HashiCorp Terraform Associate (004) Question 219
Single answer8d Configure and use HCP Terraform integrationA team currently runs Terraform locally from engineers' laptops and wants to standardize execution in HCP Terraform. They need remote plans and applies, shared state management, and a way for Terraform code to authenticate to AWS without storing long-lived cloud credentials in variables. Which configuration change best meets these requirements for an existing workspace connected to a VCS repository?
- A
Add a cloud block to the Terraform configuration that targets the organization and workspace, configure the workspace to use remote execution, and set up HCP Terraform workload identity integration with AWS so runs receive short-lived credentials.
- B
Keep local execution, add an S3 backend for state storage, and store AWS access keys as sensitive Terraform variables in the workspace so engineers do not need local credential files.
- C
Configure the workspace for local execution in HCP Terraform, use a local backend, and rely on each engineer's AWS CLI session because HCP Terraform automatically forwards those credentials to the run environment.
- D
Remove the VCS connection, run terraform login on one engineer's laptop, and commit the generated token file into the repository so HCP Terraform can use that token and inherit the engineer's AWS permissions.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use HCP Terraform as the execution platform by configuring the Terraform code with a cloud block and ensuring the workspace runs remotely. In HCP Terraform, remote execution provides centralized plan/apply operations and state management for team workflows. To avoid storing long-lived AWS credentials, the recommended approach is to configure HCP Terraform's workload identity integration with AWS so the run environment receives short-lived credentials dynamically. This is more secure than saving static access keys in variables. Relevant HashiCorp guidance covers the cloud block and workspace mapping for HCP Terraform integration, remote versus local execution modes, and dynamic provider credentials or workload identity for AWS.
- A. Correct.
Correct. The cloud block is the supported way to integrate Terraform CLI configuration with HCP Terraform workspaces. Using remote execution in the workspace shifts plan and apply operations into HCP Terraform, which also centralizes state management. For AWS authentication without long-lived static credentials, HCP Terraform can integrate through workload identity so runs obtain short-lived credentials instead of storing access keys in workspace variables. This aligns with current best practices for secure HCP Terraform integrations.
- B. Incorrect.
Incorrect. An S3 backend can store state remotely, but this does not move execution into HCP Terraform or provide HCP Terraform-managed remote runs. Storing long-lived AWS access keys in workspace variables is possible but does not satisfy the stated goal of avoiding long-lived credentials. This option mixes an external backend approach with static secrets, which is less secure and does not fully use HCP Terraform's integration capabilities.
- C. Incorrect.
Incorrect. Local execution means Terraform runs on the machine where the CLI is invoked, not in HCP Terraform's remote execution environment. A local backend would keep state on disk rather than providing shared centralized state. HCP Terraform does not automatically forward an engineer's local AWS CLI credentials into a separate remote run environment. This option reflects a common misunderstanding about how execution modes and credentials work.
- D. Incorrect.
Incorrect. Committing a user token file to version control is insecure and contrary to best practices. The terraform login command authenticates a local CLI user to HCP Terraform; it is not how HCP Terraform authenticates to AWS. HCP Terraform also does not inherit an engineer's personal AWS permissions from a committed token. This confuses user authentication to HCP Terraform with cloud provider authentication used during runs.