Terraform Workflow

You know the four commands. But knowing commands is not the same as knowing how to work. This lesson shows you what a professional Terraform workflow looks like end to end — and exactly where teams cut corners and pay for it later.

The Workflow Most Tutorials Skip

Most Terraform tutorials show you terraform apply and call it a workflow. That is not a workflow — that is a single command run in isolation. A real workflow is the full cycle from writing configuration to safely deploying changes to production, including every review, every check, and every gate along the way.

Teams that skip the workflow and treat Terraform as "just run apply" are the same teams that accidentally destroy production databases. The commands are safe. The process is what makes them safe to use on infrastructure that matters.

The Complete Workflow

A professional Terraform workflow has six stages. The first four happen locally. The last two happen through a controlled process — either manually with discipline or automated through CI/CD.

The Two Commands You Have Not Seen Yet

Stage 2 introduced two commands that did not appear in earlier lessons. They are short, fast, and should become automatic habits before every plan.

New terms:

• terraform fmt — formats all .tf files to the canonical HashiCorp style. Modifies files in place. Run before every commit.
• terraform validate — checks for syntax errors and internal consistency. Does not connect to any cloud provider. Catches things like referencing a variable that does not exist. Instant and offline.
• terraform plan -out=tfplan — saves the execution plan to a binary file. When you run terraform apply tfplan, Terraform executes exactly that saved plan — no surprises between review and apply. Essential for CI/CD.
• terraform show — prints a saved plan file or current state in human-readable format. Use terraform show tfplan to inspect a saved plan before applying.

# The full local workflow — run in this order every time

# Format all .tf files to canonical style
terraform fmt

# Check for syntax errors and consistency issues
terraform validate

# Generate and save the execution plan
terraform plan -out=tfplan

# Inspect the saved plan before applying
terraform show tfplan

# Apply exactly the saved plan — no re-planning, no surprises
terraform apply tfplan

# Confirm zero drift after apply
terraform plan

$ terraform fmt
main.tf
variables.tf

$ terraform validate
Success! The configuration is valid.

$ terraform plan -out=tfplan

  # aws_instance.web_server will be created
  + resource "aws_instance" "web_server" {
      + ami           = "ami-0c55b159cbfafe1f0"
      + instance_type = "t2.micro"
    }

Plan: 1 to add, 0 to change, 0 to destroy.
Saved the plan to: tfplan

$ terraform apply tfplan

aws_instance.web_server: Creating...
aws_instance.web_server: Creation complete after 32s [id=i-0abc123def456789]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

$ terraform plan
No changes. Your infrastructure matches the configuration.

Working as a Team — Shared State

When you work alone, the state file lives on your machine. When you work in a team, that breaks immediately — two engineers cannot share a state file that only one of them has.

The solution is a remote backend — a shared location where the state file lives. Every team member and every CI pipeline reads from and writes to the same state. The most common setup is an S3 bucket with DynamoDB for state locking — locking prevents two applies running simultaneously and corrupting the state file.

Remote backends are covered fully in Section II. For now: local state is for learning only. Any infrastructure a team manages together needs remote state from day one.

Common Mistakes

Practice Questions

Quiz