HashiCorp Terraform Associate (004) Question 29
Single answer2a Install and version Terraform providersYour team maintains a Terraform configuration that uses the HashiCorp AWS provider. Developers run Terraform locally on different operating systems, and the CI pipeline also runs Terraform in a Linux container. After a recent release of the AWS provider, one developer upgraded locally and committed changes that caused CI to install a different provider build than expected. The team wants reproducible provider installation across environments while still allowing safe patch updates within a defined major version. Which action is the BEST way to meet this requirement?
- A
Add a required_providers block with source = "hashicorp/aws" and version = "~> 5.0", then commit the .terraform.lock.hcl file to version control
- B
Run terraform init -upgrade in every environment and do not use a lock file, because the version constraint alone guarantees identical provider selections
- C
Pin the provider version exactly in the provider block, for example version = "5.0.0", and delete .terraform.lock.hcl so each platform can resolve its own build
- D
Set TF_PLUGIN_CACHE_DIR in each environment and rely on the shared cache to ensure all users and CI install the same provider version
Show answer and explanation
Correct answer: A
Explanation
The best practice for reproducible provider installation is to declare provider requirements in the terraform block using required_providers and to commit the generated .terraform.lock.hcl file. The version constraint defines what versions are acceptable, while the lock file records the exact provider version selected and its checksums so subsequent terraform init runs reuse that version unless intentionally upgraded. This is especially important when multiple developers and CI systems run Terraform on different platforms. HashiCorp documentation recommends using dependency lock files to ensure consistent provider selections and using terraform init -upgrade only when you intentionally want to update locked dependencies.
- A. Correct.
Correct. Defining the provider source and a version constraint in the required_providers block is the recommended way to declare provider requirements. Using ~> 5.0 allows updates within the 5.x series, depending on the constraint semantics, while the dependency lock file records the exact selected provider version and checksums. Committing .terraform.lock.hcl helps keep provider selections reproducible across machines and CI runs. This matches Terraform best practices for provider installation and version control.
- B. Incorrect.
Incorrect. terraform init -upgrade explicitly tells Terraform to ignore existing selections and seek newer acceptable versions, which reduces reproducibility. A version constraint alone does not guarantee that every environment will choose the exact same provider version over time, because multiple versions may satisfy the constraint. The lock file is what records the exact selected version.
- C. Incorrect.
Incorrect. Provider version constraints belong in the required_providers block, not in the provider block for modern Terraform usage. Also, deleting .terraform.lock.hcl removes the mechanism Terraform uses to record and verify the exact provider version and checksums. Exact pinning can be overly restrictive if the team wants controlled patch or minor updates, and removing the lock file works against reproducibility.
- D. Incorrect.
Incorrect. A plugin cache can improve performance by reusing already downloaded provider plugins, but it is not the primary mechanism for dependency selection consistency. Different environments can still resolve different acceptable versions without a committed lock file. Cache contents are an optimization, not a substitute for version constraints and dependency locking.