Instiq
Chapter 2 · Configuration Management and IaC·v2.1.0·Updated 6/28/2026·~10 min

What's changed: In-scope coverage: added Control Tower, Service Catalog, AWS Proton to s2; OpsWorks, License Manager, EC2 Image Builder to s3

2.2IaC at Scale (StackSets, CDK, SAM)

Key points

Understand deploying across accounts/regions—StackSets, IaC in programming languages (CDK), and SAM for serverless. Deploy infrastructure consistently at organizational scale.

At organizational scale, you must deploy infrastructure consistently across accounts/regions. StackSets and CDK enable this.

2.2.1Means of large-scale deployment

Diagram of IaC at scale: CloudFormation StackSets deploys the same stack to multiple accounts and regions in one operation (integrated with Organizations for auto-deploy to new accounts) at the center; CDK (write IaC in TypeScript/Python, synthesizing CloudFormation) and SAM (concise serverless templates for Lambda/API Gateway) both compile down to CloudFormation templates.
IaC across accounts/regions
  • StackSets: deploy the same stack to many accounts/regions in one operation; auto-apply to new accounts via Organizations integration.
  • CDK: write IaC in programming languages (TS/Python, etc.), synthesizing CloudFormation.
  • SAM: concise serverless templates to define Lambda/API Gateway.
  • All ultimately compile to CloudFormation and are managed declaratively.
Exam point

Common on DOP-C02: bulk deploy across accounts/regions = StackSets, IaC in programming languages = CDK, concise serverless templates = SAM, plus StackSets with Organizations auto-applying to new accounts. StackSets is the go-to for org-wide baselines.

StackSets has two permission models. Self-managed requires you to provide the administration/execution roles (AWSCloudFormationStackSetAdministrationRole / Execution Role) manually; service-managed integrates with AWS Organizations to create roles for you and uses automatic deployment to roll stacks out to accounts newly added to an OU. During rollout you control deployment order (by region) and max concurrency / failure tolerance to limit blast radius. Meanwhile, CDK modularizes infrastructure with constructs (L1 = raw CFn, L2 = higher-level, L3 = patterns), synthesizes CloudFormation via cdk synth, deploys via cdk deploy, and can build self-mutating CI/CD with CDK Pipelines. SAM iterates serverless quickly via sam build/sam deploy and local emulation (sam local), deploying internally through a CloudFormation transform. For testing, CDK uses assertions (snapshot/fine-grained), while CloudFormation templates are statically checked with cfn-lint / cfn-guard (policy as code) / cfn_nag and wired into the pipeline.

MeansWhen to useKey point
StackSets (service-managed)Org-wide baseline rolloutOrg integration; auto-deploy to new accounts
CDKAbstract complex IaC with codeReusable constructs; CDK Pipelines
SAMIterate serverless fastConcise syntax; sam local testing
Plain CloudFormationStrict declarative managementChange sets/drift/stack policy
Note

Scenario: Reliably apply a common security baseline (Config rules, IAM roles) to all current and future accounts in the org. → Use service-managed StackSets targeting OUs. Enabling automatic deployment rolls the same stack out to accounts later added to those OUs. Set region order and failure tolerance to expand safely.

Note

FAQ: CDK or plain CloudFormation? If you want programming abstractions (loops, conditions, types, reuse), use CDK (it synthesizes CFn). If YAML declarations suffice and you want minimal dependencies, use plain CloudFormation. Either way the artifact is a CloudFormation stack, so both benefit from change sets and drift detection.

Warning

Exam trap: Choosing StackSets to "group multiple stacks within a single account and region" is overkill. StackSets is primarily for multi-account/region rollout. For organizing within one account, nested stacks or CDK stack splitting suffice.

2.2.2Services that complement large-scale IaC and governance

In addition to StackSets/CDK/SAM, DOP-C02 in-scope services include tools for multi-account governance automation, distributing approved IaC, and platform-team template management.

Control Tower automatically builds a multi-account landing zone. It combines Organizations, IAM Identity Center (SSO), Config, CloudTrail, and Service Catalog to standardize org-wide governance with guardrails (preventive controls = SCPs; detective controls = Config rules) and an Account Factory (automated new-account provisioning). In a DevOps context, choose it to establish a security and compliance baseline for a multi-account structure with minimum effort.

Service Catalog catalogs approved CloudFormation templates as products, letting users self-service provision resources in a standardized way. A platform team registers products such as "standard VPC" or "approved EC2 config," and development teams deploy by selecting from the catalog—achieving self-service while maintaining governance. In a DevOps context, use it when you want to distribute only admin-approved configurations within the organization.

AWS Proton is an IaC management service where a platform team manages container/serverless deployment environments as service templates, enabling developers to deploy via self-service. It separates environment templates (shared infrastructure) from service templates (app deployment definitions), and updates to templates can automatically propagate to deployed environments. In a DevOps context, it embodies the idea of a platform team managing standard environments while developers deploy independently. Note: AWS Proton stopped onboarding new customers in 2024; for new builds, assemble a self-service platform with Service Catalog or CDK/CloudFormation plus pipelines.

ServiceDevOps roleWhen to choose
==Control Tower==Auto-build multi-account landing zoneEstablish org governance baseline with minimal effort
==Service Catalog==Distribute approved IaC products for self-serviceOffer only approved configs within the org
==AWS Proton==Platform manages templates; devs self-deploySeparate platform and dev team responsibilities
Exam point

DOP-C02 in-scope: automate multi-account landing zone = Control Tower, catalog approved IaC for distribution = Service Catalog, platform manages templates / devs self-deploy = AWS Proton. In a governance context, keep these three services distinct.

2.2.3Section summary

  • Large-scale = StackSets (multi-account/region)
  • Authoring = CDK (languages) / SAM (serverless) → CloudFormation
  • Governance = Control Tower (landing zone) / Service Catalog (approved products) / AWS Proton (template management)

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. You want to deploy/update the same baseline stack across many accounts and regions in one operation. What?

Q2. You want to author infrastructure in TypeScript/Python and synthesize CloudFormation. What?

Q3. You want to define/deploy a Lambda + API Gateway serverless app with concise templates. What?

Check your understandingPractice questions for Chapter 2: Configuration Management and IaC