Terraform State Lock Error — How to Fix "Error Acquiring the State Lock"

To fix the Terraform "Error acquiring the state lock" error, first check if a team member is running Terraform. If nobody is, the lock is stale from a crashed run — use terraform force-unlock LOCK_ID with the lock ID from the error message. Never force-unlock while someone is mid-apply — that corrupts your state file.

You run terraform plan and instead of a clean output, you get this:

Error: Error acquiring the state lock

Error message: ConditionalCheckFailedException: The conditional request failed
Lock Info:
  ID:        a1b2c3d4-e5f6-7890-abcd-ef1234567890
  Path:      my-company-terraform-state/prod/vpc/terraform.tfstate
  Operation: OperationTypeApply
  Who:       dev@laptop
  Version:   1.9.0
  Created:   2026-04-03 10:15:23.456789 +0000 UTC

Terraform acquires a state lock to protect the state from being
written by multiple users at the same time. Please resolve the
issue above and try again.

Do not panic. Do not immediately force-unlock. Read the lock info first — it tells you everything you need to know.

What the Error Means

Terraform uses a locking mechanism to prevent two people from modifying infrastructure at the same time. When someone runs terraform apply, Terraform writes a lock entry to DynamoDB (if you are using the S3 backend with DynamoDB locking). When the apply finishes, the lock is released.

If you see this error, it means someone or something already holds the lock. There are three possible reasons:

1. A team member is actively running terraform apply — this is the lock working correctly. Wait for them to finish.
2. A previous run crashed — someone's terminal closed, their laptop died, or a CI/CD job timed out mid-apply. The lock was never released.
3. A CI/CD pipeline is stuck — a GitHub Actions or Jenkins job is hanging with the lock held.

Step 1: Read the Lock Info

The error message gives you everything:

• Who: dev@laptop — who acquired the lock. Check with this person.
• Operation: OperationTypeApply — they were running apply, not just plan.
• Created: 2026-04-03 10:15:23 — when the lock was acquired. If this was hours ago, it is probably stale.
• ID: a1b2c3d4... — you need this to force-unlock.

Step 2: Check if Someone Is Running Terraform

Before doing anything else — ask your team. Send a message:

"Is anyone running terraform apply on prod/vpc right now?
I'm seeing a state lock from dev@laptop created at 10:15 UTC."

If someone says yes — wait. The lock is working as designed. It is protecting you from corrupting the state.

If everyone says no, or the lock is hours/days old, it is a stale lock from a crashed run.

Step 3: Force-Unlock the State

Only do this after confirming nobody is running Terraform.

terraform force-unlock a1b2c3d4-e5f6-7890-abcd-ef1234567890

Terraform will ask for confirmation:

Do you really want to force-unlock?
  Terraform will remove the lock on the remote state.
  This will allow local Terraform commands to modify this state, even though it
  may still be in use. Only 'yes' is accepted to confirm.

  Enter a value: yes

Terraform state has been successfully unlocked!

Now you can run terraform plan or terraform apply normally.

Force-unlocking while someone is mid-apply is one of the fastest ways to corrupt your state. The running apply writes to a state file that you have just unlocked for someone else to also write to. Both writes conflict. Your state no longer matches reality. Recovering from this can take hours of manual resource importing. A Slack message takes 10 seconds.

Why Crashed Runs Leave Stale Locks

Terraform releases the lock at the end of a successful or failed run. But if the process is killed — Ctrl+C during apply, laptop crash, CI/CD timeout, network disconnection — Terraform never gets the chance to release the lock.

The lock entry stays in DynamoDB indefinitely. It does not expire on its own. This is by design — an automatic expiry could release the lock while a very long apply is still running (some infrastructure changes take 20+ minutes).

How to Prevent This

1. Use CI/CD as the only way to apply. If only your pipeline runs terraform apply, there is no risk of two humans running it simultaneously. Developers run terraform plan locally, but all applies go through the pipeline.
2. Set timeouts on CI/CD jobs. A hanging job holds the lock forever. Set a 30-minute timeout on your Terraform apply step so it fails cleanly if something hangs.
3. Never Ctrl+C during apply. If you must cancel, let the current resource finish creating/destroying first. Interrupting mid-resource-creation is what causes partial state corruption.
4. Use -lock-timeout. Instead of failing immediately when the lock is held, Terraform can wait: terraform apply -lock-timeout=5m waits up to 5 minutes for the lock to be released before failing.

# Wait up to 5 minutes for the lock instead of failing immediately
terraform plan -lock-timeout=5m
terraform apply -lock-timeout=5m

What If Your State Is Corrupted

If you force-unlocked while someone was running and now your state is wrong, here is how to recover:

1. Go to your S3 bucket where state is stored
2. Enable "Show versions" on the state file
3. Find the last good version — the one from before the corruption
4. Download it and verify it looks correct
5. Upload it as the current version — or use terraform state push

This is why enabling versioning on your S3 state bucket is not optional. Without versioning, a corrupted state file is permanent.

Checking the Lock in DynamoDB

If you want to see the lock entry directly:

aws dynamodb scan \
  --table-name terraform-state-locks \
  --output json

This shows all current locks. Each entry has:

• LockID — the state file path
• Info — JSON with the lock details (who, when, operation)

An empty table means no active locks. If you see entries from days ago, they are stale and safe to remove.

Frequently Asked Questions

What causes the Terraform state lock error?

Another process holds the lock — either a team member running apply, a crashed run that never released the lock, or a stuck CI/CD pipeline. The lock exists to prevent two simultaneous writes to the state file.

Is it safe to run terraform force-unlock?

Only if nobody else is running Terraform against the same state. Force-unlocking during an active apply corrupts the state. Always verify with your team first.

How do I prevent state lock errors?

Use CI/CD as the single entry point for apply. Set job timeouts. Use -lock-timeout=5m to wait instead of failing immediately. Never Ctrl+C during apply.

What if my state is already corrupted?

Restore a previous version from S3 version history. This is why versioning on your state bucket is critical — without it, corruption is permanent.

Can I manually delete the lock from DynamoDB?

Yes, but prefer terraform force-unlock. If you must, go to DynamoDB console, find the lock table, delete the item. Same effect but skips Terraform's safety confirmation.

---

Set Up State Locking Properly

If you are hitting state lock issues, make sure your remote state with S3 and DynamoDB is configured correctly. A proper setup with versioning, encryption, and locking prevents most state-related disasters.