Use Terraform outside the core workflow →hardMultiple ChoiceObjective-mapped

TF-004 Use Terraform outside the core workflow Practice Question

Exhibit

Error: Error acquiring the state lock
...
Lock Info:
  ID:        abc123
  Path:      terraform.tfstate
  Operation: OperationTypeInvalid
  Who:       user@host
  Version:   0.12.0
  Created:   2019-10-17 12:00:00
  Info:

Refer to the exhibit. A user encounters this error while running 'terraform plan'. What is the best course of action?

⚠ Common exam trap

Terraform exams often test the misconception that waiting or changing backends is a safe workaround, when in fact only verifying the lock holder and then using 'force-unlock' is the proper recovery procedure.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Run 'terraform force-unlock' with the lock ID after verifying no other process holds the lock

The error indicates that the state file is locked, which prevents concurrent operations to avoid corruption. Running 'terraform force-unlock' with the lock ID is the correct recovery step, but only after verifying that no other Terraform process is actively using the state. This command releases the lock from the backend (e.g., S3, Consul, or Terraform Cloud), allowing subsequent plans or applies to proceed.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Run 'terraform force-unlock' with the lock ID after verifying no other process holds the lock
Why this is correct
When Terraform encounters a state lock, it prevents concurrent operations that could corrupt the state file. If a previous operation failed or was interrupted, the lock might persist, becoming "stale." The `terraform force-unlock <LOCK_ID>` command is specifically designed to release such a stale lock, but it must only be used after confirming that no other legitimate Terraform process is actively holding the lock to prevent state corruption.
✗
Change the backend to local and run plan again
Why it's wrong here
Changing the backend configuration from a remote, shared backend (like S3, Azure Blob Storage, etc.) to `local` would effectively abandon the existing remote state file and its associated lock. This action would create a new, empty local state, causing a complete loss of tracking for all previously deployed resources and leading to severe state drift or resource orphan issues. It does not resolve the original remote state lock but bypasses it destructively.
✗
Delete the state file and run terraform init
Why it's wrong here
Deleting the Terraform state file (`terraform.tfstate`) is an extremely destructive action that would permanently sever Terraform's connection to all managed infrastructure resources. Without the state file, Terraform loses all knowledge of what resources it created, their configurations, and their dependencies. This would necessitate manually importing all existing resources or risking their accidental destruction or duplication upon subsequent `terraform apply` operations.
✗
Wait for 5 minutes and retry
Why it's wrong here
While some distributed locking mechanisms have built-in timeouts, Terraform's state locks, especially those managed by remote backends, are often persistent until explicitly released. Waiting for an arbitrary period like 5 minutes is unlikely to resolve a stale lock caused by an interrupted operation, as the lock mechanism is designed to prevent concurrent access rather than automatically expire without confirmation of completion or release.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

TF-004 Use Terraform outside the core workflow Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question