HashiCorp Terraform Associate (004) Question 201
Single answer8 HCP TerraformYour team has migrated a Terraform workflow from local execution to HCP Terraform. A workspace is configured to use the VCS-driven workflow, and the Terraform configuration includes an aws provider block that expects credentials from environment variables. The code plans successfully when engineers run it locally, but runs in HCP Terraform fail during provider authentication because no AWS credentials are available in the remote execution environment. You need to fix this without hardcoding secrets in the configuration or committing credential files to version control. What is the best solution?
- A
Add the AWS access key and secret key as Terraform input variables in the workspace, then reference them directly in the provider block.
- B
Store the AWS credentials as sensitive environment variables in the HCP Terraform workspace so remote runs can use them during plan and apply.
- C
Commit a shared credentials file to the repository and configure the provider to read from that file during HCP Terraform runs.
- D
Switch the workspace from remote execution to local execution so each engineer's local AWS CLI credentials are reused automatically.
Show answer and explanation
Correct answer: B
Explanation
In HCP Terraform, remote runs execute in an isolated environment, so local developer credentials are not automatically available. When a provider supports authentication through environment variables, the recommended approach is to set those values as workspace environment variables and mark secrets as sensitive. This keeps credentials out of Terraform configuration and out of version control while allowing remote plan and apply operations to authenticate successfully. Using Terraform input variables for cloud credentials is generally less appropriate than environment-based authentication for providers like AWS. Committing credential files is explicitly poor practice. See HashiCorp documentation for HCP Terraform workspace variables and provider authentication via environment variables.
- A. Incorrect.
This is not the best solution. Although Terraform variables can technically pass values into a provider block, cloud credentials are better handled as environment variables or a dynamic authentication mechanism rather than as Terraform input variables. Putting secrets into Terraform variables can increase exposure in configuration usage patterns and is not the recommended HCP Terraform approach for provider authentication when standard environment variables are supported.
- B. Correct.
This is correct. HCP Terraform supports workspace environment variables, including sensitive values, which are injected into the remote execution environment for plan and apply operations. For providers such as AWS, setting supported environment variables like AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY allows authentication without hardcoding credentials in code or storing them in version control.
- C. Incorrect.
This is incorrect and insecure. Committing credential files to version control exposes secrets and violates basic security practices. HCP Terraform is designed to avoid this by allowing sensitive environment variables and other secure credential injection methods instead of storing secrets in the repository.
- D. Incorrect.
This is incorrect because it avoids the problem rather than solving the remote execution requirement. In a VCS-driven HCP Terraform workflow, remote runs are a core feature, and switching back to local execution removes centralization, auditability, and consistency benefits. It also does not address how HCP Terraform itself should authenticate during remote runs.