Introduction
Configuration Management and Infrastructure as Code (IaC) is Domain 2 of the AWS Certified DevOps Engineer – Professional (DOP-C02) exam, worth roughly 17% of your score. It sits right behind SDLC Automation as one of the heaviest-weighted domains, and it defines a core expectation of the certification: that you can provision, configure, and maintain infrastructure entirely through code — reproducibly, at scale, and without drift.
The questions in this domain are almost never “what does CloudFormation do?” They’re scenarios: “a stack update must be previewed before it touches production — how?”, “the same baseline must deploy into 200 accounts across 4 Regions — which feature?”, “instances must self-configure at launch and stay patched — what combination of services?” The skill being tested is picking the right IaC and configuration tool for the constraint in front of you, and knowing the guardrails (change sets, drift detection, deletion policies) that keep automated infrastructure safe.
This guide walks Domain 2 the way a practitioner works: CloudFormation as the foundation, higher-level abstractions (CDK, SAM), then the configuration-management side (Systems Manager), platform abstractions (Elastic Beanstalk), and dynamic instance configuration (golden AMIs and bootstrapping). If you haven’t mapped the whole exam yet, the AWS DevOps Engineer Professional exam guide covers all six domains and the logistics first.
What “Configuration Management and IaC” Actually Tests
The domain breaks into a handful of recurring themes. Naming the theme a scenario belongs to is half the battle:
| Theme | What the exam wants you to build |
|---|---|
| Provisioning as code | CloudFormation templates, stacks, nested stacks, cross-stack references |
| Safe change management | Change sets, drift detection, deletion/update policies, stack policies |
| Multi-account / multi-Region | StackSets, organizations integration |
| Higher-level IaC | AWS CDK, AWS SAM, and how they compile to CloudFormation |
| Configuration management | Systems Manager: Parameter Store, State Manager, Automation, Patch Manager |
| Instance bootstrapping | User data, cfn-init/cfn-signal, golden AMIs, EC2 Image Builder |
| Platform abstractions | Elastic Beanstalk environments, .ebextensions, deployment policies |
The unifying principle: infrastructure and configuration should be declarative, version-controlled, and repeatable. If an answer requires someone to click through the console or SSH in to hand-edit a server, it’s usually wrong.
CloudFormation: The Foundation
CloudFormation is AWS’s native IaC service and the center of gravity for this domain. You declare resources in a template (YAML or JSON); CloudFormation provisions them as a stack and manages their full lifecycle — create, update, delete — as one unit.
A minimal template shows the anatomy the exam assumes you know:
AWSTemplateFormatVersion: '2010-09-09'
Parameters:
InstanceType:
Type: String
Default: t3.micro
Resources:
AppServer:
Type: AWS::EC2::Instance
Properties:
InstanceType: !Ref InstanceType
ImageId: !Ref LatestAmiId
Outputs:
InstanceId:
Value: !Ref AppServer
Export:
Name: prod-app-instance-id # exported for cross-stack referenceKey sections: Parameters (inputs), Mappings (lookup tables), Conditions (conditional creation), Resources (the only required section), and Outputs (values to expose, optionally Exported for other stacks to Fn::ImportValue).
Change Sets: Preview Before You Apply
A change set is a preview of exactly what a stack update will add, modify, or replace before you execute it. This is the exam’s go-to answer whenever a scenario demands that updates be reviewed or approved before touching production. The critical nuance: some property changes force resource replacement (a new resource is created and the old one deleted), which can mean data loss or a new endpoint. Change sets surface that “Replacement: True” so you catch it first.
Nested Stacks vs Cross-Stack References
Two ways to decompose large templates — know when each applies:
| Approach | Mechanism | Best for |
|---|---|---|
| Nested stacks | Parent template references child templates via AWS::CloudFormation::Stack | Reusable components managed as one lifecycle |
| Cross-stack references | One stack Exports an output; another Fn::ImportValues it | Independently managed stacks sharing values (e.g. a VPC stack shared by many app stacks) |
Trap: you cannot delete or modify an exported output while another stack imports it. That’s a common “why did my delete fail?” scenario.
StackSets: One Template, Many Accounts and Regions
StackSets deploy and manage a single template across multiple AWS accounts and Regions from one operation — the answer whenever a scenario spans an AWS Organization (“apply this guardrail/baseline to all 150 accounts”). With service-managed permissions and Organizations integration, StackSets can even auto-deploy to new accounts as they join an OU.
Drift Detection
Drift detection compares a stack’s actual resource configuration against its template and reports resources that were changed out-of-band (someone edited a security group in the console). It doesn’t fix drift — it detects it. If a scenario asks “how do you find manual changes made outside CloudFormation?”, the answer is drift detection.
Protecting Resources: Deletion & Update Policies
DeletionPolicy: Retainkeeps a resource (e.g. an S3 bucket or RDS database) even when the stack is deleted.Snapshottakes a final backup first.UpdateReplacePolicydoes the same for updates that would replace a resource.- Stack policies protect specific resources from accidental updates.
- Termination protection blocks deletion of the whole stack.
These guardrails are heavily tested because they’re how you make automated infrastructure safe for stateful resources.
Higher-Level IaC: CDK and SAM
CloudFormation templates get verbose. AWS offers two abstractions that compile down to CloudFormation:
- AWS CDK (Cloud Development Kit) lets you define infrastructure in a real programming language — TypeScript, Python, Java, Go — using constructs. Running
cdk synthgenerates a CloudFormation template;cdk deployprovisions it. CDK is the answer when a scenario wants loops, conditionals, reusable typed components, or developers who prefer code over YAML. Under the hood, it’s still CloudFormation doing the provisioning. - AWS SAM (Serverless Application Model) is a CloudFormation extension with shorthand for serverless resources (
AWS::Serverless::Function,Api,SimpleTable).sam build/sam deployandsam localfor local testing make it the go-to for Lambda-centric stacks.
The exam framing to remember: CDK and SAM both transpile to CloudFormation — they’re developer-experience layers, not separate provisioning engines.
Systems Manager: The Configuration-Management Half
IaC provisions infrastructure; AWS Systems Manager (SSM) configures and maintains it over time. This is the “configuration management” half of the domain name, and its components are frequently tested:
| Capability | What it does | Typical exam cue |
|---|---|---|
| Parameter Store | Hierarchical store for config values and secrets (SecureString via KMS) | Centralized config; avoid hard-coding values in code/AMIs |
| State Manager | Enforces a desired configuration state on instances on a schedule | ”Ensure agents/config stay consistent across the fleet” |
| Automation | Runbooks that automate operational tasks (patch, AMI creation, remediation) | Automated, repeatable ops workflows |
| Run Command | Execute commands across many instances without SSH | Ad-hoc fleet-wide actions, no bastion needed |
| Patch Manager | Scan and patch instances against a baseline, on a maintenance window | ”Keep the fleet compliant with patches automatically” |
| Session Manager | Browser/CLI shell to instances without SSH keys or open ports | Secure access, auditable, no bastion |
Two patterns worth internalizing: State Manager is Systems Manager’s continuous configuration-enforcement engine (think of it as the AWS-native equivalent of a config-management tool keeping instances in a known state), and Parameter Store is how you keep environment-specific values out of your AMIs and templates so the same artifact promotes cleanly across environments — a theme that connects directly to the CI/CD pipeline patterns in Domain 1.
Elastic Beanstalk: Platform-as-Code with Deployment Policies
Elastic Beanstalk provisions and manages the underlying stack (EC2, Auto Scaling, load balancer) for you from application code, while still exposing configuration through .ebextensions (YAML/JSON config files in your source bundle) and saved configurations. For the DOP-C02, the most-tested angle is its deployment policies — each trades speed against safety and cost:
| Policy | How it works | Trade-off |
|---|---|---|
| All at once | Deploy to all instances simultaneously | Fastest, but full downtime on failure |
| Rolling | Batch by batch, in place | No extra cost; reduced capacity during deploy |
| Rolling with additional batch | Adds a fresh batch first, then rolls | Maintains full capacity; briefly runs extra instances |
| Immutable | Launches a new set of instances, swaps if healthy | Safest in-place option; easy rollback; higher temporary cost |
| Traffic splitting | Canary — shifts a % of traffic to new instances | Built-in canary testing before full cutover |
| Blue/Green (swap URL) | Deploy to a separate environment, then swap CNAMEs | Zero-downtime, instant rollback by swapping back |
The exam loves “zero downtime with instant rollback” → immutable or blue/green via environment URL swap; “cheapest, downtime acceptable” → all at once; “canary a small percentage first” → traffic splitting. This mirrors the deployment-strategy logic from SDLC Automation, applied at the platform level.
Dynamic Instance Configuration: Bootstrapping vs Golden AMIs
A classic DOP-C02 trade-off: how should EC2 instances arrive fully configured?
- Bootstrapping at launch — user data scripts or cfn-init (with the
AWS::CloudFormation::Initmetadata andcfn-signalto report success back to CloudFormation) install and configure software when the instance boots. Flexible, but slower to launch and dependent on external repos being reachable. - Golden AMIs — pre-bake a machine image with everything installed, typically built by a pipeline using EC2 Image Builder. Instances launch fast and identically, which matters for Auto Scaling responsiveness and immutability. The trade-off is a build/rotation process to keep images current.
The mature pattern the exam favors is a hybrid: bake a golden AMI for the heavy, slow-changing layers (OS packages, agents) and use lightweight user data plus Parameter Store for the environment-specific bits. The cfn-signal + CreationPolicy/WaitCondition combination is a specific test point — it’s how CloudFormation waits for instances to report successful configuration before marking a stack CREATE_COMPLETE.
Choosing the Right Tool: A Decision Table
| Scenario | Reach for |
|---|---|
| Declarative provisioning, native AWS, full lifecycle control | CloudFormation |
| Preview changes (esp. replacements) before applying | Change sets |
| Deploy one baseline to many accounts/Regions | StackSets |
| Detect out-of-band manual changes | Drift detection |
| IaC with loops/conditions in a real language | AWS CDK |
| Serverless-first stacks (Lambda/API/DynamoDB) | AWS SAM |
| Store and version config values / secrets | SSM Parameter Store |
| Continuously enforce instance configuration | SSM State Manager |
| Patch a fleet on a schedule, track compliance | SSM Patch Manager |
| Secure shell access with no SSH keys or open ports | SSM Session Manager |
| Managed platform from app code with deploy policies | Elastic Beanstalk |
| Fast, identical instance launches | Golden AMI + EC2 Image Builder |
Common DOP-C02 Traps
| Trap | The clarification |
|---|---|
| Thinking drift detection fixes drift | It detects and reports only — remediation is separate (e.g. re-deploy, or SSM Automation) |
| Deleting a stack whose output is imported | Fails while another stack imports the export — you must remove the dependency first |
| Assuming CDK/SAM are separate provisioning engines | Both compile to CloudFormation — the same engine provisions |
| Using nested stacks for independently managed resources | Independent lifecycles → cross-stack references; shared single lifecycle → nested stacks |
Forgetting cfn-signal with CreationPolicy | Without it, CloudFormation marks the resource complete before the instance finishes configuring |
| Picking “all at once” when zero downtime is required | Use immutable or blue/green (URL swap) for zero-downtime with rollback |
| Hard-coding secrets in templates or AMIs | Use Parameter Store (SecureString) or Secrets Manager instead |
Frequently Asked Questions
How heavily is Configuration Management and IaC weighted on the DOP-C02?
It’s Domain 2 at roughly 17% of the exam — the second-largest domain. Expect multiple scenario questions on CloudFormation features, Systems Manager, and Elastic Beanstalk deployment policies.
Do I need to know CloudFormation template syntax in detail?
You should recognize the template sections (Parameters, Resources, Outputs), key intrinsic functions (!Ref, !GetAtt, Fn::ImportValue), and features like change sets, DeletionPolicy, and StackSets. You won’t write full templates, but you must reason about what a feature does.
When should I use StackSets instead of a regular stack?
Use StackSets whenever you need to deploy the same template across multiple accounts and/or Regions from a single operation — especially with AWS Organizations, where it can auto-deploy to newly added accounts.
What’s the difference between a golden AMI and bootstrapping?
A golden AMI is pre-baked with software so instances launch fast and identically; bootstrapping (user data / cfn-init) configures instances at launch time. The exam favors a hybrid: bake slow-changing layers, configure environment-specifics at boot via Parameter Store.
Is Systems Manager part of this domain or the monitoring domain?
Both touch it, but configuration management capabilities — State Manager, Parameter Store, Patch Manager, Automation — are squarely Domain 2. Its logging/inventory features also surface in monitoring scenarios.
CDK, SAM, or raw CloudFormation — which does the exam prefer?
There’s no single “right” tool; the exam tests fit. Raw CloudFormation for native declarative control, CDK when programmatic logic or typed reusable components help, SAM for serverless-first stacks. All three end up as CloudFormation.
Conclusion
Domain 2 rewards a clear map of two halves: Infrastructure as Code (CloudFormation and its abstractions CDK/SAM, plus the safety features — change sets, drift detection, StackSets, deletion policies) and Configuration Management (Systems Manager for ongoing state, patching, and secure access; Elastic Beanstalk for platform-level deployments; golden AMIs and bootstrapping for instance configuration). Master the trade-offs — nested vs cross-stack, immutable vs all-at-once, golden AMI vs bootstrap — and the scenario questions become a matter of matching the constraint to the tool.
The fastest way to convert this knowledge into exam points is scenario-based practice under time pressure. Sailor.sh’s AWS Certified DevOps Engineer Professional (DOP-C02) Mock Exam Bundle includes eight full-length 75-question exams with 180-minute timing that mirror the real exam, plus detailed explanations across all six domains — including the CloudFormation, Systems Manager, and deployment-policy scenarios this guide covered. Working through them is the surest way to find the gap between “I understand this feature” and “I can pick the right answer under pressure.”
To keep building, sequence your prep with the AWS DevOps Engineer Professional study plan, go deeper on templates with the CloudFormation guide for DevOps, and connect this domain to the pipelines that deploy your IaC in the SDLC Automation deep dive. Then round out the resilience angle — IaC is what makes reproducible, drift-free environments possible — with the Resilient Cloud Solutions guide.