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. On a first pass the gap is usually embarrassing. Teams find that a large share of granted actions go untouched over the window, with full admin attached to roles that touch two services. That number is also your business case when engineering asks why anyone is spending time here.
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.