Terraform State & Drift · Terraform systems note
Terraform State Is Not a Cache — It Is the Binding Database
State maps resource addresses in configuration to real remote objects. Treating it as disposable cache data is how infrastructure gets orphaned or recreated.
Terraform configuration says what infrastructure should exist. The provider API says what exists remotely. State is what connects those two worlds.
State stores identity
When Terraform sees aws_instance.web, it needs to know which remote instance is already associated with that address. That association lives in state together with provider-managed metadata.
If the state disappears while configuration remains, Terraform does not “rediscover everything” automatically. It can conclude that declared resources are missing and plan new ones.
Remote state changes storage, not semantics
A remote backend gives teams shared access, locking, and often encryption. It reduces dependence on one laptop, but the state remains canonical infrastructure metadata.
State carries migration history
Renaming a resource or moving it into a module changes its address. Terraform needs an explicit migration—such as a moved block—because the remote object should survive while its address changes.
Manual state operations deserve database discipline
Before state surgery, pull a backup, capture the configuration revision and provider lock file, make one focused change, then immediately run a plan. Editing raw JSON bypasses lineage, serial and schema checks that Terraform's commands provide.
The useful model is simple:
configuration = desired model
provider API = remote reality
state = identity bindingWhen those three agree, planning is deterministic. When state is treated like cache, resource ownership becomes guesswork.