Terraform state: what it stores, why it is locked and how drift shows up

What it is

The state documentation (cited) describes the primary purpose of state as storing bindings between objects in a remote system and resource instances declared in configuration: when Terraform creates a remote object, it records that object's identity against the resource address so that later changes update or delete the same object. State is a JSON text file; by default it lives locally as terraform.tfstate, and the documentation advises against storing it in version control or any storage without locking and access control, because that can cause data loss or expose secrets stored in the state file.

Locking (cited): if the backend supports it, Terraform locks the state for every operation that could write it, silently, and refuses to continue when the lock cannot be taken. force-unlock exists for a lock left behind by a crashed run and takes the lock ID as a safeguard.

Why it matters

Two people or two pipelines applying at once without a lock can each write a state that omits the other's resources; the next plan then proposes to recreate or destroy real infrastructure. Drift, a change made in a console or by another tool, is not an error in itself but is invisible until the next plan, and the plan documentation (cited) warns that routinely applying with -target leads to undetected configuration drift.

How to apply

• Use a remote backend with locking and versioning (object storage plus a lock mechanism, or a hosted backend) and restrict read access as tightly as write access, since state contains attribute values such as generated passwords.
• Run terraform plan -refresh-only on a schedule to list drift without proposing configuration changes, and decide per finding whether to adopt the change into code or revert it.
• Produce plans with -out in CI and apply exactly that saved plan after review; use -detailed-exitcode to fail a check when a diff exists.
• Keep one state per blast radius: separate environments and separate long-lived foundations (networks, identity) from frequently changed services.
• Move or rename resources with moved blocks rather than editing state by hand.

Pitfalls

A terraform import or state rm changes bindings without touching infrastructure, so the next plan may look surprising. Provider upgrades can rewrite state schemas. The cited state page warns that the state file can contain secrets; marking a variable sensitive hides it from output, not from the file.