Configuration Management & IaC

Domain 2 of the DOP-C02 blueprint asks a narrower question than "do you understand infrastructure as code" — it asks whether you know AWS's own opinionated implementation of it. Infrastructure as code and configuration management already gave you the vendor-neutral model this whole domain sits on top of: declarative state, idempotency, drift, and plan-then-apply. This page assumes that foundation and goes straight to the AWS surface area it maps onto — CloudFormation as the provisioning engine, the CDK as a code-first front end for it, Systems Manager for configuring fleets that already exist, and Organizations plus Control Tower for governing all of it across many accounts and regions at once. At 17%, it's tied for the exam's second-largest domain, and more than any other domain it rewards knowing a specific service feature over knowing a general principle.

The domain: where 17% of the exam actually goes

☺ Like you're 10: Roughly one in every six exam questions lives here — and most of them are testing whether you know a specific AWS feature, not whether you understand IaC in general.

AWS's own exam guide groups this domain's task statements into two families: provisioning AWS resources with an infrastructure-as-code technique, including in hybrid and multi-account environments, and applying a configuration management strategy to a fleet of resources that already exist. That split maps directly onto the vendor-neutral boundary configuration management already drew — provisioning makes a resource exist, configuration changes what's running on a resource that already does — except every tool named on the exam is AWS-native.

AWS revises domain weighting whenever it revises the exam guide, and it has done exactly that before on this exam. Treat the percentages above as a planning signal, not gospel — confirm the current split on the DOP-C02 exam guide page before you build a study schedule around them.

CloudFormation: templates, change sets, and drift

☺ Like you're 10: CloudFormation is AWS's own declarative engine — you already know plan-then-apply and drift from earlier in this course; this is just AWS's specific words for the same two ideas.

A CloudFormation template is a JSON or YAML file with one required section, Resources, and several optional ones — Parameters for inputs, Mappings for static lookup tables, Conditions for environment-specific branching, Outputs for values other stacks or tools can consume, and Transform for macros like AWS SAM. Submit a template and CloudFormation creates a stack: a single named collection of resources that CloudFormation now owns and tracks, the same role Terraform's state file plays for a Terraform-managed set of resources — see infrastructure as code for that comparison in general form.

A change set is CloudFormation's version of a plan: it computes the diff between a stack's current state and a proposed template update, and shows exactly what will be added, modified, or replaced — without touching anything — so a human or an automated gate can review it before it runs. The CLI flow behind the console button:

aws cloudformation create-change-set \
  --stack-name checkout-api \
  --template-body file://template.yaml \
  --change-set-name bump-instance-type \
  --change-set-type UPDATE            # or CREATE for a brand-new stack, IMPORT to adopt existing resources

aws cloudformation describe-change-set \
  --stack-name checkout-api \
  --change-set-name bump-instance-type   # review Add/Modify/Remove per resource before executing

aws cloudformation execute-change-set \
  --stack-name checkout-api \
  --change-set-name bump-instance-type   # only now does anything actually change

Read the change set's Replacement field as carefully as you'd read Terraform's -/+ markers — a change that looks small in a diff can still force a destroy-and-recreate if it touches an immutable property, and CloudFormation will tell you which resources fall into that bucket before you execute.

Drift detection answers a different question: not "what would change if I applied this template" but "has anything already changed outside CloudFormation." aws cloudformation detect-stack-drift kicks off an asynchronous check that compares each resource's actual configuration to what the template declares, and reports each one as IN_SYNC, MODIFIED, DELETED, or NOT_CHECKED — the last of those matters on the exam, because not every resource type supports drift detection, so a clean drift report doesn't guarantee nothing has drifted. It's a detection tool, not an enforcement one: CloudFormation doesn't auto-correct drift the way a Puppet agent reconciles on its own schedule, so the operational discipline is the same one infrastructure as code already argued for — route every change through the pipeline, and treat manual console edits as incidents, not shortcuts.

Custom resources are the escape hatch for anything CloudFormation doesn't natively model — calling a third-party API, looking up a value only knowable at deploy time, managing a resource type AWS hasn't shipped native support for yet. A custom resource is backed by a Lambda function that CloudFormation invokes on create, update, and delete, and that function must send a SUCCESS or FAILED response to a pre-signed S3 URL CloudFormation provides — miss that step and the stack operation just hangs, IN_PROGRESS, until it eventually times out. The CDK's Provider framework (below) exists specifically to wrap that response-signaling boilerplate so you don't hand-roll it per resource.

StackSets: one template, every account and region

☺ Like you're 10: A stack lives in one account and one region; a StackSet is what turns one template into many stacks at once, all managed from a single place.

