Security, Identity, and Access Management
What this domain covers
This domain tests identity design and least privilege: who can call which API on which resource, how workloads authenticate, and how network and data controls reinforce IAM. Expect scenario questions about automation keys, admin separation, and public exposure.
Core rules
- IAM principals include human users and workload identities. Authenticate humans with MFA; avoid shared accounts. Authenticate automation with dedicated credentials or roles, not a person's password.
- Policies are evaluated deny-by-default. Grant the smallest action set on the narrowest resource ARN or identifier. Use groups for humans and distinct policies for workloads.
- Separate administrative, deployment, and read-only roles. The account owner is for break-glass, not daily CI/CD.
- Rotate API keys and secrets; store them in a secrets manager or encrypted parameter store if available; never commit them to images or repositories.
- Network controls: private LAN, bastion or VPN, security groups. Do not expose management ports to the internet.
- Protect data with encryption at rest and in transit, bucket policies, and audit logs. Logging must be enabled before an incident, not after.
Worked example
A CI job must upload build artifacts to one object-storage prefix. Create a workload identity with a policy allowing PutObject on that bucket and prefix only; omit DeleteObject, ListBucket, and wildcard resources. Store its key in the CI secret store and rotate it. Reasoning: the job cannot delete production artifacts or read unrelated buckets; compromise of the key has limited blast radius.
Traps
Using Action:* and Resource:*; giving the account owner key to automation; relying on a public bucket as security by obscurity; forgetting that authentication is not authorization; and enabling MFA for humans but not protecting workload secrets.