How a Terraform remote backend supports shared state, and why locking must be verified for the selected backend.
A remote backend stores Terraform state in a shared service rather than on one operator’s local filesystem. That gives a team one state source for a particular workspace and enables controls such as access management and backups. It does not, by itself, guarantee locking: Terraform’s backend documentation says locking is optional and backend-specific.
When a backend supports locking, Terraform automatically locks state for operations that could write it. A second writer cannot acquire the lock until the first run completes or the lock times out. This reduces the risk of two applies working from conflicting snapshots and corrupting state. HashiCorp’s locking reference describes this behavior and cautions against disabling it.
| Control | What it helps with | What it does not replace |
|---|---|---|
| Remote state | A shared authoritative state location. | Code review or least-privilege access. |
| State locking | Concurrent state-writing operations. | Reviewing a plan’s intended changes. |
| Backend access controls | Who can read or update potentially sensitive state. | Provider permissions for the infrastructure itself. |
-lock=false.terraform force-unlock only to clear a lock that belongs to your failed run, using the reported lock ID. Removing another active run’s lock can allow two writers.Remote state and locking work alongside—not instead of—reviewed configuration, provider permissions, environment separation, and recovery procedures. A lock serializes writers; it cannot determine whether a change is correct.