What You Built in This Module

A configuration file makes infrastructure reproducible the same way a lock file made dependencies and a Docker image made the runtime — and it carries a danger neither of those did: the same apply that creates a resource can destroy a live one, and only the preview ever warns you. Infrastructure clicked together is reproducible by nobody; infrastructure declared in a versioned file is reproducible by anyone who can read it. The discipline that makes the second one safe is reading the plan before the apply, every time.

What you completed

The smallest declared resource came first; each lesson after it took the principle one layer deeper, ending on the failure that makes the whole discipline non-optional:

• The preview is a deterministic diff, not a guess about what might happen. Declarative configuration describes a desired end state, and the plan computes the difference over exactly three inputs — your file, the tool’s recorded state, and a fresh read of reality. Knowing those three inputs is what lets you trust the preview instead of hoping the apply does what you meant.
• Click-ops is “works on my machine” moved up a layer. A clicked environment works on one account, in one region, and is reproducible by nobody who was not in the room. A change made in reviewed, version-controlled code is reproducible by construction — the same cure Docker applied to the application, now applied to what the application runs on.
• The image and the database it talks to do not share a lifetime. Deploying the application and provisioning its infrastructure are different jobs because the image is replaced on every deploy while the database under it must survive all of them. Collapsing the two is fine at trivial scale and quietly catastrophic past it — the deploy that should swap a container instead recreates the data store.
• A one-line edit can become a -/+ that deletes a live database. State is the tool’s fallible memory, drift is the gap that opens when the cloud moves underneath it, and changing a create-time-only field turns an innocuous diff into a destroy-and-recreate. That replacement is visible only in the plan and never in the config — which is the entire reason reading the plan is the discipline, not a formality.

Check your understanding

Work these without scrolling back up. Each one is a new system, not the loan-scoring infrastructure the lessons used — the point is to apply the judgment, not recall the case. Try to answer before opening the hint.

1. You declare a single object-storage bucket for a recommendation service in a configuration file, run the preview, and a teammate asks whether the preview is just a guess about what the tool might do. Explain what the plan actually computes and name the three inputs it compares to produce the diff.

   Hint

   The preview is a deterministic diff, not a guess. Think about the three things it reconciles — your declared file, the tool's recorded state, and a fresh read of reality — and why knowing those three is what lets you trust the preview.

2. A colleague provisioned the recommendation service’s queue and cache by clicking through the cloud console, and now nobody can recreate that environment in a second region. Explain why click-ops is “works on my machine” moved up a layer, and what a reviewed, version-controlled configuration gives you that the clicked environment cannot.

   Hint

   A clicked environment is reproducible by nobody who was not in the room. Think about the same cure Docker applied to the application, now applied to what the application runs on — reproducible by construction because it is code under review.

3. A teammate proposes putting the recommendation service’s container image and its production database in the same deploy step “to keep it simple.” Explain why the application and its infrastructure do not share a lifetime, and the specific catastrophe that collapsing them invites past trivial scale.

   Hint

   The image is replaced on every deploy; the database under it must survive all of them. Think about what happens when a deploy meant to swap a container is wired to also manage the data store — the deploy that should replace a container recreates the database.

4. You make a one-line edit to a create-time-only field on the recommendation service’s live database — say its instance identifier — and run the preview. It shows a -/+. Explain what that symbol means, why state and drift make it possible, and why this is the case that makes reading the plan non-optional rather than a formality.

   Hint

   A `-/+` is destroy-and-recreate, not an in-place update. Think about why a create-time-only field forces replacement, how state is the tool's fallible memory and drift the gap that opens when the cloud moves underneath it, and why the replacement is visible only in the plan and never in the config.

What it adds up to

This module completes the reproducibility thread that ran through the whole track: dependencies, then runtime, then the infrastructure underneath. The same lesson held at every layer — a thing set up by hand is reproducible by nobody, and a thing declared in a versioned file is reproducible by anyone. The system you can now stand up does not depend on one person remembering what they clicked; it depends on a file anyone can read, review, and apply, with a preview that shows every consequence before it lands.

What comes next

Your system now runs, reachably and reproducibly. What you cannot yet do is tell when it is failing — especially the failure that returns 200 OK while quietly serving wrong predictions. A deployed, reproducible service that nobody is watching is a service that breaks silently. The next module makes the system observable: the metrics that show it is healthy, the drift detection that catches a model going stale, and the alerting that pages you on the right signal instead of on noise.