Amazon Web Services
Infrastructure as Code — CloudFormation, CDK & Terraform
Manage AWS infrastructure as code with CloudFormation, CDK or Terraform, and know the guards that stop a template change from replacing a production database.
On AWS there are three mainstream ways to keep infrastructure in version control.
A builder's quote before any work starts. It lists every wall to be knocked down, and the one line that says "remove load-bearing wall" is the line you read twice.
Key Concepts
1
CloudFormation AWS-native, YAML or JSON; AWS keeps the state
CDK TypeScript, Python, Java or Go that synthesises
to CloudFormation -- loops and types, not YAML
Terraform multi-cloud, HCL; you keep the state file2
A change set is CloudFormation's preview. Create one, read it, then execute it. Every resource change carries a Replacement value — True, False or Conditional — and a True beside a database is the line that matters: some property changes, such as renaming the instance, can only be applied by creating a new resource and deleting the old.
ReplacementTrueFalseConditional
3
CloudFormation has three separate guards for stateful resources, and naming them is what marks out someone who has run it:
4
DeletionPolicy Retain or Snapshot when the resource is
removed from the stack, or the stack deleted
UpdateReplacePolicy the same, when an update forces replacement
DeletionProtection a property on RDS and others: the service
API itself refuses the delete5
Add a stack policy to forbid updates to named resources altogether, and termination protection to stop the whole stack being deleted.
6
Drift detection compares each stack with the live resources and reports what someone changed by hand. Whether the next deploy then overwrites that fix or fails, the template is the truth and the console edit was the bug.
7
CDK earns its place through repetition. Constructs package good defaults — an L2 bucket that blocks public access and encrypts by default — and loops replace copy-pasted YAML. cdk diff shows the CloudFormation changes before deploying.
cdk diff
8
StackSets deploy one template across many accounts and regions, which is how guardrails — logging, config rules, baseline IAM roles — reach every account in an AWS Organization.
9
Terraform on AWS keeps its state in S3. Recent Terraform releases can lock that state natively with use_lockfile, so a DynamoDB lock table is no longer needed; either way the state must be remote, versioned and locked, because it holds secrets and two concurrent applies corrupt it.
use_lockfile
10
What the interviewer is probing.1. "How do you stop a template change from destroying the production database?" Probing: CloudFormation's guards. Stalls: "Be careful with changes." Moves up: read the change set for Replacement: True, and set DeletionPolicy and UpdateReplacePolicy to Snapshot plus DeletionProtection on the instance — so even a mistaken replacement leaves a snapshot and the API refuses the delete.
Replacement: TrueDeletionPolicyUpdateReplacePolicySnapshotDeletionProtection
11
2. "Someone fixed an incident by editing a security group in the console. What now?" Probing: drift. Stalls: "Leave it, it works." Moves up: run drift detection, put the fix into the template, and deploy it — otherwise the next stack update silently reverts the fix.
12
3. "CDK or raw CloudFormation?" Probing: when the abstraction earns itself. Stalls: "CDK always." Moves up: CDK when there is enough repetition or logic that YAML turns into copy-paste; it synthesises to CloudFormation either way, so cdk diff and change sets still apply.
cdk diff
13
4. "How would you put the same baseline into eighty accounts?" Probing: multi-account scale. Stalls: "Run the template in each account." Moves up: CloudFormation StackSets with service-managed permissions targeting AWS Organizations units, so new accounts receive the baseline automatically.