Terraform state: the file that owns your infrastructure

You write the code. You define the resources. You run the apply. But Terraform doesn’t track your infrastructure through the cloud provider’s API alone. It relies on a single, critical artifact: the state file.

This file is the ledger. It records what exists, maps your code to real-world IDs, and determines every action Terraform takes. Forget the idea that your .tf files are the source of truth. They’re merely instructions. The state file is reality.

How State Dictates Your Reality

When you run terraform plan, the engine doesn’t scan your cloud environment from scratch. It compares your configuration against the cached reality stored in the state. This is why state corruption or drift leads to chaos:

If the state lists a resource your code no longer defines, Terraform will destroy it.
If your code adds a resource the state doesn’t know, Terraform will create it.
If someone modifies a resource manually via console, the state—and thus Terraform—becomes blind to that change. The next apply may overwrite it.
The Inevitable Pitfalls

A local terraform.tfstate file is a liability. It dooms you to:

The Lone Operator Problem: Only the machine with the file can manage the infrastructure.
The Collaboration Disaster: Two engineers applying changes based on different local state files will create conflicting, duplicate, or orphaned resources.
The Irrecoverable Loss: Delete the file, and you sever the link between your code and the deployed resources. You cannot update or destroy them through Terraform anymore.
Practical Rules for Survival

Use Remote State. This is mandatory. Store it in a backend like S3 with locking (via DynamoDB), Terraform Cloud, or similar. This provides a single, shared source of truth for the team.
Never Edit Manually. Use the command line (terraform state rm, terraform state mv, terraform import) for any surgical operations. Hand-editing the JSON is asking for subtle, catastrophic failure.
Lock Rigorously. The remote backend should prevent simultaneous applies. This avoids two processes racing to write conflicting state updates.
Back Up and Version. Enable versioning on your remote state bucket. Before risky operations, pull a copy as an emergency snapshot (terraform state pull > backup.tfstate).
Plan Relentlessly. Every apply should be preceded by a plan. If the plan looks wrong, question your state. It is the most likely culprit.
Conclusion

Terraform state is not a log file. It is the control plane. It is the authoritative record of ownership. Manage it with the same rigor you apply to your infrastructure code—because in truth, it is more critical. Without accurate state, Terraform is blind, and your infrastructure is adrift.

Configure your remote backend first. Everything else follows.