Assign permissions to groups instead of duplicating policies on every user. Use roles when AWS services or external identities need temporary credentials—not long-lived user keys.
When to use each
| Identity | Use when |
|---|---|
| User | Human with long-lived Console/CLI access (small teams) |
| Group | Apply same policy set to Developers, Billing, Admins |
| Role | EC2 instance, Lambda, CI runner, or cross-account access |
Create a sandbox developer group (concept)
# Console workflow (preferred for learners):
# IAM → User groups → Create group → attach ReadOnlyAccess or custom policy
# IAM → Users → Add user to group
# CLI example (sandbox only):
aws iam create-group --group-name DevelopersSandbox
aws iam attach-group-policy \
--group-name DevelopersSandbox \
--policy-arn arn:aws:iam::aws:policy/ReadOnlyAccessPractice: Perform IAM steps in the IAM Console or with the AWS CLI in a sandbox account only.
Roles for EC2 (preview)
An EC2 instance profile lets the app call S3 without static keys on disk—covered again in compute and integration lessons.
Important interview questions and answers
- Q: Why groups?
A: Single place to update permissions for many users; avoids policy drift per user. - Q: Role vs user credentials?
A: Role credentials are temporary and auto-rotated; users can have persistent access keys.
Self-check
- When should you use a role instead of an IAM user?
- Why attach policies to groups rather than individual users?
Tip: Attach policies to groups named Developers, Billing, Admins—not duplicated on each user.
Interview prep
- Groups benefit?
Centralize permissions—update one group instead of every user.
- Role vs user?
Roles provide temporary credentials for services and federation; users are persistent identities.