6.2.1. Why Locking Matters
💡 First Principle: A lock turns a race condition into a queue — the second operation waits instead of corrupting state — so the value of locking is precisely the corruption it prevents during concurrent apply/destroy runs.
Terraform automatically attempts to lock state before any operation that could write to it (apply, destroy, state mutations) and releases the lock when done. If another operation holds the lock, Terraform waits or errors rather than proceeding — this is what stops two engineers (or two CI jobs) from writing conflicting state simultaneously.
If a process crashes mid-operation, a lock can be left dangling. terraform force-unlock <LOCK_ID> manually releases it — used carefully, only when you're sure no operation is actually running. The -lock=false flag disables locking entirely and is dangerous.
⚠️ Exam Trap: force-unlock is for stuck locks, not routine use, and -lock=false should essentially never be used in team settings. The exam may frame a "lock stuck after a crash" scenario — the answer is terraform force-unlock, not deleting state.
Reflection Question: Why is disabling locking with -lock=false far riskier on a remote shared backend than on a single-user local setup?
