Terraform Muscle Memory: Practice init, plan and apply Without a Cloud Account

#gitops #iac #devops #terraform

The awkward thing about learning Terraform is that most tutorials assume a cloud account, and a cloud account is exactly what a beginner should not point Terraform at. The gap between "read the docs" and "safely ran apply fifty times" is where the confidence comes from, and it is the gap most people never cross before their first work ticket says terraform plan.

You can cross it in a browser. Below is a practice path built on a simulated Terraform project, plus a second simulator for the part that comes after Terraform works: keeping deployed state honest over time. Disclosure: I help build these; both are free, browser-based, no signup, no AWS bill.

The loop that is the whole job

Terraform's day-to-day is one loop: change code, preview the diff, apply it, verify. The Terraform Terminal Simulator drills exactly that loop against a fake project with simulated infrastructure (you will meet a VPC with an id like vpc-04e9f2a1 that costs nobody anything). The guided sequence:

Initialize: terraform init, and what actually happens: providers download, the backend gets configured. The lesson has you run terraform validate here too, the cheap syntax-and-consistency check that belongs before every plan.
Plan: terraform plan, reading the diff before it is real. Learning to actually read a plan, not skim it, is the most transferable habit in IaC.
Apply: terraform apply, creating the simulated resources. (In real Terraform, bare apply stops for a yes/no confirmation and -auto-approve skips it; the simulator accepts both forms, and the flag is one to distrust until CI is the one running it.)
Make a change: edit, re-plan, and watch the diff show a modification instead of a creation. This is the moment Terraform's model clicks: you declare the destination, it computes the route.
Inspect state: terraform state list and terraform output, because the state file is Terraform's memory, and querying it is how you check what Terraform thinks exists.
Tear down: terraform destroy, the command that makes experiments reversible, practiced here where it can destroy nothing.

What a plan diff looks like when you make that change in step 4, the shape to learn to read:

  # aws_vpc.main will be updated in-place
  ~ resource "aws_vpc" "main" {
        id         = "vpc-04e9f2a1"
      ~ tags       = {
          ~ "Environment" = "dev" -> "staging"
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

The ~ is a modification, + is a creation, - is a destruction, and -/+ (replacement) is the one that should make you slow down: it means Terraform will destroy and recreate the resource to get there.

terraform fmt rounds out the set: it standardizes formatting so diffs stay about substance.

The reason to drill this in a sandbox first is not that the commands are hard. It is that each one has a moment where a habit forms: reading the plan instead of trusting it, checking state instead of assuming, destroying deliberately instead of clicking through. A sandbox lets those habits form before anything is at stake.

Day 2: when the repo and the cluster disagree

Terraform gets your infrastructure created. The modern follow-up question is who keeps the running system matching the repo afterwards, and that is GitOps territory. The GitOps Workflow simulator drops you into three decision scenarios, each one a real day-2 situation:

Configuration Drift: someone changed the live system by hand, so the cluster no longer matches Git. You decide how the reconciler should respond, and you see why "the repo is the truth" is a policy you enforce, not a wish.
Deployment Rollback: a bad version is live. In GitOps, the rollback is a revert in Git, not a hotfix on the cluster, and the scenario walks why that discipline pays.
Sync Policy Decision: automatic sync with self-heal and pruning, or manual gates? The scenario's preferred answer is full automation, which is worth knowing is a simplification: Argo CD itself ships with pruning and self-heal off by default, and plenty of teams gate production syncs on purpose. The value is in having to weigh it at all.

The pairing with Terraform is deliberate: plan/apply is convergence toward declared state on demand, and GitOps is the same convergence made continuous, with an agent pulling desired state and reconciling it automatically. Drift is the shared enemy.

From sandbox to real

The graduation path, in order of increasing blast radius:

The simulator until init, plan, apply, state and destroy feel boring.
Terraform against something local: HashiCorp's own getting-started path uses the Docker provider, real Terraform managing real containers on your machine, no bill possible.
A real cloud sandbox account with a budget alarm set before the first apply, not after the first bill. (Free tiers reduce cost, they do not eliminate it; the alarm is not optional.)
Reading real plans at work before you write any, because plan-reading is the skill teams actually need from a newcomer on day one.

The habits transfer unchanged; only the stakes grow.

Both simulators are part of 50+ free DevOps games and simulators. When you are ready for the real thing, HashiCorp's Docker getting-started tutorial is the natural next step: real Terraform, local resources, still no cloud bill.