Skip to main content

Module 2: Infrastructure as Code: Mistake Clinic

This clinic turns wrong moves into reusable judgment. Use it after each practice page and again before the quiz or checkpoint.

Module-Specific Mistake Radar​

Start with these traps. Replace or extend them with real mistakes from your own work.

Mistake to look forWhere it shows upSymptomRepair evidence
Finishing First Terraform Module Lab with only a final answerFirst Terraform Module LabThe work has no failed case, trace, test, proof gap, or design stress point.Add the smallest broken example and show the repair that changes the result.
Finishing Modularity and State Workshop with only a final answerModularity and State WorkshopThe work has no failed case, trace, test, proof gap, or design stress point.Add the smallest broken example and show the repair that changes the result.
Finishing Refactoring and Import Clinic with only a final answerRefactoring and Import ClinicThe work has no failed case, trace, test, proof gap, or design stress point.Add the smallest broken example and show the repair that changes the result.
Finishing IaC Katas with only a final answerIaC KatasThe work has no failed case, trace, test, proof gap, or design stress point.Add the smallest broken example and show the repair that changes the result.
Treating Declarative vs Imperative Infrastructure as vocabulary instead of a toolDeclarative vs Imperative InfrastructureThe explanation names the concept but cannot decide between two cases.Write one example, one non-example, and the rule that separates them.
Treating State: The Ground Truth and Its Hazards as vocabulary instead of a toolState: The Ground Truth and Its HazardsThe explanation names the concept but cannot decide between two cases.Write one example, one non-example, and the rule that separates them.

Practice Mistake Checks​

Pull any miss from these checks into your mistake log.

First Terraform Module Lab​

Source: practice/01-first-terraform-module-lab.md

Identify and fix the error in each:

  1. terraform apply run without a saved plan in a team setting. (what guarantee is lost?)
  2. provider "aws" { region = "us-east-1" } repeated in every module. (what belongs at the root vs inside a module?)
  3. variable "env" { type = string } with no validation. (what bug does this invite?)
  4. resource "aws_s3_bucket" "b" { bucket = "logs" } with no tags. (what breaks first in an org with cost attribution?)
  5. terraform destroy run to "clean up" a prod environment. (what you should do instead, and why.)

Modularity and State Workshop​

Source: practice/02-modularity-and-state-workshop.md

Identify and fix:

  1. A reusable module contains provider "aws" { region = "us-east-1" }.
  2. envs/prod/main.tf and envs/dev/main.tf each have a different set of inputs to the module -- but one of them silently has a different resource schema.
  3. Two engineers committed terraform.tfstate to git "so both could use it."
  4. The DynamoDB lock table is acme-tf-locks, but the backend config for envs/prod/ was copy-pasted from envs/dev/ and still points at acme-tf-locks-dev. Why is this dangerous?
  5. terraform workspace new prod is used as the prod environment. What operator surprise is likely in the first year?

Refactoring and Import Clinic​

Source: practice/03-refactoring-and-import-clinic.md

Identify and fix:

  1. moved { from = module.a.x to = module.b.x } where module a still exists and has its own x. What happens?
  2. An import block whose id is wrong (typo). Plan looks fine -- what does apply do?
  3. Renaming with terraform state mv in one engineer's terminal instead of using a moved block in code. What does the next PR reviewer see?
  4. An engineer saw replaced in a plan for production RDS and apply'd anyway because the PR description said "no-op." What is the process failure, not the engineer failure?
  5. prevent_destroy = true was added to a bucket, then an engineer removed it with a one-line PR to let destroy proceed. How do you prevent this pattern?

Repair Protocol​

For each real mistake:

  1. Reproduce the failure on the smallest example, trace, proof, query, command, or design sketch.
  2. Name the hidden assumption.
  3. Repair the artifact.
  4. Save evidence that changed: failing then passing test, corrected proof step, revised diagram, safer command, benchmark, or review note.
  5. Add one retrieval card beginning with Check... before... or Do not use... when....

Mistake Log​

DateMistakeSymptomRoot causeRepair evidenceRetrieval card
StarterPick one radar row aboveExplain how it would fail in this moduleName the assumptionAdd a counterexample or corrected artifactWrite the card before closing the page

Completion Standard​

  • At least five real mistakes are logged.
  • At least two mistakes include a counterexample or failing test.
  • At least one mistake connects to an older semester skill.
  • At least one correction changes code, a proof, a diagram, a command transcript, a query, or a design decision.