HashiCorp Terraform Associate (004) Question 205
Single answer8a Use HCP Terraform to create infrastructureA platform team wants application developers to provision AWS infrastructure through HCP Terraform without needing the AWS CLI or local cloud credentials on their laptops. The team has already pushed the Terraform configuration to a VCS repository and connected that repository to an HCP Terraform workspace. They want plans and applies to run remotely in HCP Terraform whenever code is merged to the main branch. Which action should they take next to enable this workflow securely?
- A
Configure the workspace to use remote execution and add the required AWS provider credentials as environment variables or a dynamic credentials integration in HCP Terraform
- B
Require each developer to run terraform apply locally with their own AWS credentials, then upload the state file to HCP Terraform after the deployment completes
- C
Store AWS access keys directly in Terraform variable values inside the configuration so HCP Terraform can read them during plan and apply
- D
Disable VCS-driven runs and use terraform import from each developer workstation so HCP Terraform can infer the needed AWS permissions automatically
Show answer and explanation
Correct answer: A
Explanation
HCP Terraform can create infrastructure by running Terraform remotely in a workspace connected to a VCS repository. In this model, developers do not need local cloud credentials because the plan and apply occur in HCP Terraform's execution environment. To make that work, the workspace must be configured for remote execution and supplied with provider credentials securely, typically through environment variables marked sensitive or through supported dynamic credentials integrations. This aligns with HashiCorp best practices for VCS-driven workflows, remote operations, and secret handling. The other options reflect common misconceptions: local execution with manual state handling bypasses HCP Terraform's workflow controls, embedding credentials in code is insecure, and terraform import does not solve authentication or automated provisioning requirements.
- A. Correct.
Correct. To create infrastructure through HCP Terraform without requiring local cloud credentials, the workspace should use remote execution so Terraform runs in HCP Terraform's execution environment. HCP Terraform then needs access to provider credentials, commonly through workspace environment variables or, where supported, dynamic provider credentials. This is the standard secure pattern for VCS-driven workflows in HCP Terraform.
- B. Incorrect.
Incorrect. This defeats the goal of using HCP Terraform to centralize execution and avoid local cloud credentials. Uploading state after local applies is not the intended operational model for HCP Terraform remote runs and introduces drift, security, and process consistency problems.
- C. Incorrect.
Incorrect. Hardcoding cloud credentials in Terraform configuration or normal Terraform variables is an insecure practice. Secrets should not be committed to version control. HCP Terraform supports sensitive variables and environment variables, and best practice is to use those or dynamic credentials instead of embedding secrets in code.
- D. Incorrect.
Incorrect. terraform import is used to bring existing infrastructure under Terraform management, not to grant provider permissions or replace normal plan/apply workflows. Disabling VCS-driven runs also conflicts with the team's requirement to trigger remote runs automatically from merges to the main branch.