Identity & Privileged Access
Authorization / Policy Engineer
Policy-as-code appears in 44% of identity postings — higher than directory work. This is the growth specialism in identity and it is an engineering role.
Authentication is largely solved if you deploy phishing-resistant factors. Authorisation is not, and it is where the actual risk sits: almost every reported ‘account compromise’ is two failures, and the second — that the account could reach far more than it should — is what turned an incident into a breach.
What the job actually is
You build and own the system that answers may this subject perform this action on this resource, for every application in the estate, consistently. That means an externalised policy engine — Open Policy Agent with Rego, AWS Cedar, OpenFGA or SpiceDB — policy living in version control with tests and code review, and the unglamorous work of getting applications to actually call it.
| Time | What you are actually doing |
|---|---|
| 09:00 | A team wants to ship a new endpoint. You review the authorisation model with them: what the resource is, who owns it, and whether the existing policy already covers it. |
| 10:30 | Write Rego. A relationship-based rule — a user may read a document if they own it, or are in a group granted access to its folder, or the document is public within their tenant. |
| 13:00 | Performance. The policy engine is on the hot path for every request, so you are looking at cache behaviour and p99, because authorisation that adds 40ms to every call gets removed by whoever owns latency. |
| 14:30 | Bypass hunt. You grep the codebase for direct database queries that skip the authorisation layer entirely, which is where the real vulnerabilities live. |
| 16:00 | An audit question: who can access this dataset? You answer it by evaluating policy rather than by reading a spreadsheet, which is the whole point. |
The decisive round
“Design authorisation for a multi-tenant SaaS document system.”
Interviewer: “Documents, folders, teams, sharing links, and enterprise customers who want their own roles. Design the authorisation.”
A weak answer. “I'd define roles — owner, editor, viewer — assign them to users per document, and check the role on each request.” Falls over on the second requirement. Folder inheritance, group membership and sharing links are all relationships, not roles, and modelling them as roles produces a row per user per document, which is where role explosion comes from.
A strong answer. “The requirements are relationship-shaped rather than role-shaped, so I'd model it as relationships and derive permissions — the Zanzibar approach, which is what OpenFGA and SpiceDB implement.
The core is tuples: user X is an editor of document Y; folder F is the parent of document Y; group G is a member of folder F's viewers. Then permissions are computed by traversing those — a user can view a document if they are a direct viewer, or an editor, or a member of a group with viewer on any ancestor folder. Inheritance falls out of the graph instead of being copied onto every object, which is what stops the explosion.
Tenancy I'd put in the object identifier itself rather than as a check, so cross-tenant access is not expressible rather than merely denied. That is a stronger guarantee than a filter someone can forget.
Custom enterprise roles become named permission sets scoped to a tenant, which the model supports without changing the engine.
Two hard parts I'd flag. Latency — this is on every request, so it needs local caching with an invalidation story, and the honest trade is that cache staleness means a revoked share may work for a few seconds. That must be a stated decision, not an accident. The list problem — ‘show me all documents I can see’ is a reverse lookup, not a permission check, and it is much harder; it usually needs a materialised index rather than checking every document.
And I'd want a bypass test in CI that asserts every data path goes through the engine, because a policy layer that some code paths skip is worse than none — it produces confidence without coverage.”
Recognising the problem is relationship-shaped, naming the list problem, and flagging the cache-staleness trade are the three things that mark someone who has built this.
- Build something with OpenFGA or OPA. A small document system with folder inheritance and group sharing. A weekend, and it makes every answer above concrete.
- Write policy tests. Rego and Cedar are testable; bringing a tested policy file is unusual and immediately credible.
- Measure the hot path. Add the engine to a request path and record the p99 with and without caching. Interviewers for this role care about latency more than candidates expect.
Compensation
| Market | Band | Notes |
|---|---|---|
| United States | $160k – $270k base | Prices as a backend specialism, not as IAM administration |
| India | ₹22L – ₹55L total | Growing; concentrated in product companies and identity vendors |
The book for this field
Identity & Access
Authentication versus authorisation, federation, the joiner-mover-leaver lifecycle, entitlements, privileged access, secrets, and machine identity.
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 →