TL;DR: Least privilege at fleet scale is an evidence problem before it is a policy problem. Capture what every identity actually did for 60 to 90 days, diff granted permissions against used ones, shrink in tiers with a break-glass escape hatch, and run the loop continuously, because a point-in-time review is stale within weeks.
How to approach it
Clarify scale and goal: how many accounts and identities, and whether they want an audit artefact or an actual reduction in standing permission. Then state your spine early: measure usage first and generate policy from evidence, because hand-writing policies for thousands of roles is where these programmes die.
A strong answer
Start by collecting the truth about what identities do. CloudTrail management events, selected data events and IAM last-accessed information give you, per role and per principal, which services and actions were actually exercised. Diff that against granted permissions and you get the one number that runs the whole programme: actions granted minus actions used.
Work it once and it becomes a business case rather than a principle. Suppose 400 roles averaging 180 granted actions each, which is 400 × 180 = 72,000 grants in the estate. Over a 90-day window those roles exercise an average of 12 actions each, 400 × 12 = 4,800. The gap is 72,000 − 4,800 = 67,200 grants, about 93 percent of what was handed out, never used.
That single percentage is what gets the work funded, and the next cut is what makes it tractable. Split the 400 by usage rather than treating them as one backlog: the roles with zero recorded activity in the window are a removal conversation with an owner, the ones active on a few services are a policy-generation exercise, and only the remainder needs engineering time per team. A programme framed as "93 percent of grants are unused" is a different conversation from one framed as "we should tighten IAM".
Shrink in tiers rather than one heroic rewrite. An action absent from a 60–90 day window may serve disaster recovery, an annual job or incident response. Obtain owner confirmation and test those rare paths before staged removal. Last-accessed data has service/action coverage limits; it is evidence, not proof of no need. IAM last-accessed limitations. Over-scoped roles on actively used services get generated policies built from observed activity, reviewed by the owning team, canaried on one account while you watch for AccessDenied spikes in CloudTrail. Whatever remains needs engineering time per team, and you schedule it like any other backlog instead of hoping a tool finishes it.
Two things separate a real programme from a spreadsheet exercise. First, escalation paths: PassRole can participate in escalation when combined with permission to create or alter a service workload and a role that trusts that service. PassRole alone does not assume the role; evaluate the full action/trust chain. Graph analysis such as pmapper, or commercial platforms like Wiz and Sonrai, surfaces these chains, and closing them matters more than trimming S3 verbs. Second, permanence: new roles appear weekly, so generation-from-evidence runs continuously, SCP-style guardrails deny the worst patterns organisation-wide, and any new admin grant pages a human.
Keep one break-glass role per account: no standing members, approval-gated, session-recorded, auto-expiring. It converts every argument of the form "but I might need admin someday" into a two-minute detour instead of a permanent grant.
| Tier | Finding | Action |
|---|---|---|
| 1 | No use in observed window | Owner review, rare-path tests, staged removal |
| 2 | Over-scoped on used services | Generate from evidence, canary, enforce |
| 3 | Escalation path to admin | Close regardless of usage |
| 4 | Genuine broad need | Break-glass with approval and recording |
What interviewers probe next
"How do you avoid breaking production?" Evidence-based removals first, canary accounts second, alarms on AccessDenied spikes third, rollback via the previous policy version. You will still cause one incident somewhere in a programme this size; say so going in rather than promising zero.
"What about human access, not machine roles?" Move humans to SSO groups with federated roles and just-in-time elevation that expires. Standing console admin for individuals should not survive the quarter.
"A team insists they need admin permanently." Ask what they did with it last month. Real work gets a scoped role shaped around exactly that work; a hypothetical need is already covered by break-glass.
Common mistakes
Hand-writing policies from imagination instead of generating them from recorded activity, breaking everything, and getting the whole effort reverted.
Treating it as a quarterly review in a spreadsheet. Permission drift accumulates in weeks, so review-only programmes re-find the same findings forever.
Ignoring privilege escalation because the role looks read-only. Interviewers raise PassRole specifically to test whether you have chased a real chain to its end.