IAM — Concept
What it is
AWS Identity and Access Management (IAM) = the global, free service that controls who (identity) can do what (permission) on which (resource) in your AWS account.
Why it exists
A single AWS account can hold thousands of resources used by many people, apps, and services. IAM lets you grant least-privilege, auditable access without sharing the root credentials.
Core entities
| Entity | What it is |
|---|---|
| Root user | The email that created the account. Has all powers. Use only for billing + a few account-level tasks; enable MFA, then lock away. |
| IAM user | A long-lived identity for a human or app. Has password and/or access keys. |
| IAM group | A bag of users. Attach policies to the group, not to each user. |
| IAM role | An identity assumed by something else (EC2, Lambda, another account, a federated user). Returns short-lived STS credentials. |
| IAM policy | JSON document with Effect, Action, Resource, optional Condition. |
Policy types (memorize)
| Type | Attaches to | Purpose |
|---|---|---|
| Identity-based | User / group / role | Grants permissions to that identity |
| Resource-based | S3 bucket, SQS queue, KMS key, Lambda, etc. | Allows access from a Principal (cross-account works without role assumption) |
| Permissions boundary | User or role | A maximum — limits what identity-based policies can grant |
| Service Control Policy (SCP) | OU / account in Organizations | Account-wide cap (no Allow on its own) |
| Session policy | Passed during AssumeRole | Further restricts a single session |
| ACL | S3 / VPC | Legacy; prefer bucket policies and NACLs |
How a request is evaluated
- Explicit Deny anywhere → deny.
- SCP must allow.
- Permissions boundary must allow.
- Identity-based or resource-based policy must allow.
- Otherwise → implicit deny.
STS & roles
- AssumeRole: returns temporary credentials (default 1 h, max 12 h).
- Roles for services: e.g. EC2 instance profile, Lambda execution role.
- Cross-account: trust policy in role + identity policy in caller's account.
- Federation: SAML 2.0, OIDC (Cognito, GitHub Actions, EKS), AWS IAM Identity Center (formerly SSO).
When to use vs alternatives
| Use ... | Instead of ... | When ... |
|---|---|---|
| IAM role | Access keys on an EC2 / Lambda | Always for AWS service-to-service auth |
| IAM Identity Center | IAM users | Multi-account human SSO via Orgs |
| Cognito | IAM users | End-user auth for mobile/web apps |
| Resource-based policy | Role assumption | Cross-account access to S3/SQS/Lambda |
Limits & defaults
- Max policies per user: 10 managed.
- Policy size: managed 6,144 chars; inline larger but discouraged.
- Access keys per user: 2 (rotate one while the other is active).
- Role session: default 1 h, max 12 h (set in role).
- Password policy is account-wide.
Common exam scenarios
- "App on EC2 needs S3 access" → attach IAM role to instance profile, not keys.
- "Limit max permissions of a developer-created role" → Permissions boundary.
- "Block use of a region across all accounts" → SCP on the OU.
- "Allow GitHub Actions to deploy to AWS" → OIDC federation with an IAM role.
- "Audit who did what" → CloudTrail (IAM only authorizes, doesn't log itself).
- "Cross-account S3 read" → resource policy on bucket + identity policy on caller, or assume role.
- "Enforce MFA for sensitive actions" →
Condition: {Bool: {aws:MultiFactorAuthPresent: true}}.
Exam tip
Never use long-term access keys on EC2/Lambda — always use a role. Never attach policies to an individual user when more than one user needs them — use a group.