A plain stack is scoped to one account and one region. A StackSet takes one template and deploys it as a set of independent stack instances, one per account/region combination you target, all administered from a single operation. This is the exam's answer to "how do I roll out the same baseline VPC, the same guardrail role, or the same logging configuration to every account in the org without writing that logic yourself."

StackSets support two permission models, and the exam expects you to pick the right one for a scenario:

• Self-managed permissions — you create an AWSCloudFormationStackSetAdministrationRole in the account running the StackSet and an AWSCloudFormationStackSetExecutionRole in every target account, and wire the trust relationship between them by hand. Works even for accounts outside AWS Organizations, but every new target account needs that execution role created before it can receive a stack instance.
• Service-managed permissions — StackSets integrates directly with AWS Organizations (once trusted access for CloudFormation StackSets is enabled), manages the IAM roles for you, and can target an entire Organizational Unit instead of an explicit account list. Turn on automatic deployment and a new account that joins the target OU gets the stack instance with zero extra steps — and one that leaves has it removed.

Operation preferences control the blast radius of a StackSet rollout: failure tolerance (how many accounts can fail before the whole operation stops), max concurrent accounts (a count or percentage, capping parallelism), and region concurrency (SEQUENTIAL region-by-region, or PARALLEL across regions at once). Treat these the same way you'd treat a canary's bake time in deployment strategies — a low failure tolerance and modest concurrency turn a bad template into a contained blast instead of a simultaneous failure in two hundred accounts.

The CDK: real code that compiles down to CloudFormation

☺ Like you're 10: The CDK lets you write "make me a bucket" in a real programming language, and it does the tedious job of turning that into the exact CloudFormation JSON underneath.

The AWS Cloud Development Kit (CDK) lets you define infrastructure in TypeScript, Python, Java, C#, or Go instead of hand-writing template YAML — and critically, it doesn't invent a new deployment engine. Running cdk deploy synthesizes your code into a plain CloudFormation template and then deploys it through a change set exactly like the CLI flow above, which means everything already covered on this page — change sets, drift detection, StackSets — still applies to a CDK-managed stack. The CDK is a better front end for CloudFormation, not a replacement for it.

Infrastructure is assembled from constructs at three levels of abstraction. L1 constructs (prefixed Cfn, e.g. CfnBucket) are a direct one-to-one mapping onto a CloudFormation resource type, auto-generated from the CloudFormation resource specification — every property the template supports, no opinions added. L2 constructs (e.g. s3.Bucket) wrap one or more L1 resources with sensible defaults, helper methods, and type-safe property validation. L3 constructs, often called patterns, wire together many resources for a common architecture in one call — aws-ecs-patterns' ApplicationLoadBalancedFargateService provisions a load balancer, a Fargate service, a task definition, and the security groups connecting them from a handful of lines.

import * as s3 from 'aws-cdk-lib/aws-s3';
import * as cdk from 'aws-cdk-lib';

export class ReportsStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new s3.Bucket(this, 'ReportsBucket', {      // an L2 construct
      bucketName: 'acme-billing-reports',
      versioned: true,
      encryption: s3.BucketEncryption.S3_MANAGED,
      removalPolicy: cdk.RemovalPolicy.RETAIN,   // guard against an accidental delete on stack teardown
    });
  }
}

Three commands cover the day-to-day loop: cdk synth renders the CloudFormation template without deploying anything — useful for reviewing exactly what your code produces, or feeding into a StackSet; cdk diff compares that synthesized template against what's actually deployed, the CDK's equivalent of reading a change set before executing it; and cdk deploy synthesizes and deploys in one step. Before any of that works in an account/region pair, cdk bootstrap has to run once, standing up a small support stack — an S3 bucket for template and asset uploads, and the handful of IAM roles the CDK uses at deploy time — conventionally named CDKToolkit. For a CI/CD pipeline that deploys a CDK app across multiple stages and accounts, CDK Pipelines builds on CodePipeline and is self-mutating: if a commit changes the pipeline's own structure — a new stage, a new deployment target — the pipeline updates itself as its first step, before deploying anything else.

Fleet configuration with Systems Manager

☺ Like you're 10: Once a resource already exists, Systems Manager is the crew that keeps it configured correctly, patched, and holding its secrets — without anyone SSHing in by hand.

Where CloudFormation and the CDK answer "does this resource exist," AWS Systems Manager answers the configuration-management half of this domain: keeping a fleet of already-provisioned instances in a known-good state, the same job configuration management already assigned to Ansible, Puppet, and Chef — except delivered as a managed AWS service instead of a tool you operate yourself. Three capabilities are named explicitly on the exam.

State Manager: continuous, scheduled enforcement

