Least Privilege
Grant the minimum access needed — the single highest-leverage security habit.
Least privilege means every identity gets only the permissions it needs to do its job — no more. It’s the highest-leverage security practice because it shrinks the blast radius of any compromise: a leaked credential or hacked service can only do what little it was allowed.
How to apply it:
- Start from zero and add permissions as needed, not the reverse
- Prefer narrow scopes (one bucket, one resource group) over account-wide
- Remove standing admin access; use just-in-time elevation
- Continuously review and prune unused permissions (access analyzers help)
The related idea is separation of duties — no single identity should be able to do everything (e.g. deploy and approve its own change).
Too broad (avoid): Least privilege (prefer):
AdministratorAccess → s3:GetObject on arn:…:my-bucket/*
Owner on subscription → Reader on one resource group
long-lived admin key → JIT elevation for 1 hour when needed- Rewrite an “admin everywhere” grant as a least-privilege one.
- Explain how least privilege limits the impact of a leaked credential.
- Describe just-in-time access and why it beats standing admin.
- What is separation of duties?
Cheat Sheet▾
| Principle | Detail |
|---|---|
| Least privilege | Minimum needed permissions |
| Default deny | Start at zero, add as needed |
| Narrow scope | One resource, not account-wide |
| JIT access | Temporary elevation |
| Review/prune | Remove unused permissions |
| Separation of duties | No single all-powerful identity |
Common Interview Questions▾
What is the principle of least privilege and why does it matter?
Granting each identity only the permissions it needs. It minimizes the blast radius of a compromise — a leaked credential can only do what little it was permitted.
What is just-in-time access?
Granting elevated permissions only temporarily, when needed and approved, instead of standing admin rights — so high privilege exists only briefly and is audited.