Infrastructure as reviewable, version-controlled code — the foundation the whole track has been standing on.
Your win: explain what Infrastructure as Code is and why it beats clicking
cloud consoles, and describe Terraform's declarative model and the write → plan → apply loop —
which will feel familiar after Kubernetes.
The problem: infrastructure by hand doesn't scale
Someone has to create the GKE clusters, the VPC, the buckets, the databases, the
service accounts that Courses 2–6 assumed already existed. Do it by clicking the GCP console and
you get: no record of what was done, no review, no reproducibility (was prod set up the same as
staging?), and no undo. Infrastructure as Code fixes this — you define
infrastructure as code, checked into git, reviewed in PRs, and applied by a
tool.1
Terraform is declarative — you'll recognize this
Terraform (HashiCorp's IaC tool) is declarative: you
describe the desired end-state ("a cluster with these node pools, a bucket with these
settings"), not the step-by-step commands to build it. Terraform figures out what to create,
change, or destroy to make reality match.2
You already know this idea
This is exactly the Kubernetes model from Course 2 — declare desired state, a system
reconciles reality toward it — applied to cloud resources instead of Pods. Terraform
is to GCP what a Deployment manifest is to a cluster. If declarative desired state clicked for
K8s, it clicks here for free.
The core loop: write → plan → apply
write .tf config (desired state, in HCL)
│
▼
terraform plan ── diff config against STATE ──► "+ create cluster, ~ change bucket, - drop SA"
│ (a human reviews the preview)
▼
terraform apply ── make exactly those changes ──► real infrastructure + updated state
Plan-before-apply is the safety gateterraform plan shows you exactly what will change before anything
happens — the create/update/destroy list. That "destroy" column is why you
always read a plan: a careless config change can propose deleting a database. Plan is the
"measure twice"; apply is the "cut once." Reviewing plans is the single most important IaC
habit.
Anchor — IaC in this repo
All the infrastructure the track runs on lives in
deployments/terraform/, split into modules
(reusable definitions, 34 of them) and live (per-cell configs) — with
Terragrunt on top (Lesson 5). It provisions the GKE clusters (Course 2), the
VPC, Cloud SQL, the KMS keys (SOPS, Course 3), and the Workload Identity bindings (Courses
3–6) — the "where does this come from?" answer to six courses of infra. And it's applied not
by hand but through Atlantis on pull requests (Lesson 12) — plan on open,
apply on approval.
Backend use case
Backend use case: this is the foundation behind the GKE clusters, Cloud SQL instances, KMS keys, state buckets, and Workload Identity bindings referenced across the whole infra track.
Common mistake
Common mistake: treating Terraform like a cloud CLI script runner instead of a declarative desired-state tool with a plan/apply discipline.
Read this next
Terraform — What is IaC? + the core workflow
The declarative model and the write/plan/apply loop, from HashiCorp.
In plain English
Plain English: Infrastructure as Code means the clusters, buckets, identities, and keys are described as reviewable code instead of being created by hand in a console.
Check yourself (from memory)
Q1. Terraform's model is best described as…
You declare the end-state; Terraform computes the create/
change/destroy actions — the Kubernetes idea, for cloud resources.
Q2.terraform plan is important because it…
It shows the create/change/destroy list to review —
catching, e.g., an accidental database deletion before apply.
Q3. IaC beats clicking the console mainly because it's…
Code in git = a record, PR review, and identical envs. Console
clicks leave no trail and drift apart.
What is IaC, Terraform's model, and the core loop?
recall, then click to reveal
IaC = infrastructure defined as VERSION-CONTROLLED CODE — reviewable,
reproducible, auditable (vs console clicks: no record/review/undo, envs drift). TERRAFORM is
DECLARATIVE: you describe the DESIRED END-STATE (HCL), it computes create/change/destroy to
converge — the SAME idea as Kubernetes (Course 2), for cloud resources. CORE LOOP: write .tf →
terraform plan (preview the diff vs STATE — read the DESTROY column!) → apply
(make exactly those changes + update state). Plan-before-apply = the safety gate. REPO:
deployments/terraform/{modules,live} (Terragrunt) provisions the clusters/VPC/
Cloud SQL/KMS/Workload Identity of Courses 2–6; applied via Atlantis on PRs, not by hand.
Want to see a real terraform plan output, or why declarative beats a bash script
of gcloud commands? Ask me — providers & resources are Lesson 2.