HashiCorp Terraform Associate (004) Question 158
Single answer6 Terraform state managementA team has been managing AWS infrastructure with Terraform using a local state file stored on an engineer's laptop. Multiple engineers now need to collaborate safely on the same configuration, and the team wants to prevent simultaneous state modifications that could corrupt state. They decide to migrate to an S3 backend. Which additional configuration should they use to best support safe collaborative state management?
- A
Configure a DynamoDB table for state locking and consistency alongside the S3 backend
- B
Enable versioning on the S3 bucket only, because versioning prevents concurrent applies
- C
Store the terraform.tfstate file in an S3 bucket path organized by workspace, without any locking mechanism
- D
Use the local backend with terraform refresh before every apply, because refresh prevents state conflicts
Show answer and explanation
Correct answer: A
Explanation
For collaborative Terraform usage, remote state storage is preferred over local state because it gives the team a shared source of truth. With AWS, the common pattern is to use the S3 backend for remote state storage and DynamoDB for state locking. State locking is important because Terraform state is not designed for simultaneous modification by multiple users. S3 versioning is also a strong best practice because it provides recovery points for the state file, but versioning alone does not prevent concurrent operations. HashiCorp documentation for the S3 backend specifically describes the use of S3 for state storage and DynamoDB for locking in team environments.
- A. Correct.
Correct. When using the S3 backend for shared remote state, Terraform can use a DynamoDB table for state locking. This helps prevent multiple users from writing to the same state at the same time, which is a core requirement for safe collaboration. In practice, S3 provides shared storage for the state file, while DynamoDB provides the lock that prevents concurrent operations. This is a common and recommended pattern for team-based Terraform workflows on AWS.
- B. Incorrect.
Incorrect. S3 bucket versioning is a valuable best practice because it helps recover previous versions of the state file if it is changed or corrupted. However, versioning does not provide state locking and does not stop two engineers from running Terraform at the same time. A candidate might choose this option because versioning improves safety, but it does not address the specific requirement to prevent simultaneous state modifications.
- C. Incorrect.
Incorrect. Simply placing the state file in S3 centralizes storage, but without locking, concurrent Terraform operations can still occur and lead to race conditions or state corruption. Organizing by workspace may help separate environments, but it does not solve the locking problem for a shared state file used by multiple engineers.
- D. Incorrect.
Incorrect. The local backend does not support the shared remote workflow the team needs. Running terraform refresh updates state to reflect real infrastructure, but it does not coordinate access among multiple users and does not prevent concurrent writes. This option reflects a common misconception that refresh solves collaboration or locking issues.