HashiCorp Terraform Associate (004) Question 221
Single answer8d Configure and use HCP Terraform integrationA platform team wants all Terraform operations for a production AWS workspace to run remotely in HCP Terraform so that plans and applies are centralized, state is stored there, and developers do not need long-lived AWS credentials on their laptops. They have already created an HCP Terraform workspace named prod-network. Which configuration change in the Terraform root module is the most appropriate to connect the local configuration to that existing workspace and enable remote execution?
- A
Add a cloud block to the Terraform configuration that specifies the HCP Terraform organization and the existing prod-network workspace name.
- B
Add a backend "remote" block and run terraform import on the workspace before terraform init can use HCP Terraform.
- C
Configure the AWS provider with assume_role only; HCP Terraform will automatically discover and attach the local configuration to the correct workspace.
- D
Store the terraform.tfstate file in a VCS repository connected to HCP Terraform; remote runs will begin automatically after the next commit.
Show answer and explanation
Correct answer: A
Explanation
The key requirement is to link the root module to the existing HCP Terraform workspace so Terraform operations run remotely and state is managed by HCP Terraform. For Terraform Associate 004, candidates should recognize that the recommended configuration for HCP Terraform integration is the terraform cloud block, where you specify the organization and workspace details. This supports remote runs, centralized state, and separation of user laptops from cloud credentials. The remote backend is an older mechanism and is not the preferred answer when asked how to configure HCP Terraform integration today. Also, provider authentication settings and VCS configuration solve different problems: provider settings control access to AWS, while VCS integration controls code-triggered runs. Best practices from HashiCorp documentation emphasize remote state management in HCP Terraform and avoiding storing state files in version control.
- A. Correct.
Correct. In current Terraform workflows, the recommended way to integrate a CLI-driven configuration with HCP Terraform is to use the terraform cloud block in the root module and identify the target organization and workspace. This associates the configuration with the existing HCP Terraform workspace and enables remote operations when initialized appropriately. HCP Terraform then manages state remotely and executes runs in its environment instead of relying on local execution.
- B. Incorrect.
Incorrect. The remote backend was historically used for Terraform Cloud/Enterprise integration, but the cloud block is the current recommended approach for HCP Terraform integration in Terraform CLI workflows. Also, terraform import is unrelated to connecting a configuration to an HCP Terraform workspace. Import is used to bring existing infrastructure resources into state, not to register or initialize a workspace connection.
- C. Incorrect.
Incorrect. Configuring the AWS provider affects how Terraform authenticates to AWS, but it does not connect the configuration to HCP Terraform or enable remote execution. HCP Terraform does not automatically map a local configuration to a workspace just because the provider is configured. Workspace association must be defined in Terraform configuration or through the relevant workflow.
- D. Incorrect.
Incorrect. HCP Terraform does not use a VCS repository as a replacement for Terraform state storage. State should be stored in HCP Terraform when using its remote execution and state management features. Connecting a VCS repository is a valid workflow for triggering runs, but committing terraform.tfstate to version control is not a best practice and does not correctly configure HCP Terraform integration.