AWS CloudFormation for DOP-C02: Infrastructure as Code Complete Guide

Introduction

Configuration Management and Infrastructure as Code accounts for 17% of the DOP-C02 exam. CloudFormation is the primary service tested in this domain. The exam expects you to understand advanced template features, multi-account deployment patterns, and troubleshooting strategies that go well beyond writing basic templates.

This guide covers everything you need to know about CloudFormation for DOP-C02.

CloudFormation Template Anatomy

Every CloudFormation template has a specific structure. Know each section and when to use it.

Template Sections

AWSTemplateFormatVersion: "2010-09-09"
Description: "Template description"

Parameters:
  # Input values provided at stack creation

Mappings:
  # Static key-value lookup tables

Conditions:
  # Conditional resource creation logic

Resources:
  # AWS resources to create (REQUIRED - only mandatory section)

Outputs:
  # Values to return after stack creation

Parameters

Parameters make templates reusable across environments.

Parameters:
  Environment:
    Type: String
    AllowedValues:
      - dev
      - staging
      - prod
    Default: dev
  InstanceType:
    Type: String
    Default: t3.micro
    AllowedValues:
      - t3.micro
      - t3.small
      - t3.medium

Parameter types the exam tests:

String, Number, CommaDelimitedList
AWS::EC2::KeyPair::KeyName — Validates against existing key pairs
AWS::SSM::Parameter::Value<String> — Reads from Parameter Store at deploy time
AWS::EC2::VPC::Id, AWS::EC2::Subnet::Id — Validates against existing resources

Exam tip: The AWS::SSM::Parameter::Value type is frequently tested. It resolves Parameter Store values during stack creation, allowing you to centralize configuration outside templates.

Mappings

Mappings are static lookup tables. They don’t change at runtime.

Mappings:
  RegionAMI:
    us-east-1:
      HVM64: ami-0123456789abcdef0
    us-west-2:
      HVM64: ami-abcdef0123456789a

Use when: You need different values based on region, environment, or instance type that are known in advance. Mappings cannot reference parameters dynamically — they’re hardcoded.

Conditions

Conditions control whether resources are created or properties are applied.

Conditions:
  IsProduction: !Equals [!Ref Environment, prod]
  CreateReadReplica: !And
    - !Condition IsProduction
    - !Equals [!Ref EnableReadReplica, "true"]

Resources:
  ReadReplica:
    Type: AWS::RDS::DBInstance
    Condition: CreateReadReplica
    Properties:
      SourceDBInstanceIdentifier: !Ref PrimaryDB

Exam tip: Conditions are evaluated once at stack creation. They cannot change during a stack update unless the parameter values change.

Outputs and Exports

Outputs return information about created resources. Exports make values available to other stacks.

Outputs:
  VPCId:
    Value: !Ref VPC
    Export:
      Name: !Sub "${AWS::StackName}-VPCId"

Other stacks reference exports with Fn::ImportValue:

Resources:
  Instance:
    Type: AWS::EC2::Instance
    Properties:
      SubnetId: !ImportValue "network-stack-SubnetId"

Exam tip: You cannot delete a stack that has exports referenced by other stacks. You must remove the importing stacks first or remove the import references.

Intrinsic Functions

Know these functions and when to use each:

Function	Purpose	Example
`!Ref`	Reference a parameter or resource	`!Ref MyBucket` → bucket name
`!GetAtt`	Get a resource attribute	`!GetAtt MyBucket.Arn` → bucket ARN
`!Sub`	String substitution	`!Sub "arn:aws:s3:::${BucketName}"`
`!Join`	Join strings with delimiter	`!Join ["-", [!Ref Env, "app"]]`
`!Select`	Select item from list	`!Select [0, !GetAZs ""]`
`!Split`	Split string into list	`!Split [",", !Ref SubnetList]`
`!If`	Conditional value	`!If [IsProduction, t3.large, t3.micro]`
`!FindInMap`	Look up in mappings	`!FindInMap [RegionAMI, !Ref "AWS::Region", HVM64]`
`!GetAZs`	Get AZs for region	`!GetAZs ""` → list of AZs
`!Cidr`	Generate CIDR blocks	`!Cidr [!Ref VPCCidr, 4, 8]`
`!ImportValue`	Import from another stack	`!ImportValue "shared-vpc-id"`

