Terraform "Error acquiring the state lock": the run that died, the lock it left behind, and the safe way to clear it

verbatim errorError acquiring the state lock Error message: 2 errors occurred: * Resource already exists: resource op0001-abc123 exists Lock Info: ID: op0001-abc123, Created: 2026-08-19T14:22:05Z

Problem

A terraform apply that was interrupted (CI timeout, laptop lid closed, someone's Ctrl-C during the plan phase), and every run since then refuses to start:

Error acquiring the state lock
Error message: 2 errors occurred:
  * Resource already exists: resource op0001-abc123 exists
Lock Info: ID: op0001-abc123, Created: 2026-08-19T14:22:05Z

The created timestamp is hours old. No Terraform process is running anywhere. The lock is simply stale.

Root cause

Terraform locks state on every write operation to prevent concurrent modification. The lock lives in the backend — a DynamoDB item for the S3 backend, a blob for Azure, an object for GCS — and it is only released when the process exits cleanly. A killed process leaves the lock row in place, and Terraform refuses to guess whether another runner actually holds it: the safe behavior is to fail loudly, which this error is.

The dangerous reflex is treating the error as a race and deleting lock infrastructure (DynamoDB tables, lock buckets) to clear it — that removes the concurrency protection for every future run. The safe path is specific: identify the lock, confirm it is truly orphaned, then force-unlock that exact ID.

fix preview — first 3 of 7 lines (bash), truncated:

# who is running terraform? (CI included: check for in-flight pipelines)
ps aux | grep -v grep | grep terraform || echo "no local process"

… 4 more lines in the fix

🔒 the fix — including 4 code blocks — is members-only. $1/mo unlocks everything.