DOP-C02 Configuration Management and IaC Guide
Study DOP-C02 configuration management, CloudFormation, CDK, drift, desired state, and compliance as code.
This is the desired-state domain. DOP-C02 wants you to choose infrastructure definitions, reusable components, drift controls, and compliance checks that keep environments consistent across accounts and stages.
What AWS is explicitly testing
As of May 11, 2026, the current AWS DOP-C02 domain page splits Configuration Management and IaC into three task areas:
- Task 2.1: define cloud infrastructure and reusable components to provision and manage systems throughout their lifecycle
- Task 2.2: deploy automation to create, onboard, and secure AWS accounts in a multi-account or multi-Region environment
- Task 2.3: design and build automated solutions for complex tasks and large-scale environments
That split matters because DOP-C02 questions often mix templates, account governance, and operational automation into one prompt. The best answer usually solves the actual scale or lifecycle problem instead of just saying “use CloudFormation.”
Current weight in the exam guide
AWS currently weights this domain at 17% of scored content.
Work this domain in order
Start with 2.1 Reusable IaC and Lifecycle Management so the infrastructure-definition patterns are clear first.
Then move through:
- 2.2 Multi-Account Provisioning and Governance Automation
- 2.3 Large-Scale Configuration Automation
Fast routing inside this chapter
| If the scenario is really about… |
Go first to… |
| CloudFormation, CDK, SAM, modules, Service Catalog, reusable patterns, drift, or lifecycle-managed templates |
2.1 Reusable IaC and Lifecycle Management |
| Organizations, Control Tower, account vending, StackSets, SCPs, or standardized onboarding across Regions/accounts |
2.2 Multi-Account Provisioning and Governance Automation |
| Systems Manager, AppConfig, State Manager, Lambda automation, patching, inventory, or desired-state enforcement at scale |
2.3 Large-Scale Configuration Automation |
What strong DOP-C02 answers usually do
- treat templates and configuration definitions as long-lived controlled assets
- reuse infrastructure patterns instead of cloning slightly different stacks everywhere
- separate account-governance automation from workload-level configuration logic
- enforce desired state with automation rather than relying on manual drift cleanup
- choose the automation control plane that matches the scale of the environment
Common IaC and configuration traps
- using IaC only for initial provisioning but not for lifecycle changes
- copying stacks per account instead of using reusable modules or StackSets where appropriate
- trying to solve multi-account governance with ad hoc scripts alone
- patching drift manually when the requirement clearly wants desired-state automation
- using one tool name as a reflex when the real issue is account onboarding, app configuration, or fleet configuration
In this section
-
DOP-C02 Reusable IaC and Lifecycle Management Guide
Study DOP-C02 reusable IaC for CloudFormation, CDK, SAM, Service Catalog, drift control, and lifecycle-managed infrastructure.
-
DOP-C02 Multi-Account Provisioning and Governance Automation Guide
Study DOP-C02 multi-account provisioning, Control Tower, Organizations, StackSets, SCPs, and governance automation.
-
DOP-C02 Large-Scale Configuration Automation Guide
Study DOP-C02 large-scale configuration automation for Systems Manager, State Manager, AppConfig, patching, and desired state.