Stack Operations

Change Sets

Change sets preview how a stack update will affect resources.

Workflow:

Create a change set with the updated template
Review the change set — see which resources will be Added, Modified, or Replaced
Execute the change set to apply changes, or delete it to cancel

Exam-critical detail: Some property changes cause replacement (a new resource is created and the old one deleted). Others cause in-place updates. The change set shows you which will happen.

Example: Changing an EC2 instance’s InstanceType causes an in-place update (stop, change, start). Changing the AvailabilityZone causes replacement (new instance created, old one deleted).

Stack Policies

Stack policies control which resources can be updated.

{
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "Update:Replace",
      "Principal": "*",
      "Resource": "LogicalResourceId/ProductionDatabase"
    },
    {
      "Effect": "Allow",
      "Action": "Update:*",
      "Principal": "*",
      "Resource": "*"
    }
  ]
}

Exam use case: Protect production databases from accidental replacement during stack updates.

Important: Stack policies are set once and cannot be removed (only overridden temporarily during a specific update). An empty policy denies all updates.

Drift Detection

Drift detection identifies resources that have been modified outside of CloudFormation.

How it works:

Initiate drift detection on a stack
CloudFormation compares actual resource configuration to the template
Resources are marked as IN_SYNC, MODIFIED, or DELETED

Exam use case: Detect when someone manually changes a security group rule that was deployed via CloudFormation.

Limitation: Not all resource types support drift detection. Know that drift detection is available for common resources (EC2, RDS, S3, IAM) but may not cover every property.

DeletionPolicy

Controls what happens to a resource when its stack is deleted.

Policy	Behavior
`Delete` (default)	Resource is deleted with the stack
`Retain`	Resource is preserved after stack deletion
`Snapshot`	A snapshot is taken before deletion (RDS, EBS, Redshift)

Exam tip: Always set DeletionPolicy: Retain or DeletionPolicy: Snapshot on stateful resources (databases, S3 buckets with data) in production templates.

UpdateReplacePolicy

Controls what happens to the old resource when CloudFormation replaces it during an update.

Policy	Behavior
`Delete` (default)	Old resource is deleted after replacement
`Retain`	Old resource is preserved
`Snapshot`	Snapshot taken before old resource is deleted

Nested Stacks

Nested stacks allow you to compose complex infrastructure from reusable template modules.

Resources:
  NetworkStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.amazonaws.com/templates/network.yaml
      Parameters:
        VPCCidr: 10.0.0.0/16

  ApplicationStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.amazonaws.com/templates/application.yaml
      Parameters:
        VPCId: !GetAtt NetworkStack.Outputs.VPCId

When to Use Nested Stacks

Reusable components: A VPC template used across multiple applications
Template size limits: Individual templates are limited to 51,200 bytes in S3
Resource limits: Each stack supports up to 500 resources
Team ownership: Different teams manage different infrastructure layers

Nested Stacks vs. Cross-Stack References

Feature	Nested Stacks	Cross-Stack References
Relationship	Parent-child (lifecycle coupled)	Independent (lifecycle decoupled)
Updates	Parent stack update cascades to children	Each stack updated independently
Sharing	Values passed via Parameters/Outputs	Values shared via Exports/ImportValue
Use case	Components that deploy together	Shared infrastructure (VPC, DNS)

Exam decision: If infrastructure components have the same lifecycle (deploy and delete together), use nested stacks. If they have different lifecycles (shared VPC used by many apps), use cross-stack references.

CloudFormation StackSets

StackSets deploy stacks across multiple accounts and regions from a single template.

Permission Models

Self-managed permissions:

You create IAM roles in each target account
More control over which accounts receive deployments
Requires manual role setup

Service-managed permissions (with Organizations):

