The four building blocks
| Object | What it is |
|---|---|
| User | A person/app identity with long-term credentials. |
| Group | A collection of users; attach policies once, apply to all. |
| Role | An identity assumed temporarily (by a service, user, or federated identity) — short-lived credentials. Preferred for apps/EC2. |
| Policy | JSON document granting/denying permissions. Identity-based (on user/group/role) or resource-based (on the resource, e.g. S3 bucket policy). |
How policy evaluation resolves conflicts
By default everything is denied. An explicit Allow grants access. An explicit Deny always wins over any Allow. So: explicit deny > explicit allow > default deny.
Root account & least privilege
- Least privilege: grant only the permissions needed — start minimal, add as required.
- Don't use the root user for daily work; lock it away, enable MFA, delete its access keys.
- Prefer roles over long-term keys for EC2/Lambda and cross-account access.
- Enable MFA for privileged users.
Exam traps
- Thinking Allow can override Deny. An explicit Deny always wins.
- Embedding access keys in code on EC2. Attach an IAM role instead.
- Using root for routine tasks. Create individual IAM users/roles.
Test yourself
4 quick questions — tap an answer to check it instantly. Nothing is sent anywhere.
1. In IAM policy evaluation, which wins?
2. Which IAM object provides temporary credentials that are assumed?
3. Best practice for the root user is to…
4. A policy attached to an S3 bucket (not a user) is…
Sources
- Amazon Web Services — AWS IAM User Guide.
- AWS official documentation and the AWS Certified Solutions Architect exam guide.
Reference summary only. "AWS" is a trademark of Amazon. Confirm current details in the official AWS documentation.