State and backends

State remembers which object belongs to which address

Configuration says what you want. State associates addresses such as terraform_data.name with managed object identities and attributes. With a cloud provider, that mapping might connect aws_instance.web to a particular instance ID. Without it, Terraform cannot simply assume an existing object with a similar name belongs to this configuration.

A backend determines where state is stored and how it is accessed. The default local backend uses files in your working directory. Remote backends store state elsewhere and may support locking to coordinate writers. A lock prevents competing state operations where supported; it does not turn a multi-resource apply into an all-or-nothing transaction.

Inspect the state you created

Use terraform-basics from the earlier lessons. If only the first resource has been applied, that is enough for the first two commands:

terraform state list
terraform state show terraform_data.name
terraform output

Expected: the name address appears, its generated ID and stored input are shown, and outputs reflect the last apply. A label present only in configuration will not appear in state yet. That difference is useful: configuration and state are related, not interchangeable copies.

Open terraform.tfstate only for reading in this non-secret local exercise. Find the resource type, name, and input. Its JSON representation is an implementation format, not a routine editing interface. Real state can include passwords or other sensitive attributes. Keep state, backups, and saved plans out of Git.

Work through a two-writer problem

Suppose Ana and Ravi each hold a local copy of state. Ana creates an object and writes an updated copy. Ravi plans from the old copy and then overwrites it with another result. The team can lose a reliable record of ownership even though the remote objects still exist. Shared state storage plus a supported locking mechanism addresses coordination; access control, encryption, version history, and recovery remain separate responsibilities.

For an S3 backend, the bucket must already exist before initialization. Current S3 backend configuration supports use_lockfile = true; DynamoDB-based locking is deprecated. These are design facts for later cloud work, not instructions to create a bucket here. Backend configuration cannot use ordinary input variables, and credentials should come from a supported authentication flow rather than a committed backend block.

Understand recovery before changing records

Drift means the actual managed object differs from what Terraform expects. A normal plan refreshes observations where possible and proposes a way forward. A refresh-only plan updates the proposed state view without proposing remote changes; applying it does not rewrite the desired configuration.

terraform state rm forgets a binding; it does not destroy the real object. If its configuration remains, a later plan may propose another object. terraform import associates an existing object with an address; it is not permission to ignore or overwrite that object's configuration. A moved block can record an intended address change during refactoring.

Backend migration transfers existing state to another backend through the documented initialization workflow. -reconfigure changes backend initialization; it is not interchangeable with -migrate-state. Before any migration, know the source, destination, active writers, and recovery copy. Never force-unlock solely because a lock is inconvenient; establish whether its owner is still operating.

Checkpoint

If someone deletes the local state file, were cloud objects deleted? No. If .terraform.lock.hcl exists, does it prevent simultaneous applies? No; it records provider selections, not a state-operation lock. In your notes, draw three boxes—configuration, state, and managed objects—and explain what each of these actions changes: edit a value, plan, apply, and forget a binding.

Next, use modules for reuse while keeping environment state and credentials explicit.

References: state↗, state commands↗, state locking↗, and S3 backend↗.