What State Knows

Scenario: A configuration says server.api, while the provider API knows only opaque object ID srv-a81; Terraform needs a durable mapping.

State maps Terraform addresses to remote object identities, stores dependency metadata and provider-returned attributes, and accelerates operations. It is not merely a cache and should not be hand-edited. Terraform compares configuration (desired), prior state (memory), and refreshed provider data (observed reality). A state snapshot has lineage and serial metadata to prevent unsafe overwrites.

Analogy: State is the title registry for managed property. Losing the blueprint is bad; losing the mapping between titles and real parcels creates duplicate ownership and demolition risk.

A worked configuration

terraform state list
terraform state show fakecloud_server.api
terraform show
# Back up before exceptional state surgery:
terraform state pull > reviewed-backup.json

Treat state as production data: encrypted, access-controlled, versioned, backed up, and changed through Terraform commands. State can contain secrets even if configuration never hardcodes them.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-local-backend-basics Terraform lab. Open /labs/terraform and choose slug tf-local-backend-basics; the lab runs real Terraform against the offline FakeCloud provider.