Lesson 17 of 30

Infrastructure as Code with CloudFormation

Q: Your team currently sets up staging and production infrastructure by clicking through the AWS console, and the two environments have quietly drifted apart. How would you fix this with CloudFormation, and what would you build into the process to keep it from happening again?

A strong answer covers: Proposes capturing the infrastructure as a declarative template and deploying it as a stack per environment, so both environments come from the same source of truth; Explains that a stack ties resources together as a managed unit, and that deleting or reviewing it is safer than reasoning about untracked, manually-created resources; Uses change sets as a review gate before applying updates, treating it like reviewing a diff before merging; Identifies the real fix for future drift as process discipline (all changes go through the template) rather than just detecting drift after the fact.

Clicking through the console to create a bucket works fine — once. The moment infrastructure needs to exist twice, identically, on demand, clicking stops being the answer.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

What does it mean that a CloudFormation template is 'declarative' rather than a script?

It describes the desired end state of resources, and CloudFormation figures out the steps to reach itIt's a list of AWS CLI commands executed in the exact order they're writtenIt only works for read-only resources like tags, not resources that actually get created

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Infrastructure as Code with CloudFormation

What interviewers actually ask about this, and what a strong answer has to cover.

Your team currently sets up staging and production infrastructure by clicking through the AWS console, and the two environments have quietly drifted apart. How would you fix this with CloudFormation, and what would you build into the process to keep it from happening again?

A strong answer covers

Proposes capturing the infrastructure as a declarative template and deploying it as a stack per environment, so both environments come from the same source of truth
Explains that a stack ties resources together as a managed unit, and that deleting or reviewing it is safer than reasoning about untracked, manually-created resources
Uses change sets as a review gate before applying updates, treating it like reviewing a diff before merging
Identifies the real fix for future drift as process discipline (all changes go through the template) rather than just detecting drift after the fact

Likely follow-ups

Three weeks after migrating to CloudFormation, someone on-call makes an emergency manual fix directly in the console to unblock an incident. What's now true about that stack, and what should happen next?
Why is a change set actually meaningfully safer than just running the update and seeing what happens, given that most updates are probably fine?

The plain-language idea

CloudFormation is AWS's declarative infrastructure tool: you write a template (JSON or YAML) describing the resources you want to exist and their configuration, and CloudFormation figures out how to make reality match it — creating, updating, or deleting whatever's needed. Declarative here means the template says what should exist, not the sequence of API calls to run — the same distinction as declarative UI (describe the desired state) versus imperative scripting (describe the steps).

A template deployed becomes a stack — a named, tracked collection of resources CloudFormation manages together as one unit. Delete the stack, and everything it created is torn down with it, which is exactly why a stack is safer to reason about than a pile of manually-created resources nobody's sure they can safely delete.

See it in a real thing: a template, a change set, and drift

Resources:
  UploadsBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-app-uploads
      VersioningConfiguration:
        Status: Enabled

This template, deployed as a stack, creates one versioned S3 bucket. Deploy the identical template again in a staging account and a production account, and both environments get the same bucket configuration — no manual clicking, no environment silently drifting from what the last person who set it up remembered to configure. Before an update actually applies, CloudFormation can generate a change set: a preview of exactly what will be added, modified, or replaced, reviewable before anyone commits to it — the infrastructure equivalent of reviewing a diff before merging.

What people usually miss

Watch out

A template describes desired end state, not a sequence of steps. CloudFormation itself works out the order of operations (what has to be created before what, what needs replacing versus updating in place) — authors don't write "first create the VPC, then the subnet"; they declare both resources and their relationships, and CloudFormation sequences it.
Deleting a stack deletes everything it manages, by default. This is the safety CloudFormation is built around — no orphaned resources nobody remembers creating — but it also means a stack deletion is a genuinely destructive action deserving the same caution as any bulk-delete operation, not a casual cleanup step.
A change set is a preview, not a commit. Generating one doesn't apply anything — it has to be explicitly executed after review, which is what makes it a real safety gate rather than just informational output that's easy to skip past.
Drift isn't detected automatically in real time. CloudFormation doesn't watch for manual changes as they happen — drift detection has to be explicitly run (or scheduled) to compare current resource state against the template, so a manually-changed resource can sit undetected for a long time unless someone actually checks.

Why this matters in interviews

"How would you make sure staging and production actually have the same infrastructure?" tests whether a candidate reaches for a template-and-stack model with change sets as a review gate, versus manually replicating console clicks and hoping nothing was missed or drifted since.