HashiCorp Terraform Associate (004) Question 160
Single answer6a Describe the local backendA small development team is using Terraform to provision resources for a non-production environment. Their configuration does not define a backend block, and they run Terraform from a shared project directory on one engineer's workstation. Soon, other engineers begin copying the configuration to their own laptops and running terraform plan and terraform apply. The team notices inconsistent plans and is concerned about accidentally overwriting each other's state. Which action best addresses the root cause while accurately describing how the local backend works?
- A
Keep using the default local backend, because Terraform automatically synchronizes the state file between all team members' machines.
- B
Add a local backend block with a custom path, because the local backend stores state in a file on the machine where Terraform runs and does not provide remote sharing or collaboration features.
- C
Switch to the local backend with state locking enabled through Terraform Cloud, because the local backend supports built-in remote locking when multiple users run Terraform from different laptops.
- D
Remove the state file from disk and rely on
.terraformplugin data instead, because the local backend recreates infrastructure state from downloaded provider metadata when needed.
Show answer and explanation
Correct answer: B
Explanation
When no backend is explicitly configured, Terraform uses the local backend by default. The local backend stores state locally on disk, usually in terraform.tfstate within the working directory unless a custom path is configured. This is acceptable for individual use or simple experimentation, but it is not appropriate for collaborative workflows where multiple operators need a shared source of truth. In the scenario, each engineer is effectively maintaining a separate local state file, which causes inconsistent plans and risks state divergence. HashiCorp documentation and Terraform best practices recommend using a remote backend for team-based workflows so state can be shared and managed centrally. The key concept for the exam is that the local backend is file-based and local to the execution environment; it does not provide the collaboration benefits of remote backends.
- A. Incorrect.
Incorrect. By default, if no backend is configured, Terraform uses the local backend and stores state in a local file, typically
terraform.tfstatein the working directory. That file is not automatically synchronized across different users' machines. This option reflects a common misconception that Terraform itself handles team state sharing when using local state. - B. Correct.
Correct. The local backend stores state on the local filesystem of the machine running Terraform. You can customize the state file location with a
backend "local"configuration, but it remains local to that system unless you separately share the filesystem. This does not solve team collaboration by itself, but it accurately describes the backend and identifies the root cause: each engineer is using a different local copy of state, leading to drift and inconsistent plans. - C. Incorrect.
Incorrect. Terraform Cloud is a remote backend, not a feature of the local backend. The local backend does not provide built-in remote collaboration capabilities across multiple laptops. While local state can support locking in certain local contexts, it does not solve the team's distributed workflow problem described here.
- D. Incorrect.
Incorrect. Provider plugins and the
.terraformdirectory do not contain authoritative infrastructure state. Terraform state is stored in the state file, and removing it does not allow Terraform to reconstruct full state from plugin metadata. This option confuses provider installation data with resource state tracking.