CloudFormation automatically creates roles via AWS Organizations
Automatic deployment to new accounts added to an OU
Simpler setup for large organizations

Exam preference: Service-managed permissions with Organizations is the recommended approach for large-scale deployments.

Deployment Options

Maximum concurrent accounts: How many accounts receive the stack simultaneously
Failure tolerance: How many account failures are acceptable before stopping
Region order: Which regions are deployed to first
Automatic deployment: New accounts in an OU automatically receive the stack

Common Exam Scenarios

“Deploy a Config rule across all accounts in the organization” → StackSets with service-managed permissions and automatic deployment enabled.

“Ensure CloudTrail is enabled in every account and cannot be disabled” → StackSets to deploy CloudTrail + SCP to prevent deletion.

“Deploy infrastructure to 3 regions in 10 accounts” → StackSets with region ordering and parallel account deployment.

CloudFormation and CI/CD Integration

CodePipeline + CloudFormation

CodePipeline can use CloudFormation as a deployment action:

CREATE_UPDATE: Creates or updates a stack
DELETE_ONLY: Deletes a stack
REPLACE_ON_FAILURE: Deletes and recreates a failed stack
CHANGE_SET_CREATE: Creates a change set for review
CHANGE_SET_EXECUTE: Executes a previously created change set

Exam pattern: Pipeline creates a change set → Manual approval → Pipeline executes the change set. This gives reviewers visibility into what will change before it happens.

Infrastructure Pipeline Pattern

Source (template in CodeCommit)
  → Validate (cfn-lint in CodeBuild)
    → Create Change Set (staging)
      → Execute Change Set (staging)
        → Integration Tests (CodeBuild)
          → Create Change Set (production)
            → Manual Approval
              → Execute Change Set (production)

Troubleshooting CloudFormation

Common Failures

Error	Cause	Fix
`CREATE_FAILED`	Resource creation error	Check resource-level error message, fix template
`UPDATE_ROLLBACK_FAILED`	Rollback itself failed	Use `ContinueUpdateRollback` with resources to skip
`DELETE_FAILED`	Resource can’t be deleted	Check for dependencies, use `RetainResources` parameter
Circular dependency	Resources reference each other	Use `DependsOn` or restructure references
Template validation error	Invalid syntax or references	Run `aws cloudformation validate-template`
Resource limit exceeded	Stack exceeds 500 resources	Use nested stacks to split resources

UPDATE_ROLLBACK_FAILED Recovery

This is a critical exam topic. When a stack update fails and the rollback also fails:

Identify which resources caused the rollback failure
Manually fix the resource issues (e.g., delete a manually modified resource)
Use ContinueUpdateRollback API call, optionally skipping problematic resources
The stack returns to UPDATE_ROLLBACK_COMPLETE state

Best Practices for DOP-C02

Use parameters for environment-specific values. Never hardcode account IDs, AMI IDs, or environment names.
Use SSM Parameter Store references. Centralize configuration outside templates.
Apply DeletionPolicy to stateful resources. Protect databases and storage from accidental deletion.
Use change sets before every production update. Preview changes before applying them.
Implement stack policies for production. Prevent accidental replacement of critical resources.
Use StackSets for multi-account governance. Deploy compliance infrastructure consistently.
Validate templates in CI/CD. Use linting tools in CodeBuild before deploying.
Keep templates modular. Use nested stacks or cross-stack references for reusability.

Test Your CloudFormation Knowledge

Infrastructure as Code is 17% of DOP-C02. Combined with CI/CD (22%), automation-related questions make up nearly 40% of the exam.

Sailor’s DOP-C02 mock exam bundle includes CloudFormation-focused questions covering StackSets, change sets, nested stacks, and multi-account patterns. Domain-level scores show whether your IaC knowledge is exam-ready.

DOP-C02 Exam Guide 2026 — Complete exam format and all five domains
DOP-C02 CI/CD Guide — Pipeline architecture with CloudFormation integration
DOP-C02 Monitoring Guide — The largest exam domain (26%)
10-Week DOP-C02 Study Plan — Week 4 covers CloudFormation in depth