HashiCorp Terraform Associate (004) Question 202
Single answer8 HCP TerraformYour team uses HCP Terraform to manage AWS infrastructure across development and production workspaces. A security review finds that AWS access keys are hardcoded in Terraform variable values inside multiple workspaces. You need to redesign authentication so runs in HCP Terraform no longer rely on long-lived static AWS credentials, while still allowing each workspace to assume the correct AWS IAM role at run time. Which solution best meets this requirement?
- A
Configure HCP Terraform dynamic provider credentials with AWS, establish the required trust relationship in AWS IAM, and map each workspace to the appropriate role so runs receive short-lived credentials automatically.
- B
Store the AWS access key and secret key as sensitive Terraform variables in each workspace and mark them as write-only so users cannot read them after saving.
- C
Commit the AWS credentials into a private module used by all workspaces, then reference that module from each root configuration to centralize secrets management.
- D
Use local values in the Terraform configuration to construct the AWS credentials dynamically from workspace names so each workspace gets a different credential set.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use HCP Terraform dynamic provider credentials for AWS. This feature allows HCP Terraform runs to authenticate to AWS using short-lived credentials obtained through a trust relationship, rather than storing long-lived AWS access keys in workspace variables. In practice, teams configure AWS IAM to trust HCP Terraform's identity flow and then specify which role each workspace should assume. This is the recommended pattern for improving security, reducing secret sprawl, and supporting least-privilege access per workspace. Sensitive variables in HCP Terraform are useful when secrets must be stored, but they do not eliminate the risk of static credentials. HashiCorp documentation and best practices for HCP Terraform emphasize using dynamic credentials where supported, especially for cloud providers such as AWS.
- A. Correct.
Correct. HCP Terraform supports dynamic provider credentials for AWS so runs can obtain short-lived credentials instead of using static long-lived access keys. The typical setup involves configuring workload identity / trusted federation between HCP Terraform and AWS IAM, then assigning the appropriate IAM role per workspace or variable set. This aligns with security best practices by eliminating hardcoded secrets and limiting credential lifetime.
- B. Incorrect.
Incorrect. Marking variables as sensitive helps reduce exposure in the UI and logs, but the underlying approach still depends on long-lived static AWS credentials. The requirement specifically says runs should no longer rely on static credentials. Sensitivity settings improve handling of secrets; they do not replace static secrets with ephemeral credentials.
- C. Incorrect.
Incorrect. Storing credentials in a private module is not a valid secrets-management solution and is a serious security anti-pattern. Modules are for reusable infrastructure logic, not for embedding provider secrets. This would still use static credentials and would increase the blast radius if the module source were exposed.
- D. Incorrect.
Incorrect. Terraform local values are just expressions inside configuration and cannot securely generate valid AWS access keys and secret keys. AWS credentials must come from AWS identity mechanisms, such as IAM users, IAM roles, or federation. Constructing strings based on workspace names does not create authenticated AWS credentials.