Imagine two engineers at Swiggy both run terraform apply at 9am on Monday. Both see a clean plan. Both hit enter. By the time both finish, the infrastructure is in an undefined state and no one is sure what actually got created. Terraform state — and state locking — is what prevents this. The state file is Terraform's memory, and the backend is where that memory lives safely for your whole team.
What This Pillar Covers
- Understanding what the
terraform.tfstatefile actually contains and why it must never be edited by hand - Setting up remote state on AWS S3 with DynamoDB locking for team-safe applies
- Using
terraform statecommands to move, remove, list, and inspect resources in state - Importing existing infrastructure created outside Terraform into state without recreating it
- Detecting and reconciling drift when someone changes a resource in the AWS console
- Recovering from a locked or corrupted state file safely
Who This Is For
DevOps engineers and platform engineers who are moving Terraform from a single-laptop tool to a team workflow — or who have inherited infrastructure that was partially managed by Terraform and partially built by clicking in the console.
Why This Matters in Production
At Zerodha, a developer accidentally deleted the local terraform.tfstate file and ran terraform apply — Terraform had no memory of what it had created, so it tried to create everything again, hitting naming conflicts and leaving the environment broken for hours. Remote state with S3 versioning means the state file is never on someone's laptop, is recoverable if corrupted, and is locked so only one apply can run at a time.
Prerequisites
- Terraform Fundamentals — providers, resources, and the plan/apply workflow
- Basic AWS knowledge — S3 buckets and DynamoDB tables
- Understanding of what a JSON file is