Cheat sheet

Terraform

Core workflow, state management, workspaces, import, and debugging.

Core workflow

# Initialise (download providers & modules)
terraform init

# Preview changes
terraform plan

# Preview and save plan
terraform plan -out=tfplan

# Apply saved plan
terraform apply tfplan

# Apply directly (skips interactive approval)
terraform apply -auto-approve

# Destroy all managed resources
terraform destroy

State management

# List resources in state
terraform state list

# Show a specific resource
terraform state show aws_instance.web

# Move resource to new address
terraform state mv \
  aws_instance.web \
  module.compute.aws_instance.web

# Remove resource from state (orphan it)
terraform state rm aws_instance.legacy

# Pull remote state to stdout
terraform state pull

# Force-unlock a stuck state
terraform force-unlock <lock-id>

Import & refactor

# Import existing resource into state
terraform import aws_s3_bucket.logs my-log-bucket

# Generate config for resources declared in import {} blocks (v1.5+)
terraform plan -generate-config-out=generated.tf

# Replace a specific resource (force recreate)
terraform apply -replace="aws_instance.web"

# Target a specific resource
terraform apply -target="module.eks"
terraform plan -target="aws_security_group.allow_http"

Workspaces

# List workspaces
terraform workspace list

# Create a new workspace
terraform workspace new staging

# Switch workspace
terraform workspace select production

# Show current workspace
terraform workspace show

# Delete a workspace
terraform workspace delete staging

Variables & outputs

# Pass variable on CLI
terraform apply -var="region=eu-west-1"

# Load from var file
terraform apply -var-file="prod.tfvars"

# Variable precedence (highest wins):
# 1. -var and -var-file flags (evaluated left-to-right on CLI)
# 2. *.auto.tfvars / *.auto.tfvars.json (lexical order)
# 3. terraform.tfvars.json
# 4. terraform.tfvars
# 5. TF_VAR_* environment variables

# Show outputs
terraform output
terraform output vpc_id

Format & validate

# Format all .tf files
terraform fmt -recursive

# Check formatting (exit 1 if diff)
terraform fmt -check -recursive

# Validate configuration
terraform validate

# Upgrade providers to latest in lock file
terraform init -upgrade

# Show provider requirements
terraform providers

Debugging

# Verbose logging
TF_LOG=DEBUG terraform plan

# Log levels: TRACE, DEBUG, INFO, WARN, ERROR

# Log to file
TF_LOG=DEBUG TF_LOG_PATH=./tf.log terraform apply

# Show dependency graph (requires graphviz)
terraform graph | dot -Tsvg > graph.svg

# Refresh state without applying changes (preferred — shows diff before writing)
terraform plan -refresh-only
terraform apply -refresh-only

# terraform refresh is deprecated since v1.5

About the Terraform cheat sheet

Terraform's workflow is init, plan, apply, and nearly every problem worth knowing about lives in the state file rather than the configuration. State records what Terraform believes it created, and the gap between that belief and reality is where incidents come from.

Read plans properly. The symbols matter — create, destroy, update in place, and replace are meaningfully different, and a replace on a database or a load balancer is a destructive operation wearing a routine label. Anyone who applies without reading which resources are being replaced will eventually delete something they did not intend to.

The state operations are worth learning before you need them under pressure. Importing existing infrastructure, moving a resource's address after a refactor, and removing something from state without destroying it are the three that come up most, and all three are far less frightening when practised on something unimportant first.

Frequently asked questions

How do I bring existing infrastructure under Terraform?

Write the resource configuration first, then import the real resource into that address, then run a plan and expect it to be empty. A non-empty plan means your configuration does not match reality — adjust the configuration, not the infrastructure. Import blocks let you express this in code rather than as a one-off command, which leaves a reviewable record.

I renamed a resource and Terraform wants to destroy and recreate it. Why?

Terraform tracks resources by address, so renaming looks like deleting one resource and creating another. Use a moved block to tell Terraform the address changed, and the plan becomes a no-op. This is the correct way to refactor, and it is reviewable, unlike a manual state move.

How do I stop managing a resource without deleting it?

Remove it from state rather than removing it from configuration and applying. Deleting the configuration block tells Terraform to destroy the resource; removing from state tells Terraform to forget it while leaving it running. Confirm with a plan afterwards that nothing else is affected.

What is the safest way to handle state locking?

Use a backend that supports locking and never disable it to get past an error. A stuck lock usually means a previous run was interrupted; force-unlock exists for that, but confirm no apply is genuinely in progress first. Two concurrent applies against the same state is one of the few ways to corrupt it.

Should I use workspaces for environments?

Usually not. Workspaces share one configuration and backend, so an error affects every environment and it is easy to apply to the wrong one. Separate directories or separate state per environment give real isolation and make the blast radius obvious. Workspaces suit short-lived parallel copies of the same thing better than they suit production and staging.