The Terraform lock nobody owns | Labs | DevOps in Practice

The production network pipeline cannot plan because the remote state is locked by a CI job that no longer exists.

Capture the lock identity. Do not force-unlock until you prove that its owner is gone.

Try: terraform plan

Terminal command

The state is available without concurrent writers.

The orphaned lock was removed only after its owner was disproved, and a clean plan acquired and released a new lock.

Lesson

Never treat force-unlock as the first response. Identify the owner, verify the operation is truly dead, unlock the exact ID, and use plan—not apply—as the first recovery check.

No editor required

This editor is not used in this lab.

Key concepts

State locking prevents concurrent writers

Only one operation should mutate a state snapshot at a time.

What it is

Terraform locks supported remote backends before operations that may write state.

In this incident

A cancelled run left lock 8b6f behind, so new plans cannot acquire it.

Why it matters

Removing a live lock can allow two writers and corrupt infrastructure state.

Verify ownership with independent evidence

A stale timestamp alone is not proof that a writer is gone.

What it is

Lock metadata identifies the operation, owner, creation time, and often the automation run.

In this incident

Both the CI system and process inventory show that run 91842 is no longer active.

Why it matters

Two independent signals reduce the chance of unlocking underneath a slow operation.

force-unlock is recovery, not routine

It removes coordination protection without changing resources.

What it is

terraform force-unlock removes one lock ID from the configured backend.

In this incident

Only orphaned lock 8b6f is removed after its owner is disproved.

Why it matters

Follow with plan to re-acquire state safely and inspect pending drift.