HashiCorp Terraform Associate (004) Question 207
Single answer8a Use HCP Terraform to create infrastructureA platform team is moving from local Terraform CLI runs to HCP Terraform so they can standardize deployments and keep cloud credentials out of developer laptops. They have already created a workspace connected to their VCS repository. The Terraform configuration deploys resources to AWS. The team wants every VCS-triggered plan and apply in HCP Terraform to authenticate securely to AWS without storing long-lived AWS access keys in the repository or in developer environments. Which approach should they use?
- A
Configure the HCP Terraform workspace to use dynamic provider credentials for AWS so runs obtain temporary credentials at execution time
- B
Commit AWS access_key and secret_key values into Terraform variables in the repository and mark them as sensitive
- C
Require each developer to run terraform login locally so HCP Terraform can reuse their local AWS credentials during remote runs
- D
Store static AWS access keys as environment variables in every developer's shell profile and rely on the VCS integration to pass them to HCP Terraform
Show answer and explanation
Correct answer: A
Explanation
The best solution is to configure HCP Terraform to use dynamic provider credentials for AWS. This allows HCP Terraform runs to authenticate to AWS with temporary credentials issued at run time, which aligns with the team's goals of centralizing execution and avoiding long-lived secrets on developer machines or in source control. In contrast, sensitive variables only redact output and do not make it safe to store secrets in Git. Likewise, terraform login is for CLI authentication to HCP Terraform, not for passing cloud credentials into remote execution. HashiCorp documentation and best practices for HCP Terraform recommend using workspace-based credential management and, where supported, dynamic credentials to reduce secret sprawl and improve security for remote runs.
- A. Correct.
Correct. HCP Terraform supports dynamic provider credentials for certain cloud providers, including AWS, allowing runs to obtain short-lived credentials at run time instead of relying on long-lived static secrets. This is the preferred approach when the goal is to keep credentials out of laptops and source control while enabling secure VCS-driven runs in HCP Terraform.
- B. Incorrect.
Incorrect. Marking values as sensitive only affects how values are displayed in the UI and logs; it does not make storing long-lived cloud credentials in version control acceptable. Committing AWS keys to the repository is a significant security risk and violates best practices.
- C. Incorrect.
Incorrect. The terraform login command authenticates the Terraform CLI to HCP Terraform or Terraform Enterprise, not HCP Terraform runs to AWS. Remote runs execute in HCP Terraform's environment, so they cannot rely on a developer's local AWS credential chain.
- D. Incorrect.
Incorrect. HCP Terraform remote runs do not inherit each developer's local shell environment. Even if that were possible, distributing long-lived cloud credentials across multiple laptops would undermine the team's security objective.