Identity & Privileged Access
Privileged Access (PAM) Engineer
The highest-value control surface in an enterprise. Also the programme that most often gets deployed and never actually adopted.
A privileged account is one that can change the system rather than merely use it — domain admin, root, cloud account owner, database superuser, the CI service account that can deploy anything. Compromising one converts an intrusion into a total loss, which is why this gets its own tooling, its own team and its own budget line.
A day
| Time | What you are actually doing |
|---|---|
| 09:00 | Onboard a new application to the vault. The interesting part is not the secret — it is deciding how the workload proves it is the workload, which for a Kubernetes estate means the ServiceAccount token rather than a shared client certificate. |
| 10:30 | Chase down standing privilege. You pull the list of accounts with permanent admin rights and work through it team by team. This is most of the job and it never finishes. |
| 13:00 | An access request that needs dual control. Someone wants production database credentials for a data fix; you check it is tied to a change record and route it for a second approval. |
| 14:30 | Break-glass review. The emergency account was used at 02:40 on Sunday. You establish who, why, and whether the automatic incident review happened. |
| 16:00 | Write code. A reconciliation job that compares who holds privilege in the directory against who is registered in the PAM platform, because the two drift and nobody notices. |
A real posting, decoded — Okta, “Fullstack Staff Software Engineer — PAM”, Bengaluru, India
Live in the corpus behind this site. Paraphrased, then translated.
| What the posting says | What it actually means | So you should |
|---|---|---|
| Leverage AI pair-programmers and LLMs such as Copilot and Claude to accelerate development | This is a stated hiring requirement, in India, for a security product role. It is not a nice-to-have paragraph — it appears in both the responsibilities and the qualifications. | Be able to describe how you actually use these tools and where you do not trust them. ‘I use Copilot for tests and boilerplate, and I review anything touching auth by hand’ is a real answer. |
| Design, develop and deliver cloud-based privileged access management solutions | You are building the PAM product, not operating one. Different job from the enterprise side of this archetype and it pays differently. | Know the domain as a builder: what a session broker does, why credentials must not reach the endpoint, how JIT elevation is modelled. |
| 9+ years in Go, Java or C++, especially backend services. Go preferred | A genuinely senior backend bar. The security domain does not substitute for engineering depth here. | Do not lead with security certifications. Lead with distributed systems and language depth, then domain. |
| Ensure solutions account for scalability, redundancy and multi-tenancy | It is a SaaS product serving many customers, so tenant isolation is a first-class design concern. | Be ready to design multi-tenant isolation for a system holding other companies' production credentials — the highest-stakes version of that question. |
| 4+ years with PostgreSQL, designing and querying | Real data modelling, not ORM familiarity. | Expect an actual schema and query discussion. |
The decisive round
“How should a pod in Kubernetes get a database password?”
Interviewer: “We're containerising. Applications currently read a password from a config file. What should they do instead?”
A weak answer. “They should retrieve it from the vault at startup instead of the config file, using an API token stored as a Kubernetes secret.” This has moved the problem rather than solved it. The API token is now the long-lived credential, it is sitting in a Kubernetes secret which is base64 rather than encrypted by default, and anyone who can read secrets in that namespace has the keys to the vault.
A strong answer. “The goal is that no long-lived credential exists on the pod at all, so the first question is how the pod proves who it is without already holding a secret — otherwise you have a bootstrapping problem dressed up as a solution.
In Kubernetes the answer is the pod's own ServiceAccount token. The vault is configured to trust the cluster's issuer, so the pod presents its projected token, the vault validates it against the cluster API, checks the ServiceAccount and namespace against policy, and issues a credential. Nothing was pre-planted. With CyberArk that is Conjur with the Kubernetes or JWT authenticator; with HashiCorp Vault it is the Kubernetes auth method.
Then I'd push one step further: the credential it hands back should be dynamic rather than a stored static password. The vault creates a database user on demand with a short lease and revokes it on expiry, so the credential the pod is using did not exist an hour ago and will not exist in an hour. That turns a leak from an incident into a non-event.
Operationally the parts that bite are lease renewal — a long-running pod must refresh before expiry or it dies mid-request — and connection pooling, since pools hold connections opened under a credential that has since been revoked. Both are solvable and both are usually discovered in production.
What I'd avoid is the classic PAM fallback of a client certificate plus an application ID with an allowed-machine list. It works, but the allowed-machine model fits autoscaling pods badly, and you end up either widening it until it means nothing or fighting it on every scale-up.”
The strong answer identifies the bootstrapping problem first, which is the actual intellectual content of the question, then names the mechanism, then volunteers the two operational failures. Very few candidates get past ‘use a vault’.
What to build
- A working dynamic-secrets demo. Run Vault locally, configure the Kubernetes auth method against a kind cluster, and have a pod receive a short-lived database credential with no secret pre-planted. A weekend, and it is the single most convincing thing you can bring.
- Break it deliberately: let a lease expire under a long-running connection pool and watch what happens. That failure is the one you will be asked about.
- A standing-privilege inventory for something you control — a cloud account will do. How many principals hold permanent admin, and what would a JIT model look like?
- A coverage metric. Write the query that answers ‘what fraction of privileged sessions went through the broker last month’. Bringing that question to an interview signals you know where these programmes fail.
Real cases
An attacker phished a contractor, defeated MFA by repeatedly prompting until the user accepted, then found hard-coded admin credentials for the PAM system in a PowerShell script on an internal network share. Those credentials unlocked broad access.
Use it to say: “It is my standard argument that PAM is only as strong as its own bootstrap. A vault reached with a static credential sitting on a file share is a very expensive password manager.”
An attacker compromised a DevOps engineer's home computer through a vulnerable media server, keylogged the master password, and reached the decryption keys held by one of only four engineers with that access.
Use it to say: “Four people with standing access to everything is the finding. The control I'd have wanted is dual authorisation on that vault, so no single compromised endpoint is sufficient.”
A remote access portal without multi-factor authentication led to a breach that disrupted US healthcare payments for weeks.
Use it to say: “This is why I report coverage rather than policy. They had an MFA policy. Nobody had a number for what percentage of access paths enforced it.”
A three-week plan
Week 1 — build it
Days 1–3: Vault plus kind. Kubernetes auth method, dynamic database secrets, no pre-planted credential.
Days 4–5: Add lease renewal and deliberately break it under a connection pool. Write down what happened.
Week 2 — the enterprise side
Days 1–2: Model a JIT elevation flow on paper: request, approval, time-box, tie to a change record, automatic revocation.
Days 3–5: Inventory standing privilege somewhere real. Produce the coverage metric and the reduction plan.
Week 3 — rehearse
Days 1–2: The pod-credential answer, out loud, on a timer, including both operational failures.
Days 3–4: The harder one: how you would get admins who kept standing accounts to actually stop.
Day 5: Five stories — a bypass you found, a credential you eliminated, a rollout that stalled and why, an incident involving privilege, a metric you introduced.
Red flags
PAM as a vault-only project. If the scope stops at storing passwords, you will spend two years on a password manager and the standing accounts will still be there.
No mandate to remove standing privilege. Ask directly whether the programme has authority to take admin rights away, and from whom. If it does not, coverage will never move.
The security team is exempt. If the people running PAM keep their own standing access, nobody else will accept the constraint, and this is more common than it should be.
Compensation
| Market | Band | What moves it |
|---|---|---|
| United States | $150k – $260k base | Product-side engineering pays above enterprise operations |
| India | ₹22L – ₹60L total | Okta, CyberArk, SailPoint and BFSI GCCs are the main employers |
| Both | — | Building the product pays materially more than operating one. The Okta posting above is a Bengaluru staff engineering role, not an admin role |
The book for this field
Identity & Access
Authentication versus authorisation, federation, the joiner-mover-leaver lifecycle, entitlements, privileged access, secrets, and machine identity.
Also read for this role
Microsoft 365 & Copilot in the Enterprise
How a Microsoft 365 estate is actually built, licensed and governed — tenant, identity, workloads, devices, Purview and Defender, every licence tier with current prices, and then Copilot and Copilot Studio from the request path to the evidence on whether they deliver.
All 12 chapters in Microsoft 365 & Copilot in the Enterprise →
Cross-cutting
Skills every archetype tests
These are shared across every field on this site — the same question asked in different vocabulary — so preparation here compounds rather than being spent once. The book above is specific to your field.
Practice the 11 Identity questions → · Back to Identity & Privileged Access →