HashiCorp Terraform Associate (004) Question 159
Single answer6 Terraform state managementA team has been managing AWS infrastructure with Terraform using a local state file stored on an engineer's laptop. After several incidents where multiple engineers made changes from different machines and accidentally overwrote each other's state, the team decides to move to a shared remote backend. They want to reduce the risk of concurrent state modifications and make the current state available to all team members. Which solution best meets these requirements?
- A
Configure the S3 backend for state storage and enable DynamoDB state locking for the Terraform state file
- B
Store the state file in a shared Git repository and require engineers to pull the latest version before running terraform apply
- C
Use terraform refresh before every plan and apply so Terraform can rebuild state from the real infrastructure
- D
Configure the local backend on a network file share so all engineers use the same terraform.tfstate file
Show answer and explanation
Correct answer: A
Explanation
Terraform state management for teams should use a remote backend so the state is stored in a shared, centralized location rather than on an individual's machine. For AWS-based workflows, a common best practice is the S3 backend with DynamoDB table-based state locking. This helps ensure that only one Terraform operation can modify state at a time, reducing the risk of corruption or lost updates. HashiCorp documentation on backends and state locking emphasizes using remote state for collaboration and using supported locking mechanisms where available. Git repositories and shared file systems are common misconceptions because they provide file sharing or version history, but they do not provide the backend behavior and locking guarantees needed for safe Terraform state management.
- A. Correct.
Correct. Using a remote backend such as Amazon S3 centralizes the state so all team members work from the same source of truth. Adding DynamoDB locking helps prevent concurrent operations from modifying state at the same time, which is a standard Terraform pattern for collaborative workflows on AWS. This addresses both requirements: shared access to state and protection against simultaneous writes.
- B. Incorrect.
Incorrect. Although Git provides version history, it is not a Terraform state locking mechanism and is not a recommended way to manage active state files for team operations. State files can change frequently, may contain sensitive data, and Git does not prevent two engineers from running Terraform at the same time against stale state.
- C. Incorrect.
Incorrect. terraform refresh updates state based on real infrastructure, but it does not solve the coordination problem of multiple users changing the same state concurrently. It also does not provide a shared source of truth or locking. Relying on refresh to reconstruct state is a misunderstanding of its purpose.
- D. Incorrect.
Incorrect. A network file share may make the file accessible to multiple users, but the local backend does not provide robust remote state features such as proper backend-managed locking and collaboration controls. This approach still risks corruption and race conditions and is not a best-practice team solution.