Terraform Fundamentals · Module 06 of 12

State, backends, locking and collaboration

Treat Terraform state as protected operational data, understand backend responsibilities, and know why locking and recovery discipline matter for teams.

Learning objectives

By the end of this module, you should be able to:

Explain what state records and why manual editing is risky.
Describe backend storage and state locking.
Use safe state inspection commands and understand force-unlock risk.

State binds configuration to managed objects

Terraform state tracks resource instances, remote identifiers and attributes used for planning. The JSON representation is an implementation detail; normal maintenance should use Terraform commands rather than manual editing.

Backends determine state storage and locking capabilities

The default local backend stores state on disk. Remote backends centralize state and may provide locking. Locking prevents concurrent writers when the backend supports it.

State can contain secrets

Provider schemas and resource attributes can place sensitive information in state even when CLI output is redacted. Protect backend access, encryption and backups accordingly.

Worked examples

See the idea in practice.

Safe inspection commands

terraform state list
terraform state show ADDRESS
terraform state pull > state-backup.json

state list/show are preferable to opening and editing the JSON.
state pull can capture an explicit diagnostic backup; protect it because it may contain secrets.

Hands-on lab

Lab — Inspect and back up local state safely

Goal: Create state, inspect it through Terraform, and capture a protected backup without hand-editing.

Before you start

Terraform CLI only.

STEP 1

Create a stateful training object

mkdir -p ~/gnu-terraform-labs/module06 && cd ~/gnu-terraform-labs/module06
cat > main.tf <<'EOF'
resource "terraform_data" "state_demo" {
  input = {
    owner = "academy"
    tier  = "training"
  }
}
EOF
terraform init
terraform apply -auto-approve

STEP 2

Inspect addresses

terraform state list
terraform state show terraform_data.state_demo

STEP 3

Create diagnostic backup

umask 077
terraform state pull > state-backup.json
ls -l state-backup.json

STEP 4

Confirm no configuration drift

set +e
terraform plan -detailed-exitcode
rc=$?
set -e
test "$rc" -eq 0

Verify

State list contains terraform_data.state_demo.
The pulled state file is non-empty and created with restrictive permissions.
A no-change plan exits 0.

Expected outcome

You can inspect and back up state without manually editing it.

If it fails

terraform plan -detailed-exitcode returns 0 for no changes, 2 for changes, 1 for error.
Never publish state-backup.json to a public repository.

Real-world connection

Teams normally use protected remote state with access controls, encryption, locking and versioned recovery.

Avoid these traps

Common mistakes

Committing terraform.tfstate to Git.
Running force-unlock without proving the original writer is gone.
Assuming a sensitive output means state contains no secret.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What does a backend control?

Where state is stored and, depending on the backend, how locking/remote operations are provided.

2Why is force-unlock dangerous?

It can permit concurrent writers if the original lock holder is still active.

3Should state normally be hand-edited?

No; use Terraform state operations and documented recovery workflows.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.