What This Module Covers

I inherited a production environment once that lived entirely in one engineer’s memory. It had been clicked together in a console months earlier, it ran fine, and when we needed a second copy of it for staging nobody could reliably reproduce what the first one was. Every setting was a decision someone had made and not written down. That is the failure this module exists to prevent: the previous module’s deploy worked once, on one account, set up by one person who remembers what they did, and the infrastructure lives nowhere in code. This module makes the infrastructure itself reproducible the way Docker made the application reproducible — declared in a file, versioned, and reviewable.

What this module is

Infrastructure as Code means describing the cloud resources your system needs — the host, the network, the database — in a configuration file the way you describe your application’s dependencies in a lock file, then letting a tool make reality match the file. The principle is declarative: you write the desired end state, not the click-by-click steps to reach it, and the tool computes the difference between what you wrote and what exists.

This module teaches that principle, not a specific tool’s syntax. It uses Terraform-shaped examples because they make the ideas concrete, but the judgment it builds — declare the end state, preview before you apply, keep the application and its infrastructure as separate concerns, and respect state as a fallible source of truth — transfers to any IaC tool. The danger that makes this its own skill is the last lesson: the same apply that creates a resource can destroy a live one, and only the preview ever shows it coming.

What you will learn

The module moves through four lessons, from the smallest real thing that works to the failure mode that makes IaC dangerous enough to need its own discipline.

• Declare one resource and apply it. Write a tiny declarative config for one real resource, preview the change, and apply it — watching the tool create exactly what the file says. You will learn that declarative configuration is a description of a desired end state, not a script of steps, and that a preview is a deterministic diff over three inputs: your config, the tool’s recorded state, and a fresh read of reality.
• Why click-ops is the “works on my machine” of infrastructure. A clicked-together environment works on one account, in one region, and cannot be reproduced anywhere else. You will name this as the same disease Docker cured for the application, moved up one layer, and see why a change made in code — reviewed, logged, version-controlled — is reproducible by construction while a clicked change is reproducible by nobody.
• Application vs. infrastructure: two things you deploy. Deploying the application and provisioning the infrastructure it runs on are two different jobs with two different lifetimes. You will learn why a staff engineer keeps them apart — the image is replaced on every deploy, but the database underneath it must survive — and why collapsing the two is fine at trivial scale and dangerous past it.
• State, drift, and the apply that destroys. State is the tool’s memory of what it built, and memory goes stale when the cloud moves underneath it. You will learn how drift opens between state and reality, and why a one-line edit to a create-time-only field on a stateful resource turns into a -/+ replacement that deletes a live database — visible only in the plan, never in the config.

The module ends with a project against your own cloud account: an infra/ directory in the repo you carry, declaring the resources your deployed Census Income service runs on — a real config, a real plan read before a real apply, the application and infrastructure held apart, and the clicked M8 setup replaced by code. The lessons walk the idea on worked examples; the project is where you write and apply the config yourself, against a rubric that maps line by line to these lessons.

How it builds on what came before

This module is the reproducibility thread reaching its top layer. The Python module (M1) made dependencies reproducible with a lock file; the packaging module (M5) made the runtime environment reproducible with a Docker image; the cloud-deployment module (M8) put that image live, but by running CLI and console steps that live nowhere in code. This module makes the infrastructure those run on reproducible with a config file. The same lesson recurs at each layer: a thing set up by ad-hoc steps is reproducible by nobody, and a thing declared in a versioned file is reproducible by anyone. The live deployment you stood up in M8 is exactly what this module teaches you to declare instead — so the environment your service runs in can be rebuilt as reliably as the image that runs in it.

What you will be able to do

By the end you will write a declarative configuration for a real resource, preview the change as a diff before it happens, and apply it; explain why a clicked-together environment cannot be reproduced and a declared one can; keep the application and its infrastructure as separate, separately-lifetimed concerns; and read a plan for the -/+ replacement lines that mean a stateful resource is about to be destroyed and recreated. The thread through all four lessons is the same: the file is the source of truth, the plan is where consequences become visible, and reading it before you apply is the discipline that separates infrastructure as code from infrastructure by accident.