1. Infrastructure as Code — The Big Idea
Before Terraform, "infrastructure" meant clicking through a cloud console, or running one-off scripts that nobody remembered a year later. Infrastructure as Code (IaC) means you write the desired end-state in text files, commit them to Git like any other code, and a tool makes reality match the text.
📐 Analogy: A cloud console click-fest is like building a house with no blueprint — it works, but nobody can rebuild it identically, and nobody remembers why that one wall is there. Terraform is the blueprint. Anyone can read it, review it, version it, and hand it to a different builder (engineer) who gets the exact same house.
✅ Key point: Terraform is declarative — you state WHAT you want ("3 web servers, 1 database"), not HOW to get there step by step. Terraform itself works out the order of operations and the exact API calls.
2. The Core Loop — Animated
Press ▶ Play and watch what happens when you run terraform apply for the first time:
Ready — press Play to run "terraform apply".
3. What Happens in Each Step
| # | Step | What actually happens |
|---|---|---|
| 1 | Read config | Terraform Core parses every .tf file in the folder and builds an internal graph of everything you want. |
| 2 | Load provider plugin | For each provider block (AWS, Azure, GCP...), Terraform downloads and talks to a plugin that knows that cloud's API. |
| 3 | Compare to state | Terraform checks terraform.tfstate — its record of what it built last time — to see what's new, changed, or gone. |
| 4 | Call the real API | The provider plugin translates your resource block into actual AWS/Azure/GCP API calls that create real infrastructure. |
| 5 | Save the new state | Once the resource exists, Terraform records its real ID and attributes in terraform.tfstate — this is how it will recognize it next time. |
⚠️ Terraform never "remembers" your infrastructure by reading the cloud fresh every time. It trusts the state file. Lose the state file, and Terraform thinks nothing exists — even though your servers are still running and costing money. Chapter 4 is entirely about this.
4. The Four Commands You'll Type Constantly
# One-time setup per folder — downloads provider plugins terraform init # Preview — what WOULD change, without touching anything terraform plan # Actually make it happen terraform apply # Tear it all down when you're done (labs, temporary environments) terraform destroy
🍕 Analogy:
init = stock the kitchen with the right tools for this recipe. plan = read the recipe out loud before cooking anything ("this will add 2 eggs, remove the old flour"). apply = actually cook it. destroy = clear the plates — safely, on purpose, all at once.5. Vocabulary You'll See Everywhere
| Term | Meaning | Analogy |
|---|---|---|
| Provider | Plugin that knows how to talk to a specific API (AWS, Azure, GCP, GitHub, Kubernetes...) | A translator for one language |
| Resource | One real-world object Terraform manages (a VM, a database, a DNS record) | One line item in the blueprint |
| State | Terraform's record of what it has already built | The builder's own notebook |
| Plan | A preview of exactly what will change before it happens | A dry run / read-aloud of the recipe |
| Apply | Actually executing the plan against real infrastructure | Cooking the meal |
| Idempotent | Running apply again with no config changes does nothing — already matches | "Already done? Skip it." |