HashiCorp Terraform Associate (004) Question 208
Single answer8a Use HCP Terraform to create infrastructureA platform team is moving from local Terraform CLI workflows to HCP Terraform so that all infrastructure changes for a shared AWS environment are executed remotely and consistently. They want developers to keep editing code in a VCS repository, automatically trigger runs when changes are merged, and avoid storing long-lived AWS keys in the repository or on developer laptops. Which solution best meets these requirements?
- A
Create an HCP Terraform workspace connected to the VCS repository, configure the workspace for remote execution, and supply AWS credentials to HCP Terraform through workspace variables or a dynamic provider credential integration.
- B
Ask each developer to run terraform apply locally with their own AWS CLI credentials, then push the updated terraform.tfstate file to the repository after every change.
- C
Store the AWS access key and secret key directly in the Terraform configuration files so HCP Terraform can read them during each run.
- D
Use an HCP Terraform workspace only as a state file viewer, but keep plan and apply operations in a CI job that runs terraform apply -auto-approve from arbitrary branches.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use an HCP Terraform workspace with VCS-driven runs and remote execution. This is the standard HCP Terraform workflow for teams that want Terraform changes to be triggered from version control while centralizing plan/apply execution and state management. HCP Terraform workspaces can connect directly to supported VCS providers so code changes trigger runs automatically. Sensitive values such as AWS credentials should not be committed to code; instead, they should be provided securely through workspace variables, variable sets, or supported dynamic provider credential mechanisms. This approach matches HashiCorp guidance around remote operations, secure variable handling, and avoiding local state or hardcoded secrets.
- A. Correct.
Correct. An HCP Terraform workspace can be connected to a VCS repository so runs are automatically triggered by commits or merges, depending on the workflow. Remote execution means plan and apply happen in HCP Terraform rather than on developer machines, which provides consistency, centralized logs, and shared state management. Supplying cloud credentials through workspace variables or, where supported, dynamic provider credentials aligns with best practices because credentials are managed outside the codebase and not stored on laptops.
- B. Incorrect.
Incorrect. This keeps execution decentralized and dependent on each developer's local environment, which is the opposite of the requirement for remote, consistent execution. Committing state files to version control is also a known anti-pattern because state can contain sensitive data and is meant to be managed by a backend such as HCP Terraform, not by manual repository updates.
- C. Incorrect.
Incorrect. Hardcoding AWS credentials in Terraform configuration is insecure and violates the requirement to avoid storing long-lived keys in the repository. HCP Terraform is specifically designed to separate sensitive values from configuration by using workspace variables, variable sets, or supported credential integrations.
- D. Incorrect.
Incorrect. While external CI pipelines can run Terraform, this option does not satisfy the stated goal of using HCP Terraform to execute infrastructure changes remotely and consistently from the VCS-integrated workflow. Treating HCP Terraform only as a state viewer ignores core capabilities such as remote runs, run history, policy checks, approvals, and controlled applies.