Local, Remote, and Locked State

Scenario: Two engineers plan from the same old local state and both apply, overwriting each other's understanding.

The local backend stores state on disk and is suitable for isolated learning, not team concurrency. Remote backends centralize state and may provide encryption, versioning, access control, and locking. Locking serializes writers; do not bypass it casually with -lock=false. Backend configuration is initialized separately from provider configuration, and changing it requires terraform init -migrate-state or an intentional reconfiguration.

Analogy: A backend is a shared document vault; locking is the checkout card that prevents two people from replacing the master copy simultaneously.

A worked configuration

terraform {
  backend "remote-example" {
    organization = "platform"
    workspace    = "payments-prod"
  }
}
# terraform init -migrate-state

Design for lock failures: identify the real holder, inspect run activity, and force-unlock only a known-stale lock using its exact ID. Backend availability becomes part of the deployment control plane, so monitor and back it up.

Warning: Force-unlocking an active run can permit concurrent state writes and corrupt ownership. A timeout is not proof that a lock is stale.

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