IAM Fundamentals
Users, groups, roles, and policies — how identity and access management controls who can do what in your AWS account.
AWS Identity and Access Management (IAM) controls *who* (authentication) can do *what* (authorization) in your account. It's global (not tied to a Region), free, and at the heart of Domain 2. Master four building blocks: users, groups, roles, and policies.
| Building block | What it is | Use it for |
|---|---|---|
| IAM user | An identity with permanent credentials (password / access keys) for a person or app | A named human or legacy application needing long-term access |
| IAM group | A collection of users that share permissions | Assign policies once to 'Developers' instead of to 20 individuals |
| IAM role | An identity with *temporary* credentials that can be assumed by services, users, or other accounts | EC2 apps calling S3, cross-account access, federated logins — no stored passwords or keys |
| IAM policy | A JSON document that allows or denies actions on resources | The actual permissions — attached to users, groups, or roles |
Users are employees with permanent badges. Groups are departments — give the whole 'Finance' department vault access at once. Roles are visitor badges: powerful but temporary, handed to whoever (or whatever machine) legitimately needs them right now. Policies are the fine print on every badge saying which doors open.
How permissions are evaluated
Key points
- By default, everything is implicitly denied. Permissions must be granted explicitly.
- An explicit Deny always wins over any Allow.
- Policies can be identity-based (attached to users/groups/roles) or resource-based (attached to a resource, like an S3 bucket policy).
- IAM policies are written in JSON with Effect (Allow/Deny), Action, and Resource.
The root user
Every AWS account has one root user — the email address that created the account. It has unrestricted power that can't be limited by IAM policies, including account-closing abilities. Best practice: enable MFA on it, don't create access keys for it, lock it away, and use it only for the few tasks that require it (like changing the account email or closing the account). Day-to-day work happens with IAM identities.
Roles vs users is the #1 IAM exam pattern: an application on EC2 needs S3 access → attach an IAM role to the instance (never store access keys on the server). Temporary access, cross-account access, or AWS services acting on your behalf → role.
Never embed access keys in code or share credentials between people. Each human gets their own identity; each workload gets a role. Shared credentials destroy accountability in CloudTrail logs.
An application running on an EC2 instance needs to read objects from an S3 bucket. What is the MOST secure way to grant access?