HashiCorp Terraform Associate (004) Question 28
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 also runs Terraform in a Linux container. After a recent provider release introduced unexpected behavior, the team decided to standardize provider installation so everyone uses compatible versions and CI uses the exact same provider build recorded by the team. Which action best meets this requirement?
- A
Add a version constraint for the AWS provider in the required_providers block, run terraform init to create/update .terraform.lock.hcl, and commit the lock file to version control.
- B
Set the AWS provider version only inside the provider block and rely on each developer to run terraform init -upgrade when needed.
- C
Commit the .terraform/providers directory to version control so all users and CI reuse the same downloaded plugin binaries.
- D
Use terraform validate in CI to automatically install the latest acceptable AWS provider version for each platform.
Show answer and explanation
Correct answer: A
Explanation
For Terraform Associate 004, candidates should understand both provider version constraints and provider dependency locking. Best practice is to specify providers in the required_providers block within the terraform block, including the provider source address and a version constraint such as ~> 5.0 or >= 5.0, < 6.0 depending on the team's policy. Then run terraform init, which installs the provider and records the exact selected version in .terraform.lock.hcl. Committing that lock file ensures reproducible provider selection in shared workflows and CI/CD. This is especially important when teams work across multiple platforms because Terraform uses checksums in the lock file to verify the provider packages installed on each platform. HashiCorp documentation on provider requirements, dependency lock files, and terraform init supports this workflow. By contrast, committing the .terraform directory is not recommended, and using init -upgrade routinely would undermine deterministic builds.
- A. Correct.
Correct. The recommended approach is to declare provider source and version constraints in the terraform.required_providers block, then run terraform init so Terraform resolves and records the exact provider selections in .terraform.lock.hcl. Committing the lock file allows teams and CI to use consistent provider versions, and the lock file can also include checksums for multiple platforms so provider packages are verified across different operating systems.
- B. Incorrect.
Incorrect. Version constraints belong in the required_providers block, not as the primary mechanism inside the provider configuration block. Also, telling every developer to run terraform init -upgrade defeats the goal of consistency because -upgrade intentionally rechecks for newer allowed versions and can change the selected provider version.
- C. Incorrect.
Incorrect. The .terraform directory is a working directory cache and is not intended to be committed. It is platform-specific, environment-specific, and commonly ignored in version control. The correct artifact to commit for provider consistency is .terraform.lock.hcl, not downloaded plugin binaries under .terraform/providers.
- D. Incorrect.
Incorrect. terraform validate checks whether the configuration is syntactically and internally valid, but it is not the command used to standardize or upgrade provider versions across environments. Provider installation and version selection are handled by terraform init, and locking is handled through the dependency lock file.