HashiCorp Terraform Associate (004) Question 199
Single answer8 HCP TerraformA platform team is migrating from local Terraform execution to HCP Terraform. They want every infrastructure change to be proposed automatically when a pull request is opened, but they do not want changes to be applied until after code review and an explicit approval step. They also want Terraform state to be stored centrally without requiring engineers to manage remote backend credentials on their laptops. Which HCP Terraform workspace configuration best meets these requirements?
- A
Create a VCS-connected workspace with automatic speculative plans enabled for pull requests and apply runs requiring confirmation in the HCP Terraform UI.
- B
Create a CLI-driven workspace and require each engineer to run terraform plan locally against a local backend, then upload the state file to HCP Terraform after approval.
- C
Create a VCS-connected workspace and enable auto-apply so that every pull request plan is automatically applied after the plan completes successfully.
- D
Create a CLI-driven workspace that stores state in each engineer's local .terraform directory, and use HCP Terraform only for variable storage and notifications.
Show answer and explanation
Correct answer: A
Explanation
The best answer is the VCS-connected workspace with speculative plans for pull requests and manual apply approval. In HCP Terraform, VCS-driven workflows are designed to integrate with version control systems so that commits and pull requests trigger runs automatically. For pull requests, HCP Terraform creates speculative plans, which let reviewers see the impact of proposed changes without applying them. State is stored remotely by HCP Terraform for the workspace, which centralizes state management and avoids distributing backend credentials to individual users. To preserve an approval gate, the team should not enable auto-apply. This aligns with HashiCorp best practices for team-based workflows in HCP Terraform: use VCS connections for automated planning, remote state for collaboration, and manual confirmation when governance requires human approval.
- A. Correct.
Correct. A VCS-connected workspace in HCP Terraform can automatically trigger speculative plans for pull requests, which is exactly how teams preview proposed changes during code review. HCP Terraform also stores state remotely for the workspace, removing the need for individual engineers to manage backend credentials locally. By not enabling auto-apply, applies still require an explicit confirmation step, which satisfies the approval requirement.
- B. Incorrect.
Incorrect. A CLI-driven workspace can be useful in some workflows, but this option contradicts the requirement to automate proposals on pull requests. It also incorrectly suggests using a local backend and manually uploading state, which is not the intended HCP Terraform workflow. HCP Terraform workspaces manage remote state directly; engineers do not manually upload state files after each approval.
- C. Incorrect.
Incorrect. A VCS-connected workspace is part of the right direction, but enabling auto-apply violates the requirement for an explicit approval step after review. Auto-apply is appropriate only when teams want successful runs to apply automatically without manual confirmation.
- D. Incorrect.
Incorrect. HCP Terraform is not intended to leave state in each engineer's local .terraform directory for collaborative workflows. One of its core benefits is centralized remote state management. This option also fails to provide automatic pull request planning in the way VCS-driven workflows support.