Amazon Web Services services
19 / 24
Amazon Web Services

Infrastructure as Code — CloudFormation, CDK & Terraform

Define infrastructure in version control so environments are reproducible and changes are reviewable.

Infrastructure defined in files, applied by a tool, kept in git.

Architectural drawings rather than a building put up from memory. Anyone can read them, changes are marked up and approved, and the same plans raise an identical building elsewhere.

Key Concepts

1
    CloudFormation  AWS-native, YAML/JSON, free, manages state for you
    CDK             write TypeScript or Python, synthesises to
                    CloudFormation. Loops and types instead of YAML.
    Terraform       multi-cloud, HCL, you own the state file
2
Why it matters in an interview. Clicking in the console produces an environment nobody can reproduce, and no record of who changed what. A template is reviewed, diffed and rolled back like code.
3
A change set shows you what will happen before it happens:
4
    + aws_lb                  will be created
    ~ aws_autoscaling_group   desired 2 -> 4      (update in place)
    - aws_db_instance         will be DESTROYED   <-- stop here
5
That last line is the point. Some property changes force replacement, and for a database that means data loss. Reading the plan is the skill.
6
Drift is what happens after someone edits in the console. The template and reality diverge, and the next deploy either reverts the fix or fails. Drift detection reports it; discipline prevents it.
7
State is where Terraform differs. CloudFormation tracks state inside the service; Terraform keeps a state file you must store remotely — S3 with DynamoDB locking — or two engineers applying at once will corrupt it.
8
CDK suits complex setups because it is a real language:
9
    for (const env of ['dev', 'staging', 'prod']) {
      new ApiStack(app, `api-${env}`, { instanceCount: env === 'prod' ? 6 : 1 });
    }
api-${env}
10
The same loop in YAML is copy-paste, and copy-paste is where environments drift apart.
11
Keep stacks small and layered. Network, data and application in separate stacks, exporting values between them. One enormous stack means every change risks everything and updates take an hour.
12
Rollback is automatic in CloudFormation on a failed update, which is a real safety net — and the reason a stack can get stuck in UPDATE_ROLLBACK_FAILED when the rollback itself cannot proceed.
UPDATE_ROLLBACK_FAILED
13
What the interviewer is probing.1. "What do you look for in a plan before approving it?" Probing: the dangerous line. Stalls: "That it works." Moves up: anything marked for replacement — some property changes destroy and recreate, and for a database that is an empty database.
14
2. "What is drift and why does it matter?" Probing: console edits. Stalls: "Nothing serious." Moves up: someone changed a resource by hand, so the template and reality diverge and the next deploy either reverts the fix or fails.
15
3. "CDK or raw CloudFormation?" Probing: when the abstraction earns itself. Stalls: "CDK always." Moves up: CDK when there is enough repetition that YAML becomes copy-paste, since loops and types prevent environments drifting apart; it compiles to CloudFormation either way.
16
4. "Where does Terraform state belong and why?" Probing: the locking requirement. Stalls: "In the repository." Moves up: remote, in S3 with DynamoDB locking — two engineers applying at once otherwise corrupt it, and the file contains secrets.
Use cases:cloudformationcdkterraformdriftchange-set