CloudFormation Advanced — Overview
CloudFormation is the #1 DOP-C02 topic (113 questions) and appears on SOA-C03 and SAP-C02. The exam goes deep on StackSets (multi-account), drift detection, custom resources, change sets, nested stacks, and CloudFormation Guard for policy-as-code validation.
Organizations integration
Automatic new account deployment
Failure tolerance settings
Compare actual vs template
Resource-level detail
Import resources to fix
Extend CFN capabilities
Non-AWS resources
Complex provisioning logic
Pre-deployment validation
cfn-lint (syntax)
cfn-nag (security)
StackSets — Multi-Account Deployment
| Feature | Details |
|---|---|
| Deployment targets | Specific accounts, OUs, or entire Organization |
| Regions | Deploy to multiple regions simultaneously or sequentially |
| Auto-deployment | Automatically deploy to new accounts added to an OU |
| Failure tolerance | Set max failures per region/account before rollback |
| Concurrency | Max concurrent accounts (percentage or fixed number) |
| Permission model | Self-managed (IAM roles) or service-managed (Organizations trust) |
Exam pattern: “Deploy security baseline to all accounts” → StackSets with Organization auto-deployment to target OU.
Nested Stacks vs Cross-Stack References
| Pattern | How | Best For |
|---|---|---|
| Nested Stacks | Parent stack references child templates (AWS::CloudFormation::Stack) | Modular templates, reusable components (VPC module, DB module) |
| Cross-Stack (Exports) | Stack A exports values, Stack B imports them (Fn::ImportValue) | Independent lifecycle stacks that share values (VPC ID used by App stack) |
- Nested: Updated together as one unit. Parent manages lifecycle. Can’t update child independently.
- Cross-Stack: Independent lifecycles. Can update one without touching the other. But: can’t delete exporting stack while imported.
Change Sets
- What: Preview changes before executing an update (like terraform plan)
- Shows: Resources to be added, modified, or deleted. Whether replacement is needed.
- Replacement types: None (in-place), Conditional (may replace), Always (will delete and recreate)
- Exam note: “Preview impact before deploying” → Create Change Set, review, then execute
Drift Detection
- What: Detects if actual resource configuration differs from template (someone changed manually)
- Shows: Expected vs actual values for each drifted property
- Fix options: Update template to match actual (accept drift) OR import resource to bring under CFN management
- Limitation: Not all resources support drift detection. Some properties are not checked.
- Exam pattern: “Someone manually changed a resource, now updates fail” → detect drift, resolve
Custom Resources (Lambda-backed)
- When: CFN doesn’t support a resource natively, or you need custom logic during provisioning
- How: Define AWS::CloudFormation::CustomResource → triggers Lambda function on Create/Update/Delete
- Lambda responds: Sends SUCCESS/FAILED + response data to CFN-provided signed URL
- Use cases: Populate DynamoDB table on deploy, get latest AMI ID, configure third-party service, run DB migration
- Exam trap: Lambda must respond to the signed URL. If it doesn’t (timeout/error without response), stack hangs for 1 hour.
CloudFormation Guard
- What: Policy-as-code tool that validates templates against rules BEFORE deployment
- Language: Domain-specific language (DSL) for writing rules
- Example rule: “All S3 buckets must have encryption enabled” or “No Security Group allows 0.0.0.0/0 on port 22”
- CI/CD integration: Run in CodeBuild/CodePipeline as a gate — fail deployment if rules violated
- vs Config: Guard prevents deployment (shift-left). Config detects after deployment (reactive).
Other Validation Tools
| Tool | What | Checks |
|---|---|---|
| cfn-lint | Linter for CFN templates | Syntax errors, invalid property values, deprecated features |
| cfn-nag | Security-focused static analysis | Overly permissive IAM, public resources, missing encryption |
| TaskCat | Template testing (deploy to multiple regions) | Actually deploys and validates, then cleans up |
| CloudFormation Guard | Policy validation (custom rules) | Compliance policies, organizational standards, security baselines |
Deployment Strategies with CFN
- Stack policies: Prevent accidental updates/deletions of critical resources (e.g., deny Update on production RDS)
- Termination protection: Prevent accidental stack deletion (must explicitly disable first)
- DeletionPolicy: Retain (keep resource after stack delete), Snapshot (create snapshot), Delete (default)
- UpdateReplacePolicy: What happens when a resource needs replacement — Retain old, Snapshot old, or Delete old
Exam Tips
| Exam | Key Points |
|---|---|
| DOP-C02 | “Deploy to all org accounts” → StackSets. “Preview before update” → Change Set. “Manual change broke stack” → Drift Detection. “Unsupported resource” → Custom Resource (Lambda). “Validate security before deploy” → cfn-nag or Guard. “Modular reusable templates” → Nested Stacks. “Share VPC ID between stacks” → Cross-Stack Exports. “Prevent RDS deletion” → DeletionPolicy: Retain. |
AWS Certification Exam Practice Questions
Question 1:
A company needs to deploy a security baseline (CloudTrail, Config, GuardDuty) to all 200 accounts in their Organization. When new accounts are created, the baseline must deploy automatically. Which approach achieves this?
- Create individual stacks in each account using a script
- CloudFormation StackSets with service-managed permissions, targeting the Organization root OU, with auto-deployment enabled
- Deploy via AWS Config conformance packs to each account
- Use Control Tower account factory blueprints
Show Answer
Answer: B — StackSets with service-managed permissions uses Organizations trust (no manual IAM role setup per account). Targeting the root OU deploys to all accounts. Auto-deployment ensures new accounts added to the OU automatically receive the stack. This is the standard pattern for organization-wide baseline deployment. Control Tower (D) also works but StackSets gives more template flexibility.
Question 2:
A CloudFormation stack update fails with “Resource X has been modified outside of CloudFormation.” The team needs to understand what changed and resolve the issue. Which steps should they take?
- Delete the stack and recreate it from the template
- Run drift detection to identify the differences, then either update the template to match actual state or manually revert the resource to match the template
- Force the update with –continue-update-rollback
- Import the resource into a new stack
Show Answer
Answer: B — Drift detection shows exactly which properties were changed manually (expected vs actual values). Then either: (1) Update your template to accept the manual change (if valid), or (2) manually revert the resource to match the template. Both resolve the conflict. Deleting (A) destroys resources. Force continue (C) may skip the conflicting resource without fixing it.
Question 3:
A team needs to populate a DynamoDB table with seed data every time their CloudFormation stack is deployed. CloudFormation doesn’t natively support writing items to DynamoDB. How can this be achieved within the same stack?
- Use a CloudFormation Init script on an EC2 instance
- Create a Custom Resource backed by a Lambda function that writes items to DynamoDB on the Create event
- Add a UserData script to an EC2 instance in the stack
- Use CloudFormation macros to transform the template
Show Answer
Answer: B — Custom Resources invoke a Lambda function during stack operations (Create/Update/Delete). The Lambda writes seed data to DynamoDB on Create, and optionally cleans up on Delete. This runs within the stack lifecycle — downstream resources can depend on it. Lambda responds with SUCCESS to the CFN signed URL. No EC2 needed (A, C add unnecessary compute).
Related Posts
- CI/CD Pipeline Architecture
- Multi-Account Architecture
- Systems Manager Operations
- IAM Security Architecture
References
Frequently Asked Questions
StackSets vs Control Tower — when to use which?
StackSets: Deploy any CloudFormation template to multiple accounts/regions. Full template flexibility. Use for custom baselines, application infrastructure, or anything CFN can define. Control Tower: Deploys a prescriptive AWS landing zone with guardrails (SCPs + Config rules). Use for initial account governance setup. Many teams use both: Control Tower for governance + StackSets for custom deployments.
What is the difference between cfn-lint, cfn-nag, and Guard?
cfn-lint: Syntax/schema validation (is the template valid?). cfn-nag: Security static analysis (are there security issues?). Guard: Custom policy validation (does it meet OUR organizational rules?). Use all three in CI/CD: cfn-lint first (catch syntax), then cfn-nag (catch security), then Guard (enforce org policies). All run before deployment — shift-left validation.