HashiCorp Terraform Associate (004) Question 200
Single answer8 HCP TerraformA platform team is migrating from local Terraform execution to HCP Terraform so they can centralize state, standardize runs, and reduce the risk of developers using different local CLI versions. They want engineers to continue working from their terminals with the usual terraform plan and terraform apply workflow, but they want the actual operations to execute remotely in HCP Terraform. Which configuration best meets this requirement?
- A
Configure the HCP Terraform backend in the Terraform configuration and use a CLI-driven workflow so Terraform commands entered locally trigger remote runs in HCP Terraform.
- B
Store the state file in HCP Terraform, but keep execution local by setting TF_WORKSPACE for each engineer so version consistency is enforced automatically.
- C
Connect the workspace to a VCS repository and require all engineers to run terraform apply locally after each commit so HCP Terraform can sync the final state.
- D
Use Terraform Cloud Agents only; agents replace the need for remote execution settings and automatically intercept any local Terraform CLI command without backend configuration.
Show answer and explanation
Correct answer: A
Explanation
The best answer is the CLI-driven workflow with HCP Terraform configured in the Terraform settings. This approach lets practitioners keep using familiar Terraform CLI commands locally while the actual plan and apply steps run remotely in HCP Terraform, where state, logs, policies, and Terraform version settings can be centrally managed. This is a common migration pattern for teams moving away from purely local execution.
Key concepts reflected here:
- HCP Terraform supports multiple workflows, including VCS-driven and CLI-driven workflows.
- In a CLI-driven workflow, Terraform commands entered locally can initiate remote operations in HCP Terraform.
- Centralized remote execution helps ensure consistent Terraform versions and execution environments.
- Workspace selection variables such as TF_WORKSPACE do not replace backend/cloud configuration and do not enforce remote execution.
- Agents are used to provide network access from HCP Terraform runs into private environments; they complement remote execution but do not independently enable it.
These behaviors align with HashiCorp documentation for HCP Terraform workflows, remote state/execution, and agent usage.
- A. Correct.
Correct. HCP Terraform supports a CLI-driven workflow in which users run Terraform commands locally, but planning and applying occur remotely in HCP Terraform. This is typically configured by using the cloud block or the remote/HCP Terraform backend integration so state and execution are managed centrally. This directly satisfies the requirement to preserve the familiar CLI experience while standardizing execution and Terraform versions in the remote environment.
- B. Incorrect.
Incorrect. Setting TF_WORKSPACE only selects a workspace; it does not move plan/apply execution to HCP Terraform or enforce Terraform version consistency by itself. If execution remains local, developers can still use different local Terraform versions and environments, which is exactly the problem the team wants to solve.
- C. Incorrect.
Incorrect. A VCS-driven workflow is a valid HCP Terraform workflow, but it does not match the requirement that engineers continue to use terraform plan and terraform apply from their terminals as the primary workflow. In a VCS-driven model, runs are generally triggered by version control events rather than local CLI commands.
- D. Incorrect.
Incorrect. Terraform Cloud Agents allow HCP Terraform runs to access private infrastructure from agent pools, but they do not by themselves reroute ordinary local Terraform commands into HCP Terraform. Remote execution still depends on properly configuring HCP Terraform integration for the workspace and workflow.