HashiCorp Terraform Associate (004) Question 223
Single answer8d Configure and use HCP Terraform integrationA team currently runs Terraform locally from developer laptops, but they want all plans and applies to execute in HCP Terraform so they can centralize state, use remote runs, and avoid storing cloud credentials in configuration files. They have already created an HCP Terraform organization and workspace. Which action should they take next to correctly integrate their existing Terraform configuration with HCP Terraform remote execution?
- A
Add a cloud block to the Terraform configuration that specifies the HCP Terraform organization and workspace, then set the required cloud provider credentials as workspace environment variables in HCP Terraform.
- B
Add a backend "remote" block and hardcode the cloud provider access keys directly in the Terraform configuration so HCP Terraform can use them during remote runs.
- C
Run terraform login on the HCP Terraform workspace and commit the generated API token into version control so the remote runners can authenticate automatically.
- D
Configure an S3 backend for state storage and use terraform apply -auto-approve from developer laptops, because HCP Terraform only provides a UI for viewing runs, not executing them.
Show answer and explanation
Correct answer: A
Explanation
The best next step is to connect the configuration to the existing HCP Terraform workspace using the Terraform cloud integration and then provide provider credentials securely through HCP Terraform workspace variables or variable sets. In current Terraform workflows, the cloud block is the standard way to configure HCP Terraform or Terraform Enterprise integration for remote operations. This supports centralized state and remote execution without placing secrets in code. HashiCorp documentation and best practices emphasize keeping credentials out of configuration files and using HCP Terraform variables, variable sets, or supported dynamic credentials instead. Candidates should also recognize that terraform login is for local CLI authentication, not for passing secrets to remote runners, and that HCP Terraform supports full remote plan/apply workflows rather than acting only as a state viewer.
- A. Correct.
Correct. For Terraform workflows integrated with HCP Terraform, a cloud block can be used to connect the configuration to an HCP Terraform organization and workspace. HCP Terraform can then perform remote operations, including plan and apply, while storing state centrally. Provider credentials should be supplied securely through workspace environment variables or variable sets rather than embedded in code. This matches recommended practice for remote execution and secret management.
- B. Incorrect.
Incorrect. Although older configurations may use a remote backend, hardcoding cloud provider credentials in Terraform code is not a recommended or secure integration pattern. HCP Terraform remote runs should use workspace environment variables, variable sets, or dynamic credentials where supported. The main misconception is assuming that putting secrets directly in configuration is required for remote execution.
- C. Incorrect.
Incorrect. terraform login is run on a user's local machine to obtain a user API token for Terraform CLI interactions with HCP Terraform or Terraform Enterprise. That token should not be committed to version control. HCP Terraform remote runners do not authenticate by reading a token from your repository this way. The misconception is confusing local CLI authentication with how remote runs obtain credentials.
- D. Incorrect.
Incorrect. HCP Terraform does far more than display run results; it can execute remote plans and applies, manage state, enforce policy, and integrate with VCS workflows. Using an S3 backend and continuing to run apply from laptops does not meet the stated goal of moving execution into HCP Terraform. This distractor reflects a misunderstanding of HCP Terraform capabilities.