HashiCorp Terraform Associate (004) Question 212
Single answer8b Describe HCP Terraform collaboration and governance featuresA platform team is using HCP Terraform to manage infrastructure for several application teams. They want developers to continue using their normal Git-based workflow, but they also need stronger governance before infrastructure changes are applied. Specifically, they want every Terraform run to be centrally tracked, require at least one manual approval before apply in production, and prevent local CLI applies from bypassing that process. Which HCP Terraform approach best meets these requirements?
- A
Use VCS-driven workspaces connected to the repositories, configure the production workspace to require manual apply, and have teams apply changes through HCP Terraform runs instead of local CLI apply
- B
Use local execution mode in each workspace and rely on code review in GitHub or GitLab to provide the required approval before infrastructure changes are applied
- C
Give all developers workspace admin permissions so they can collaborate directly, then use speculative plans as the approval mechanism for production applies
- D
Use Terraform CLI locally with a remote backend in HCP Terraform, because the remote state backend alone enforces approval gates and centralized governance
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use HCP Terraform's VCS-driven workspace workflow with remote runs and manual apply protection for production. This aligns with HCP Terraform collaboration and governance capabilities: teams can collaborate through Git-based changes, HCP Terraform provides a centralized run history and execution model, and production changes can require a human approval step before apply. This is stronger governance than relying only on VCS reviews or remote state. HashiCorp documentation describes HCP Terraform workflows such as VCS-driven runs, speculative plans, remote operations, and manual confirmation before apply for applicable workspace settings. In practice, organizations use these features to standardize collaboration, improve auditability, and reduce the risk of untracked local changes reaching production.
- A. Correct.
Correct. VCS-driven workflows are a core HCP Terraform collaboration feature that integrates infrastructure changes with normal Git workflows. HCP Terraform can queue and track runs centrally, and production workspaces can be configured so applies require a manual confirmation step. By using HCP Terraform-managed runs rather than local CLI applies, the team ensures changes go through the centralized workflow instead of bypassing governance controls.
- B. Incorrect.
Incorrect. Local execution means Terraform runs happen on the operator's machine, which weakens centralized governance and tracking compared with remote runs in HCP Terraform. External code review in a VCS platform is helpful, but by itself it does not replace HCP Terraform's run controls or guarantee that apply occurs through an approved HCP Terraform workflow.
- C. Incorrect.
Incorrect. Broad admin permissions reduce governance rather than strengthen it. Speculative plans are useful for previewing changes, especially in pull request workflows, but they do not serve as an approval gate for actual production applies. Manual apply approval is a separate control.
- D. Incorrect.
Incorrect. Using HCP Terraform only as a remote backend provides remote state storage and locking-related benefits, but state storage alone does not enforce centralized approval workflows for applies. A common misconception is that remote state automatically provides the full governance model of HCP Terraform runs, but governance features come from using HCP Terraform's workspace run workflow.