HashiCorp Terraform Associate (004) Question 211
Select 28b Describe HCP Terraform collaboration and governance featuresA platform team is moving Terraform workflows from local execution to HCP Terraform. They want application teams to continue contributing infrastructure code through Git, but they must also enforce governance controls so that production changes are reviewed, policy-checked, and applied only by authorized people. Which HCP Terraform features should the platform team use to meet these requirements?
- A
Connect workspaces to the teams' VCS repositories and use run triggers so commits automatically create runs
- B
Use Sentinel policies in policy sets and require workspace runs to pass policy checks before apply
- C
Use team-based RBAC so some users can queue plans while only approved operators can apply production runs
- D
Store all Terraform state files in each engineer's local backend so peer review can happen before state is updated
- E
Disable speculative plans because they bypass governance and prevent policy enforcement
Show answer and explanation
Correct answers: B, C
Explanation
The best answers are the HCP Terraform features that directly address governance and controlled collaboration in production: Sentinel policy sets and team-based RBAC. Sentinel provides policy as code so organizations can enforce mandatory checks during runs. Team permissions let organizations control who can view, plan, queue, or apply changes, which is important for separating development from production approval responsibilities.
VCS integration is also an important collaboration feature in HCP Terraform, but the wording in option 1 is inaccurate because VCS-driven runs come from the VCS connection itself, while run triggers are used to start downstream workspace runs after upstream workspace changes. Option 4 is the opposite of HCP Terraform best practice because centralized remote state and remote execution are core collaboration features. Option 5 reflects a common misconception: speculative plans support review and collaboration and are not inherently a governance bypass.
These behaviors align with HCP Terraform documentation on VCS-driven workflows, team and workspace permissions, remote state and remote execution, and Sentinel policy enforcement.
- A. Incorrect.
Incorrect. VCS-driven workflows are a collaboration feature in HCP Terraform, but the statement adds 'use run triggers so commits automatically create runs,' which is misleading. A VCS connection itself can automatically queue runs from commits. Run triggers are a separate feature used to chain workspace runs based on upstream workspace changes, not to make VCS commits create runs. Because the option combines a correct idea with an incorrect mechanism, it is not the best answer.
- B. Correct.
Correct. Sentinel is an HCP Terraform governance feature used to enforce policy as code. Organizations can attach policy sets to workspaces so runs must satisfy required policy checks before they can proceed. This is a standard way to enforce guardrails such as approved resource types, tagging rules, cost controls, or restrictions on production changes.
- C. Correct.
Correct. HCP Terraform supports team-based access control so organizations can separate permissions such as read, plan, write, and apply. In a production workflow, this allows broader collaboration for planning and review while restricting who can confirm or apply changes. This directly supports controlled approvals and operational separation of duties.
- D. Incorrect.
Incorrect. Using local backends for state works against HCP Terraform's collaboration and governance model. HCP Terraform is designed to centralize state, runs, permissions, and auditability. Local state on engineers' machines reduces visibility, increases risk, and does not support controlled collaboration.
- E. Incorrect.
Incorrect. Speculative plans are intended for collaboration and review, especially for VCS-driven changes such as pull requests. They do not apply infrastructure, but they still provide visibility into proposed changes. Disabling them is not a governance requirement, and policy enforcement applies to normal runs according to workspace and policy configuration.