State & Remote Backends
The single most important operational concept in Terraform.
Terraform needs to remember what it has already built, so it can tell the difference between “create this” and “update that.” It keeps this memory in a state file. Understanding state — and storing it safely — is what separates a hobby project from a real team workflow.
🎯 Learning Objectives
By the end of this lesson you will:
- Understand what Terraform state is and why it exists
- Know the dangers of local state on a team
- Configure a remote backend
- Understand state locking
What is State?
When you run apply, Terraform records everything it created in a file called terraform.tfstate. On the next run, it compares three things:
Your config vs State file vs Real infrastructure
(desired) (last known) (actual)From that comparison it computes the minimal plan — what to add, change, or destroy.
💡 Why not just query the cloud?
Terraform uses state as a fast, authoritative record and to map your config names to real resource IDs. It’s also how Terraform tracks resources that can’t be easily discovered by scanning the cloud.
The Problem with Local State
By default, state lives in a local file. For one person that’s fine. On a team, it breaks:
⚠ Local state doesn't scale to teams
If state sits on your laptop:
- Teammates can’t see or use it — they’d build duplicate resources.
- Two people running
applyat once can corrupt state or clash on real infrastructure. - Losing the file means Terraform “forgets” everything it manages.
- State often contains sensitive values in plain text.
Remote Backends
A remote backend stores state in shared, durable storage instead of on your machine. Common choices: AWS S3, Azure Blob Storage, Google Cloud Storage, or Terraform Cloud.
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "prod/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-locks" # enables locking
encrypt = true
}
}Benefits:
- Shared — the whole team uses one source of truth.
- Durable — cloud storage is backed up and versioned.
- Encrypted — sensitive values are protected at rest.
- Lockable — prevents concurrent, conflicting applies.
State Locking
When someone runs apply, Terraform locks the state so no one else can change it at the same time. The lock releases when the run finishes.
Without locking, two simultaneous applies could race and corrupt both the state and the real infrastructure. With S3, a DynamoDB table provides the lock; other backends have their own mechanisms.
Handy State Commands
| Command | Purpose |
|---|---|
terraform state list |
List resources Terraform tracks |
terraform state show <addr> |
Inspect one resource in state |
terraform refresh |
Reconcile state with reality |
terraform import <addr> <id> |
Bring an existing resource under management |
⚠ Never hand-edit the state file
Editing terraform.tfstate by hand is a great way to corrupt it. Use the terraform state subcommands, which make changes safely.
🧪 Hands-on Lab
Inspect and Reason About State
- Apply a config with a couple of resources
- List everything in state and inspect one resource
- Explain why storing this state remotely matters for a team
🧠 Knowledge Check
What is the main risk of keeping Terraform state on a single developer's laptop in a team?
What does state locking prevent?
💼 Interview Preparation
Explain how Terraform decides what changes to make on an apply.
Summary
You now understand what state is, why local state fails for teams, how remote backends provide shared, encrypted, durable storage, and how locking prevents concurrent corruption. Next, you’ll make configs reusable with modules and see the full production workflow.