State Locking

Whenever Terraform is about to read or write state, it first attempts to acquire a lock. If another operation already holds that lock — say, a teammate mid-apply on the same configuration — Terraform blocks and reports that the state is locked, rather than proceeding and risking two processes overwriting each other's changes. This matters because state operations are not atomic merges: if two applies ran concurrently against the same state file without coordination, the second write would simply clobber the first, silently dropping resource records and leaving Terraform's understanding of infrastructure out of sync with reality.

Locking support and mechanism vary by backend. The S3 backend historically paired with a DynamoDB table to hold lock records (one item per state file, keyed by a LockID attribute), though newer versions of Terraform support native S3 locking via conditional writes without a separate table. Azure's backend uses blob leases on the state blob itself, and Terraform Cloud/Enterprise manages locking centrally as part of its run orchestration. Not all backends support locking — the plain local backend uses a local .tfstate.lock.info file, which only protects against concurrent processes on the same machine, not across a team.

Locks are normally released automatically when an operation finishes or is cancelled cleanly. But a crashed process, a killed CI job, or a network interruption can leave a stale lock behind, blocking all future operations. Terraform provides terraform force-unlock <LOCK_ID> for exactly this situation — but it is a manual override that bypasses the safety mechanism, so it should only be used after confirming no other operation is genuinely still running against that state.