HashiCorp Terraform Associate (004) Question 169
Single answer6b Describe state lockingA platform team stores Terraform state for a shared AWS environment in an S3 backend with a DynamoDB table configured for state locking. During a deployment, one engineer starts terraform apply from their workstation. A few seconds later, another engineer accidentally runs terraform apply against the same workspace from a CI job. The CI job fails with a message indicating that the state is locked. What is the best explanation for this behavior?
- A
Terraform acquired a lock for the first operation, and the second operation was prevented from modifying the same state at the same time.
- B
Terraform detected a provider version mismatch and reported it as a state lock to prevent corruption.
- C
The S3 backend allows only one read operation at a time, so the second command failed until the first command finished downloading the state file.
- D
DynamoDB stores a full copy of the Terraform state, and the second operation failed because the state copy was out of date.
Show answer and explanation
Correct answer: A
Explanation
This scenario tests understanding of Terraform state locking in a real team environment. State locking helps protect the state file from concurrent writes that could lead to corruption or lost updates. In the S3 backend configuration commonly used on AWS, the state itself is stored in S3 and a DynamoDB table is used to manage the lock. When one user runs an operation that may update state, Terraform acquires the lock first. A second operation against the same state cannot proceed until the lock is released, which is why the CI job failed. This is a core best practice for shared remote state in collaborative workflows. HashiCorp documentation describes state locking as a mechanism to prevent others from acquiring the lock and potentially corrupting the state during write operations.
- A. Correct.
Correct. State locking exists to prevent concurrent operations from writing to the same state simultaneously. With an S3 backend using DynamoDB for locking, Terraform creates a lock record before operations that could write state. If another
planorapplyattempts to acquire the same lock, Terraform blocks or fails that operation, depending on timing and options, to avoid state corruption or conflicting updates. - B. Incorrect.
Incorrect. Provider version mismatch can cause initialization or planning issues, but it is not what state locking is for. A lock error specifically relates to coordination of access to the state, not provider plugin compatibility.
- C. Incorrect.
Incorrect. S3 is used to store the remote state object, but the locking behavior in this scenario comes from the configured DynamoDB lock table, not from S3 restricting reads. Multiple clients can read the state object; the issue is preventing concurrent state-changing operations.
- D. Incorrect.
Incorrect. DynamoDB does not store the full Terraform state in this backend design. For the S3 backend, the state file is stored in S3, while DynamoDB is used to coordinate locking. The failure is due to an active lock, not an outdated duplicate state copy.