DOP-C02's Domain 2, Configuration Management and IaC, carries 17% of the exam weight. It goes far beyond knowing CloudFormation syntax — it tests your ability to reason about deploying infrastructure consistently across hundreds of accounts, automatically patching thousands of servers, and recovering when drift occurs. This post covers the key patterns that appear repeatedly in DOP-C02 exam scenarios.
Advanced CloudFormation Patterns
AutoScalingRollingUpdate — Zero-Downtime Instance Replacement
When deploying a new AMI across an Auto Scaling Group, the safest approach is to use CloudFormation's UpdatePolicy attribute to control how instances are replaced.
Key parameter summary:
| Parameter | Purpose | |-----------|---------| | MaxBatchSize | Maximum instances replaced simultaneously | | MinInstancesInService | Minimum healthy instances maintained during replacement | | WaitOnResourceSignals | Wait for cfn-signal before proceeding to next batch | | PauseTime | Wait time between batches |
AutoScalingReplacingUpdate replaces the entire ASG with a new one, meaning both exist simultaneously and costs double during transition. When gradual, controlled replacement is needed, always choose AutoScalingRollingUpdate.
Managing Stack Dependencies — Cross-Stack Export/Import vs Nested Stacks
How to separate and manage VPC, security groups, and application layers in a multi-tier architecture is a recurring topic in DOP-C02.
Cross-Stack Export/Import pattern: Network, security, and application stacks run as independent CloudFormation stacks Network stack's Outputs section defines an Export Name; app stack references it via Fn::ImportValue Each stack deploys independently, which is ideal when layers have different release cadences
Nested Stack pattern: Parent stack declares child stacks as resources Updating the parent stack triggers re-deployment of all nested stacks High resource reusability, but does not support independent deployment schedules
Remember the tight-coupling constraint: while another stack is referencing an Export, you cannot delete the exporting stack or rename its Export.
!Cross-Stack Export/Import versus Nested Stacks
CloudFormation Data Protection Policies
When stacks containing RDS instances or EBS volumes are updated or deleted, two policies must be set together to prevent data loss.
| Policy | Trigger | Behavior | |--------|---------|----------| | DeletionPolicy: Snapshot | Stack deletion | Creates automatic snapshot before deleting resource | | UpdateReplacePolicy: Snapshot | Resource replaced during stack update | Creates snapshot before replacement |
Setting only DeletionPolicy leaves you exposed when a stack update causes a resource replacement. Both policies are required to cover all data-loss scenarios.
Recovering from UPDATE_ROLLBACK_FAILED
When a stack update fails and gets stuck in UPDATE_ROLLBACK_FAILED state, the most common cause is that a resource was modified or deleted outside of CloudFormation, making it impossible to revert to the original state.
Official fix: Use the ContinueUpdateRollback API with the ResourcesToSkip parameter to skip the problematic resource and let the rest of the rollback complete. The skipped resource is marked as drifted and should be remediated separately using Drift Detection afterward.
CloudFormation Custom Resources — Automating Beyond Built-in Support
For operations that CloudFormation's built-in resource types do not support — emptying a non-empty S3 bucket, calling external APIs, creating an Active Directory Connector — use a Custom Resource backed by Lambda.
How it works: CloudFormation invokes Lambda with an event object containing a ResponseURL (a pre-signed S3 URL) Lambda must send a SUCCESS or FAILED response to the ResponseURL upon completion If cfn-response is never sent, CloudFormation waits up to one hour before timing out with a failure
The most common mistake is omitting the cfn-response call in a try/except block. If Lambda executes successfully but the CloudFormation stack times out, a missing cfn-response is almost always the culprit.
AWS CDK and CDK Pipelines
CDK's Relationship with CloudFormation
AWS CDK lets you define infrastructure using TypeScript, Python, Java, or C#. Running cdk synth produces a CloudFormation template. Because CDK-generated stacks are deployed via CloudFormation, they inherit all of CloudFormation's capabilities: drift detection, change sets, and automatic rollback.
Key CDK advantages: Use conditionals, loops, and functions to express complex infrastructure patterns concisely L2 and L3 Constructs embed best practices out of the box IDE type-checking and autocomplete reduce mistakes
CDK Pipelines — Defining Pipelines as Code
CDK Pipelines is an L3 Construct that defines CodePipeline as CDK code. Because the pipeline itself is deployed as a CloudFormation stack, any manual changes made in the console are detected as drift and automatically restored.
Managing the pipeline itself as IaC guarantees drift prevention, the ability to re-provision an identical pipeline at any time, and automatic rollback on deployment failure.
Service Catalog + CodePipeline Automated Synchronization
When a platform team distributes approved CloudFormation templates to business units, manually updating Service Catalog whenever a template changes leads to omissions and delays. CodePipeline has a native Service Catalog deploy action — no Lambda required. When a commit lands in CodeCommit, the pipeline automatically updates the Service Catalog product version.
Multi-Account Governance with AWS Organizations
Core Components of Organizations
Enterprises managing tens or hundreds of AWS accounts use Organizations and Control Tower together for governance.
| Component | Role | |-----------|------| | Management Account | Organization root, applies top-level SCPs | | Organizational Unit (OU) | Groups accounts, SCPs applied at OU level | | Service Control Policy (SCP) | Sets maximum permission boundary for IAM (allow/deny list) | | Control Tower | Landing zone automation, account provisioning, guardrails |
SCPs do not replace IAM policies. An action requires both the SCP and the IAM policy to allow it. SCPs only set the upper bound on what permissions are possible.
CloudFormation StackSets — Multi-Account, Multi-Region Deployment
StackSets deploy a single CloudFormation template across multiple accounts and regions simultaneously.
In SERVICE_MANAGED mode with auto-deployment enabled, stacks are automatically deployed to new accounts when they are added to an OU. This is the "automatic account onboarding" pattern that appears frequently in DOP-C02.
Deployment concurrency controls: MaxConcurrentPercentage: percentage of accounts to deploy to simultaneously FailureTolerancePercentage: percentage of accounts allowed to fail before the operation is stopped
GuardDuty and Config Organizations Integration
DOP-C02 frequently asks about service integrations with Organizations for security governance.
GuardDuty Organizations integration: Enabling GuardDuty from the management account or a delegated administrator account aggregates threat findings from all member accounts centrally. With auto-enable, GuardDuty is automatically activated on newly added accounts.
AWS Config Organizations rules: Deploying a Config Conformance Pack at the Organizations level applies the same compliance rules to all accounts. An Aggregator centralizes compliance status from all accounts and regions into a single console view.
Cross-Account IAM Role Pattern
When a central CI/CD account deploys to development, staging, and production accounts, cross-account role delegation is the standard approach.
Create a CrossAccountDeployRole in each target account with a trust policy referencing the CI/CD account ID CodePipeline/CodeBuild in the CI/CD account calls STS AssumeRole to obtain the target account's role Deploy CloudFormation using the temporary credentials from the assumed role
This pattern implements multi-account deployment with minimum privileges and no long-term credentials — a core DOP-C02 pattern.
Large-Scale Automation with AWS Systems Manager
Patch Manager — Environment-Specific Patch Policies
Automatically applying different patch baselines to different environments for hundreds of EC2 instances is a recurring DOP-C02 scenario.
The configuration flow:
Environment separation pattern:
| Environment | Patch Baseline | Patch Group Tag | |-------------|---------------|-----------------| | Production | SECURITY classification only | Patch Group: prod | | Staging | SECURITY (pre-validation) | Patch Group: staging | | Development | ALL | Patch Group: dev |