HashiCorp Terraform Associate (004) Question 26
Single answer2a Install and version Terraform providersYour team maintains a Terraform configuration that uses the AWS provider. Developers run Terraform locally on different operating systems, and the CI pipeline runs in Linux containers. After a recent provider release introduced breaking behavior, the team wants to ensure everyone installs a compatible AWS provider version consistently while still allowing patch updates. Which change best meets this requirement?
- A
Add a required_providers block with aws = { source = "hashicorp/aws", version = "~> 5.20.0" } and commit the generated .terraform.lock.hcl file to version control.
- B
Run terraform get -update in each environment so Terraform downloads the newest AWS provider available before every plan.
- C
Place the provider binary in the .terraform/providers directory and add that directory to version control so all users share the same compiled plugin.
- D
Set provider "aws" { version = ">= 5.20.0" } and delete the lock file so each platform can resolve the latest compatible provider independently.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use the terraform block with required_providers and a constrained version such as ~> 5.20.0, then commit .terraform.lock.hcl. In Terraform, provider requirements should be declared in required_providers, including the source address and version constraint. The pessimistic constraint ~> 5.20.0 permits patch updates within the 5.20 series while blocking newer minor or major versions. The lock file records the exact selected provider version and checksums, which improves consistency across environments and is especially useful when teams run Terraform on multiple platforms. According to HashiCorp best practices, .terraform.lock.hcl should generally be committed for root modules, while the .terraform directory should not be committed. Provider installation is performed during terraform init, and upgrades should be intentional, typically using terraform init -upgrade when the team decides to move to a newer acceptable provider version.
- A. Correct.
Correct. Defining the provider source and a pessimistic version constraint such as ~> 5.20.0 allows patch releases in the 5.20.x series but prevents upgrades to 5.21 or 6.0, which could introduce behavior changes. Committing .terraform.lock.hcl is a best practice because Terraform records the selected provider version and checksums, helping ensure reproducible provider installation across developer machines and CI on different platforms.
- B. Incorrect.
Incorrect. terraform get is a legacy command for downloading modules and is not the recommended mechanism for controlling provider versions. Provider installation and upgrades are handled through terraform init, and using an update-style workflow in every environment would undermine the goal of consistency by pulling newer versions unexpectedly.
- C. Incorrect.
Incorrect. The .terraform directory is a working directory cache and should not be committed to version control. Provider binaries are platform-specific, so binaries downloaded on one operating system may not work on another. Terraform's lock file and provider installation workflow are designed to handle this more reliably.
- D. Incorrect.
Incorrect. Although a version constraint can be used, placing version inside the provider block is deprecated in favor of required_providers. More importantly, >= 5.20.0 allows Terraform to select any newer version, including minor and major releases, which does not meet the requirement to avoid breaking changes while allowing only patch updates. Deleting the lock file also removes reproducibility.