Terraform: 'Error acquiring the state lock ... ConditionalCheckFailedException' (S3/DynamoDB), 'state blob is already locked' (Azure) or a lock held by another process. When is it safe to force-unlock?

Cause: Terraform locks the state for every operation that could write it (plan, apply, import, state commands) so two runs can't corrupt it. The error means a lock already exists. Usually that's either another run still in progress (a colleague, a CI pipeline, a parallel job on the same workspace), or a stale lock left behind when a run was killed (Ctrl+C twice, a CI job timeout or cancellation, a crashed runner, lost network). Fix: 1. Read the lock info in the error: ID, Path, Who (user@host), Operation and Created time. Check whether that run is still alive (CI pipeline history, ask the person). If it is, wait for it to finish; don't break a lock that a live apply holds. 2. If you're sure the lock is stale, remove it with terraform force-unlock <LOCK_ID> from the same configuration and workspace. Terraform's documentation warns to use it only when the lock-holder is definitely gone, because two concurrent writes can corrupt state. 3. After unlocking a run that died mid-apply, run terraform plan to see what was half-applied, and fix drift before applying again. Keep backups (S3 versioning, Azure blob versioning) so you can restore a previous state version if needed. 4. Prevent repeats: in CI, serialize runs per workspace (concurrency groups or resource locks in your pipeline), give jobs enough timeout, and let Terraform exit cleanly when cancelled. Use -lock-timeout=5m so short overlaps wait instead of failing. 5. Never disable locking (-lock=false) for normal operations. Verify: terraform plan runs without a lock error and shows the expected changes; your backend (DynamoDB table, S3 lock file or Azure blob lease) no longer shows the old lock. Sources: https://developer.hashicorp.com/terraform/language/state/locking https://developer.hashicorp.com/terraform/cli/commands/force-unlock