AWS Certified CloudOps Engineer - Associate (SOA-C03) #7 Domain 3-1 Deployment — CloudFormation in Depth and IaC

Through #6, we wrapped up the reliability domain. The third domain is deployment, provisioning, and automation (22%), and at its center is IaC (Infrastructure as Code). The reason IaC matters in operations is simple. An environment built by hand in the console is not reproducible, and there is no tracking of who changed what. CloudFormation is AWS’s native IaC tool — it declares infrastructure as a template (code) and manages its state.

Stacks and templates #

When you delete a stack, the resources it created are cleaned up along with it. This is the decisive difference from a hand-built environment. Creation, update, and deletion are managed as a single unit.

Main template sections #

Use Parameters to absorb differences between environments, and use Outputs with cross-stack references (Export/ImportValue) to split and assemble stacks. The answer to “separate and connect a VPC stack and an application stack” is Outputs export + ImportValue.

Change sets (Change Set) and drift #

These are the two most important features in operations.

Change set #

A feature that previews what will change before you update a stack. In particular, some changes replace a resource (replacement), causing downtime or data loss (e.g., changing certain RDS attributes). Confirming whether a replacement will happen with a change set before applying is safe operations. The answer to “you’re updating a production stack — verify the scope of impact in advance” is a change set.

Drift detection (Drift Detection) #

When someone changes a resource the stack created directly in the console, the actual state diverges from the template. This is drift. Drift detection compares the template against the actual resources and reports the resources and attributes that have diverged. The answer to “it’s an IaC-built environment, but find who changed it by hand” is drift detection.

Stack protection mechanisms #

A regular in operations is DeletionPolicy: Retain. Since a database or S3 bucket must not disappear along with the stack when it’s deleted, you apply Retain to that resource to preserve it.

StackSets: multi-account and multi-region deployment #

A feature that deploys and manages a single template across multiple accounts and multiple regions at once.

• Integrates with Organizations to automatically deploy a standard stack to new accounts
• Applies a security baseline (IAM roles, logging, Config) across all accounts in one go
• Updating in one place propagates to all targets

The answer to “lay down standard security settings consistently across all accounts in the organization, and apply them automatically to new accounts too” is StackSets (+ Organizations).

Other IaC tools: CDK and Terraform #

SOA-C03 also brings tools beyond CloudFormation into scope. Here’s how they relate.

The key distinctions are that CDK is ultimately converted into CloudFormation for deployment, and that Terraform also handles resources outside AWS and manages state in its own file. “I want to write infrastructure in a development language but use AWS-native deployment” is CDK; “manage multiple clouds with one tool” is Terraform.

Exam question patterns #

• Verify impact before a stack update → change set (Change Set)
• Track manual changes in an IaC environment → drift detection
• Preserve DB/S3 when deleting a stack → DeletionPolicy: Retain
• Protect specific resources during an update → Stack Policy
• Standard deployment across all accounts/regions → StackSets + Organizations
• Split and connect stacks → Outputs Export + ImportValue
• Write IaC in a development language, deploy AWS-native → CDK

Common Pitfalls #

1) Thinking an update is always zero-downtime #

Some attribute changes replace the resource. You need to preview whether a replacement will happen with a change set.

2) Mistakenly thinking CloudFormation automatically blocks drift #

CloudFormation only detects and reports drift — it doesn’t block manual changes in the console themselves. To block changes, restrict direct modification with IAM permissions.

3) Creating a separate stack per account without StackSets #

Deploying the same stack to dozens of accounts by hand is the wrong answer when the requirement is to minimize operational burden. StackSets is the standard.

4) Thinking CDK is a separate runtime #

CDK generates a CloudFormation template at the synthesis step. Deployment, drift, and rollback use CloudFormation’s as-is.

Summary #

What we covered in this post:

• CloudFormation declares infrastructure as a template (code) and creates, updates, and deletes it at the stack level
• Use a change set to confirm update impact (especially resource replacement) in advance, and drift detection to track manual changes
• Use DeletionPolicy: Retain to preserve DB/S3 when a stack is deleted. Protect with Stack Policy and Termination Protection
• Use StackSets + Organizations for standard bulk deployment across multiple accounts and regions
• CDK synthesizes into CloudFormation; Terraform is multi-cloud + its own state

Next: Domain 3-2 Systems Manager #

Now that we’ve covered how to deploy infrastructure as code, next are the tools for operating and managing the deployed instances.

In #8 Domain 3-2 Deployment: Systems Manager Operations Automation, I’ll cover how to manage configuration with Parameter Store, how to apply patches in bulk with Patch Manager, how to maintain a desired state with State Manager, how to connect without keys using Session Manager, and tie in Run Command and Automation as well.