HashiCorp Terraform Associate (004) Question 206
Single answer8a Use HCP Terraform to create infrastructureA platform team wants developers to provision AWS infrastructure through HCP Terraform without storing long-lived AWS access keys in workspace variables. The team also wants each Terraform run to automatically receive short-lived AWS credentials and use them during plan and apply. Which approach should they implement?
- A
Configure HCP Terraform dynamic provider credentials with AWS by establishing trust between AWS IAM and HCP Terraform, then let the workspace use the generated temporary credentials during runs.
- B
Store an AWS access key ID and secret access key as sensitive workspace variables in HCP Terraform so the run environment can authenticate to AWS.
- C
Run Terraform locally on each developer workstation and use each developer's personal AWS CLI credentials, while still connecting the configuration to HCP Terraform for state storage only.
- D
Add the AWS credentials to the Terraform configuration using provider arguments so HCP Terraform can read them directly from version control during each run.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use HCP Terraform dynamic provider credentials for AWS. This allows HCP Terraform to authenticate to AWS using a trust relationship and obtain temporary credentials for each run, which aligns with the scenario's security and operational goals. Storing static credentials in workspace variables is functional but does not satisfy the requirement to avoid long-lived keys. Running locally with developer credentials undermines centralized remote execution. Embedding credentials in code is a security anti-pattern. This follows HashiCorp guidance for HCP Terraform authentication patterns and best practices for minimizing secret sprawl and using short-lived credentials wherever possible.
- A. Correct.
Correct. HCP Terraform supports dynamic provider credentials for certain providers, including AWS, so runs can obtain short-lived credentials automatically instead of relying on static secrets stored in variables. This is the recommended pattern for reducing credential exposure and centralizing secure access for remote runs in HCP Terraform.
- B. Incorrect.
Incorrect. Sensitive workspace variables can store static AWS credentials, and this may work technically, but it does not meet the stated goal of avoiding long-lived credentials. It is a common legacy approach, but dynamic credentials are the more secure and preferred solution when available.
- C. Incorrect.
Incorrect. Local execution with personal credentials bypasses the requirement that HCP Terraform runs should automatically receive credentials for plan and apply. It also creates inconsistency across users and reduces the governance, auditability, and centralized execution benefits of HCP Terraform remote runs.
- D. Incorrect.
Incorrect. Hardcoding credentials in provider blocks or committing them to version control is insecure and against Terraform and cloud security best practices. Provider arguments can accept credentials, but placing secrets in configuration files is not an appropriate way to authenticate HCP Terraform runs.