HashiCorp Terraform Associate (004) Question 167
Single answer6b Describe state lockingYour team stores Terraform state for a shared production workspace in a remote backend. During a release, one engineer starts terraform apply and, a minute later, another engineer runs terraform plan against the same workspace. The second engineer sees a message indicating that the state is locked. What is the best explanation for this behavior and the most appropriate conclusion?
- A
Terraform uses state locking to prevent concurrent operations from writing or reading state in a way that could produce inconsistent results; the second operation must wait or fail until the lock is released.
- B
Terraform encrypts the state file while an apply is running, and a plan cannot read encrypted state until the apply completes.
- C
Terraform automatically creates a separate temporary state file for each user, so the lock message indicates the backend failed to merge those files.
- D
The lock appears because
terraform planmodifies infrastructure in the same way asterraform apply, so Terraform blocks both commands from running together.
Show answer and explanation
Correct answer: A
Explanation
Terraform state locking is a mechanism used by supported backends to prevent more than one Terraform operation from working with the same state at the same time. This is important because concurrent access can lead to race conditions, failed applies, or corrupted state. In practice, if one user is running terraform apply, another user attempting an operation that requires access to the same state may see a lock error or wait based on lock settings. This is why teams commonly use remote backends that support locking for shared environments. HashiCorp documentation and best practices emphasize remote state with locking support for collaboration, and also note that force-unlocking should be used carefully only when you are certain no active operation still holds the lock.
- A. Correct.
Correct. State locking exists to protect the state from concurrent operations against the same workspace or state file. When one operation such as
terraform applyholds the lock, another operation that also needs state access, such asterraform planin many remote-backend workflows, cannot proceed until the lock is released or times out. This prevents race conditions and state corruption. - B. Incorrect.
Incorrect. State locking is not the same as state encryption. Some backends can encrypt state at rest, but the lock message is about coordination of access, not encryption during apply. A plan is not blocked because state is encrypted.
- C. Incorrect.
Incorrect. Terraform does not solve concurrency by creating separate per-user temporary states and later merging them. In fact, merging concurrent state changes would be unsafe and unreliable. Locking is used specifically to avoid this situation.
- D. Incorrect.
Incorrect.
terraform plandoes not modify remote infrastructure. It reads configuration and current state to calculate proposed changes. The misconception is assuming Terraform blocks plan because it changes resources; the real reason is safe coordination of state access.