HashiCorp Terraform Associate (004) Question 156
Single answer6 Terraform state managementA platform team currently stores Terraform state in a local file on an engineer's laptop. After a recent incident, two engineers applied changes from different machines and one engineer accidentally committed a state file containing sensitive values to a Git repository. The team wants to improve collaboration, reduce the risk of concurrent state updates, and avoid keeping sensitive state data in local files. Which action is the BEST next step?
- A
Move the state to a remote backend that supports state locking and shared access, then reinitialize the working directory
- B
Keep using the local backend, but add the state file to .gitignore and require engineers to run terraform refresh before each apply
- C
Store the state file in a shared network drive so all engineers can manually coordinate changes
- D
Use terraform taint on critical resources before each apply so Terraform can safely resolve conflicting state changes
Show answer and explanation
Correct answer: A
Explanation
Terraform state management best practice for teams is to use a remote backend rather than local state. State is Terraform's source of truth for mapping configuration to real infrastructure, and it often contains sensitive information. In collaborative environments, local state creates risks such as conflicting updates, inconsistent state copies, and accidental exposure through source control. Remote backends help centralize state and, where supported, provide state locking to prevent simultaneous writes. After changing backend configuration, terraform init is used to initialize the backend and migrate state. This aligns with HashiCorp guidance to use remote state storage for team workflows and to protect state appropriately.
- A. Correct.
Correct. A remote backend is the recommended solution for collaborative Terraform workflows. Remote backends centralize state, allow teams to share a single source of truth, and many support state locking to prevent concurrent operations from corrupting state. Reinitializing with terraform init after changing the backend is required so Terraform can configure the new backend and migrate state if needed. This also reduces reliance on state files stored on individual laptops, which is important because Terraform state can contain sensitive data.
- B. Incorrect.
Incorrect. Adding the file to .gitignore helps prevent accidental commits, but it does not solve the core collaboration problem. The local backend still leaves each engineer with a separate copy of state, increasing the risk of drift, overwrite, and inconsistent plans. Running terraform refresh does not provide locking and is not a substitute for shared remote state management.
- C. Incorrect.
Incorrect. A shared network drive may make the file accessible to multiple users, but it does not provide Terraform backend features such as reliable state locking, backend configuration, and managed access patterns. Manual coordination is error-prone and does not meet Terraform best practices for collaborative state management.
- D. Incorrect.
Incorrect. terraform taint marks resources for recreation; it has nothing to do with resolving concurrent state updates or securing state storage. Using taint in this scenario would increase risk by causing unnecessary resource replacement without addressing the underlying state management problem.