Study DOP-C02 IAM at scale for DevOps roles, federation, secrets rotation, STS, MFA, and least-privilege delegation.
The first security task on DOP-C02 is about identity design that survives growth. AWS is testing whether pipeline runners, build systems, operators, and applications get the right access model without falling back to shared admin credentials or brittle IAM sprawl.
This domain gets easier when you split principals into two categories:
The strongest answer usually gives each category a different control model. Human access leans toward federation, permission sets, MFA, and role assumption. Machine access leans toward STS, scoped roles, profiles, and automated secret rotation where credentials still exist.
| Requirement | Strongest first fit | Why |
|---|---|---|
| Workforce access across multiple AWS accounts | Federated access and IAM Identity Center | Centralized control and reduced IAM user sprawl |
| Build or deploy system needs short-lived AWS access | STS and assumed roles | Better than long-lived access keys |
| Delegated admin needs limited ability to create roles or policies | Permission boundaries | Keeps delegation below a controlled ceiling |
| App or machine secret still exists and must rotate | Automated rotation pattern with a managed secret store | Limits manual key lifespan |
The exam often frames least privilege as a release-engineering problem, not just a policy-writing problem. The question is usually whether a pipeline, deployment role, or automation runner can do exactly what it must do across environments and nothing broader.
If a choice grants admin access “to avoid pipeline failures,” it is usually not the strongest answer.
When the prompt says scale, separate workforce identity from machine identity first. Then decide whether the real control problem is federation, temporary credentials, permission delegation, or secret lifecycle.