Terraform State & Drift · Terraform systems note
Terraform State Locking Prevents Concurrent Writers, Not Bad Decisions
State locking serializes writers against one state. It cannot tell whether a plan is destructive, credentials point at the right account, or force-unlock is safe.
Terraform locking solves a narrow but important problem: two writers should not update the same state concurrently.
The lock protects consistency, not intent
A locked apply can still delete the wrong database, run in the wrong cloud account, or replace a resource because a provider changed behavior. The backend lock does not review the plan.
force-unlock is an incident action
HashiCorp warns that terraform force-unlock should only clear a lock known to be stale. A slow or disconnected process can look dead while still having the ability to continue its operation.
Removing that lock and starting another writer creates the exact race locking was designed to prevent.
Do not use -lock=false to fix pipeline contention
If CI frequently collides on one state, the problem is workflow serialization or state boundaries. Disabling locking trades waiting for possible state corruption.
Use lock timeout instead of bypass
-lock-timeout lets automation wait for a bounded interval. Centralized run queues in HCP Terraform go further by coordinating plans awaiting approval, not only state writes.
A lock is concurrency control. It is not a certificate that the operation behind it is correct.