New: Roadmaps ordered paths through our cheat sheets and flashcards, so you always know what to study next.
Explore themSee what's new on GitHubFrom a single terraform apply to a self-healing, policy-gated infrastructure pipeline.
A 13-step learning path. Follow it in order, or jump to what you need.
This path is for engineers who already know their way around a cloud console and are ready to stop clicking and start committing: provisioning infrastructure as versioned, reviewable code instead of one-off changes nobody can reproduce. Plan on about 6 to 8 weeks at 3 to 5 hours a week, going from Terraform's core workflow to running it the way a platform team does, with tested modules, environment patterns, and policy gates in a pipeline. It stays inside Terraform and its OpenTofu fork in real depth rather than touring every cloud service (see Cloud Engineer) or every DevOps tool in a generalist sweep (see DevOps Engineer). By the end you can write and test a reusable Terraform module, catch drift before it becomes an incident, and wire Terraform into a CI/CD pipeline with policy-as-code checks that block a bad plan before it ever applies.
Expected: basic cloud computing knowledge (what a VPC, IAM role, and managed service are) and comfort with a command line. Helpful but not required: some exposure to Git and CI/CD pipelines.
Open this today and you'll see exactly why teams stopped clicking through consoles: the declarative-versus-imperative vocabulary that every tool in this path, Terraform included, builds from.
This is where state finally clicks: the file mapping your HCL to real resources trips up nearly everyone once, and expect to reread the workflow and state tables here after your first real apply.
Terraform's CLI and HCL from step 2 carry over almost unchanged here, so use this to decide whether your team stays on Terraform's BSL license or moves to OpenTofu's fully open one before you're locked into either.
You can explain why teams stopped clicking through consoles, write and apply your first resource block, and tell whether a team is running Terraform or its open OpenTofu fork. Next up: turning single resources into modules you can actually reuse.
Finish this section to unlock.
+100 XP
Copy-pasting the same VPC block across three projects is what step 2's config blocks eventually punish you for, so this turns repeated resources into versioned, reusable modules you publish once and call everywhere.
A module nobody tests is a module nobody trusts with production, so this adds the native terraform test command and Terratest suites that catch a broken module before step 6 deploys it to three environments at once.
Running the same tested module from step 5 against dev, staging, and production without copy-pasting whole directories is what Terraform workspaces and Terragrunt solve, keeping environment differences to a handful of variables instead of a forked codebase.
Every environment from step 6 will eventually stop matching its own state file, someone always makes a console change under pressure, and this is how you catch that drift before it becomes the outage nobody can explain.
Take this if your role also configures what Terraform provisions: Ansible handles the day-two software setup and patching that a resource block in step 2 deliberately leaves undone.
You can package a tested Terraform module, run it unchanged across dev, staging, and production, and catch drift before it becomes an incident. A few minutes of due flashcards keeps chapter one's state and workflow habits fresh while you build on them here. Next up: getting a pipeline, not a person, to run the apply.
Finish this section to unlock.
+100 XP
Before wiring Terraform into a pipeline, get the shared mental model: build, test, and deploy stages, approval gates, and runners, the same shape step 10 applies to infrastructure changes specifically.
Production Terraform clicks here, not in step 2: instead of anyone running apply from a laptop, a pipeline runs your plan through a Checkov or Sentinel policy gate first, and only an approved plan ever touches real infrastructure; expect the gate to feel slow until it catches its first real mistake.
Choose this path if you're heading toward managing production secrets with the HashiCorp stack: Vault issues the short-lived credentials that step 10's pipeline injects instead of a hardcoded key sitting in your state file.
Reach for this if HCL's declarative syntax has started to feel limiting: Pulumi provisions the same kind of resources from step 2 using real TypeScript, Python, or Go, loops and conditionals included.
Everything up to now, tested modules, environment patterns, drift checks, and policy-gated pipelines, comes together in one loop: Git as the single source of truth, with your infrastructure continuously reconciled to match it and drift self-healed instead of just detected.
You can wire Terraform into a CI/CD pipeline with policy-as-code checks that block a bad plan before it applies, and close the loop with GitOps so infrastructure heals itself back to what Git says it should be. That's the Infrastructure as Code with Terraform badge, earned.
Finish this section to unlock.
+100 XP
Finish every required step, at least 70% of them genuinely done (not skipped), to earn this badge and 500 XP.