Stop 10 · Infrastructure as Code & AutomationTopics · 4/9

Terraform State Management

In short

Terraform's state file is its memory of what it built. Keep it on one laptop, or let two people apply at once, and you get duplicated servers or a corrupted file.

Terraform tracks the real-world resources it manages in a state file — mishandling state (losing it, or two people applying simultaneously) is one of the most common and costly Terraform mistakes.

The mascot guards a thick ledger in a steel cabinet while neighbours queue to update it one at a time.

Think of it like this

The society maintenance ledger

A housing society keeps one ledger of who paid what. It stays locked in the office, and only one person writes in it at a time. If two treasurers kept separate notebooks, the accounts would never match. Remote state with locking is that one ledger.

Watch it happen

Two engineers, one locked state

Riya

Aman

S3 state

lock + read state

1/5Riya runs apply. Terraform first takes a lock on the state, then reads it.

The big ideas

What you need to know

State maps code to reality

It links each resource block to a real cloud ID. Without it, Terraform can't tell what it already made.

Remote backend

Store state in a shared, versioned backend like an S3 bucket, GCS bucket or Terraform Cloud, never only on a laptop.

Locking

Locking stops two applies at once. The S3 backend can lock using a lock file in the bucket itself.

State holds secrets

State can contain passwords and keys in plain text. Encrypt it, restrict access and never commit it to Git.

See it in code

Walk through the code

hcl

1terraform {2  backend "s3" {3    bucket       = "shop-tf-state"4    key          = "prod/network.tfstate"5    region       = "ap-south-1"6    encrypt      = true7    use_lockfile = true # S3-native locking (Terraform 1.10+)8  }9}

1/3State lives in one bucket, with a separate key (path) for each project and environment.

Create the state bucket first (with versioning on) and run terraform init to move state into it. Older setups use a DynamoDB table for locking instead.

Save yourself the pain

Common mistakes

Oops

Committing terraform.tfstate to Git so the team can share it.

Do this instead

Use a remote backend and add *.tfstate to .gitignore. Git has no locking, and the file can leak secrets.

Oops

Hand-editing the state file to fix a problem.

Do this instead

Use terraform state mv, state rm, import blocks or moved blocks. They change state safely and leave a record.

Your mission

Explore your state

~25 min

Quick check

Two engineers run terraform apply on the same project at the same moment with no locking. What's the risk?

Go deeper

1Learn what Terraform state actually contains and why it must stay in sync with real infrastructure.
2Set up remote state storage (e.g. an S3 backend) instead of a local state file.
3Understand state locking and why it prevents two people from applying changes simultaneously.