CloudGuild · Blog · Cheat sheets · Lessons · Certifications
AWS IAM — Identity & Access
Who can do what, on which resource, under what conditions. The control plane for all access.
What it is
Users, groups, roles, and policies that decide every allow/deny in your account.
Mental model
- Roles + temporary credentials over long-lived user keys — always.
- Policy evaluation: explicit deny > SCP boundary > explicit allow > implicit deny.
- Least privilege: grant the minimum, then widen with evidence.
Key architectural decisions
- EC2/Lambda access AWS via an attached role, never stored keys.
- Cross-account access = a role the other account assumes via STS.
- Organization-wide guardrails = Service Control Policies.
Gotchas & exam traps
- An explicit deny always wins, even over an allow.
- SCPs set the ceiling; a user can have an IAM allow and still be denied by an SCP.
- "Grant an app temporary access without static credentials" => IAM role + STS.
The architect view
Identity is the new perimeter. If a design stores access keys on a server or emails credentials, it is failing the security domain regardless of what else it gets right.