State Manager creates an association between a target (a managed instance, a tag, or a resource group) and an SSM document — a JSON or YAML definition of the actions to run, comparable in role to an Ansible playbook or a Puppet manifest. An association carries a schedule, expressed as a rate expression (rate(30 minutes)) or a cron expression, and State Manager re-applies it on that cadence whether or not anything has changed, then reports per-instance compliance. That's the AWS-native version of the pull-based reconciliation model configuration management already covered — an association that fires every 30 minutes and self-corrects drift is functionally the same guarantee a Puppet agent's default 30-minute run gives you, just without an agent server to operate.

Patch Manager: OS and application patching at fleet scale

Patch Manager automates approving and installing patches across a fleet. A patch baseline defines which patches auto-approve for a given operating system — AWS ships predefined baselines per OS, and you can layer a custom baseline with your own approval rules and rejection list on top. A patch group is a tag-based grouping of instances (Key: Patch Group, Value: prod-web) that a baseline attaches to, and a maintenance window schedules exactly when patching is allowed to run against that group, so patching a fleet never means picking a random moment and hoping nothing important is mid-request. Patch Manager reports compliance the same way State Manager does — per instance, per baseline — which is what a Config rule or a dashboard actually queries to answer "how much of the fleet is behind."

Parameter Store: hierarchical configuration, not secret rotation

Parameter Store (part of Systems Manager) holds configuration values in a hierarchical namespace — /prod/checkout/db-host, /prod/checkout/db-password — as one of three types: String, StringList, or SecureString, the last encrypted at rest with a KMS key. Every update creates a new version, and a reference can pin an exact version ({{resolve:ssm:/prod/checkout/db-host:3}}) instead of always resolving to latest. The Standard tier is free and covers most configuration use cases; the Advanced tier costs per parameter per month and unlocks larger values, higher API throughput, and parameter policies like an expiration or a change-notification trigger.

Governing many accounts: Organizations and Control Tower

☺ Like you're 10: Organizations sets citywide rules that no individual building's super can override, no matter how much power that super has inside their own building.

AWS Organizations groups a management account and its member accounts into a tree of Organizational Units (OUs), and is the mechanism StackSets' service-managed permission model builds on. A Service Control Policy (SCP) attached to an OU or account sets the maximum available permissions for everything underneath it — critically, an SCP can only restrict, never grant. An account's actual permissions are the intersection of what its IAM policies allow and what every SCP above it in the OU tree permits; an admin with a wide-open IAM policy still can't call an action an SCP above them has denied. Organizations also enables consolidated billing and the trusted access toggles that let services like CloudFormation StackSets, Config, and GuardDuty operate org-wide instead of per account.

Control Tower automates the multi-account baseline that used to mean assembling Organizations, Config, CloudTrail, and IAM Identity Center by hand: a landing zone with a pre-built OU structure (typically a Security OU and a Sandbox OU out of the box), an Account Factory for provisioning new accounts against that baseline automatically, and guardrails that come in two flavors — preventive guardrails are implemented as SCPs and block a disallowed action outright before it happens, while detective guardrails are implemented as AWS Config rules and flag a non-compliant resource after the fact rather than stopping it. That preventive/detective split is worth memorizing on its own — it's the same distinction compliance as code & policy enforcement covers in vendor-neutral terms, and security & compliance goes deeper on Config rules specifically.

Where this domain's traps live

☺ Like you're 10: Most wrong answers in this domain come from mixing up two similar-sounding AWS features — know which one does what, precisely.

• Nested stacks vs. StackSets — one organizes a single deployment's complexity in one account/region; the other repeats one deployment across many accounts/regions. See the key-idea box above.
• StackSets permission models — self-managed needs manually created IAM roles in every target account and doesn't require Organizations; service-managed needs Organizations trusted access enabled, but grants auto-deployment to accounts joining a target OU for free.
• Parameter Store vs. Secrets Manager — encryption alone doesn't decide it; automatic rotation does. See the warn box above.
• SCPs vs. IAM policies — SCPs never grant permissions, only cap them. A denied action can be denied entirely by an SCP with no IAM policy involved at all.
• Change sets vs. drift detection — a change set previews a future change against the template; drift detection reports on past, out-of-band changes that already happened. They answer different questions and neither substitutes for the other.
• Custom resource response handling — a custom resource's backing Lambda that never signals SUCCESS or FAILED leaves the stack operation hanging until timeout, not failing fast — a classic "why did my stack take an hour to fail" scenario.

Domain 2 is the AWS-native toolbox; Domain 1 is the pipeline that wires it into every merge. Pick that up next in SDLC Automation, or jump straight to the AWS service & command reference if it's the exact CLI syntax you still need drilled in.