Terraform Workflow: plan, apply, destroy
The core Terraform loop is init, plan, apply and destroy. Learn to read plan output, use plan files, and control scope with flags so changes are safe, reviewed and reversible.
What is this?
The standard Terraform workflow is a tight, repeatable loop. terraform init prepares the working directory once, then terraform plan previews changes, terraform apply executes them, and terraform destroy tears everything down. The plan output is the core review artifact: + means create, ~ in-place update, -/+ replace, and - destroy.
Why do you need it?
- The plan is a safe dry-run — you can run it as often as you like with zero side effects.
- Humans review plans before any irreversible change reaches the cloud.
- Applies are idempotent, so re-running converges to the desired state.
- Destroy is declarative teardown: no orphaned manual cleanup, everything you created is removed.
Mental model
Reading the recipe aloud before cooking
terraform plan before terraform apply
You check the ingredients first — 'I'll need eggs (create) and I'm out of flour (update)' — before you start cooking. Terraform reads the plan aloud, and you confirm, before it touches anything.
How it works
- terraform init installs providers and initializes the backend — run it once per working directory.
- terraform plan refreshes state, diffs configuration against state, and computes the actions needed.
- A reviewer reads the plan symbols and resource diffs to spot anything unexpected.
- terraform apply executes the actions in dependency order and records results in state.
- terraform destroy removes every managed resource, prompting for confirmation by default.
- Flags tune behavior: -auto-approve skips the prompt, -target limits scope, -var overrides variables, -out saves a plan file.
The Terraform core workflow loop.
Key commands
terraform initInitialize the working directory and install providers.
terraform validateCheck configuration validity before planning.
terraform planPreview changes without applying them.
terraform plan -out=tfplanSave the plan to a file for an exact, reviewed apply.
terraform apply tfplanApply an exact saved plan file.
terraform apply -auto-approveApply without the interactive confirmation prompt.
terraform destroy -auto-approveRemove all managed resources without prompting.
terraform plan -target=aws_instance.webLimit planning to one resource address (use sparingly).
terraform plan -refresh-onlyUpdate state from reality without changing resources.
Examples
Reading a real plan output
Terraform used the selected providers to generate the following execution plan.Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # local_file.greeting will be created + resource "local_file" "greeting" { + content = "Hello, Terraform!" + filename = "hello.txt" + id = (known after apply) } Plan: 1 to add, 0 to change, 0 to destroy.+ means a new resource will be created, ~ an in-place update, -/+ a destroy-and-recreate, and - a deletion. 'known after apply' means the value won't exist until the resource is created, which is normal for IDs.
In production
- CI runs terraform plan on every pull request and comments the output for review.
- Merged code triggers apply in a pipeline with human approval for production.
- Saved plan files (terraform plan -out) make applies exactly match the reviewed plan.
- Ephemeral environments are created by apply and destroyed by scheduled destroy runs.
Best practices
- Always review the plan; never apply blind in production.
- Use -out to save a plan and apply that exact file, avoiding config drift between plan and apply.
- Avoid -target in normal operations; it can leave resources out of sync.
- Make small, frequent changes so each plan diff stays reviewable.
- Keep credentials out of commands; use tfvars files and environment variables.
Common mistakes
- Using -auto-approve habitually, skipping the review gate.
- Overusing -target, which creates partial states and surprising next plans.
- Ignoring 'known after apply' values or unknown resource counts in the plan.
- Applying a stale saved plan file after the configuration changed.
Common issues
Error: Saved plan is staleConfiguration or state changed after the plan file was created.
Re-run terraform plan -out=tfplan and apply the fresh file.
Error acquiring the state lock during applyA concurrent plan/apply holds the lock.
Wait for it to finish, or force-unlock after verifying nothing is running.
Error: No changes. Infrastructure is up-to-dateConfig matches state and reality exactly.
Not an error — it means the apply converged; make changes to see new actions.
Debugging tips
- TF_LOG=DEBUG terraform plan shows every API call and internal decision.
- terraform plan -refresh-only separates drift correction from intended changes.
- terraform show <planfile> re-renders a saved plan for later review.
- terraform apply -auto-approve is safe when you already reviewed and saved the plan.
Interview checkpoint
Hands-on lab
- Move through init, validate, plan, apply and destroy
- Read plan output symbols correctly
- Use a saved plan file for a reviewed apply
- Use -target and -refresh-only to control scope
Run the Full Terraform Workflow
30 min · beginner
Quick quiz
Which plan symbol indicates a resource will be destroyed and recreated?
Which flag applies changes without asking for confirmation?
terraform plan can modify real infrastructure.
Cheat sheet
terraform initOne-time setupterraform planPreview changesterraform plan -out=tfplanSave reviewed planterraform apply tfplanApply exact planterraform apply -auto-approveSkip promptterraform destroyTear down resources-target=ADDRScope to one resource