HashiCorp Terraform Associate (004) Question 27
Single answer2a Install and version Terraform providersA 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 Linux containers. After a recent terraform init -upgrade, one developer committed updated provider selections, and now the team wants consistent provider installation behavior across environments while still allowing safe patch updates to the AWS provider. Which action is the BEST way to meet this requirement?
- A
Add a
required_providersblock withsource = "hashicorp/aws"andversion = "~> 5.0", then commit the generated.terraform.lock.hclfile to version control. - B
Commit the
.terraform/providersdirectory to version control so every machine uses the exact same downloaded provider binaries. - C
Specify the provider version only inside the
provider "aws"block and rely on each user to runterraform init -upgradewhen needed. - D
Remove all version constraints from the configuration and depend on the newest provider version selected during each
terraform initrun.
Show answer and explanation
Correct answer: A
Explanation
For Terraform Associate-level provider management, the key best practice is to declare providers in the terraform block with required_providers, including both the provider source address and an appropriate version constraint. To balance stability and flexibility, teams commonly use a constraint such as ~> 5.0 for the AWS provider, which permits compatible updates while avoiding unplanned major upgrades. Terraform also generates .terraform.lock.hcl, which records the exact provider versions selected and their checksums. Committing this lock file is the recommended way to keep provider installation consistent across developers, operating systems, and CI systems. By contrast, committing the .terraform directory is not recommended, and omitting version constraints leads to non-deterministic installations. These practices align with Terraform documentation on provider requirements, dependency lock files, and terraform init behavior.
- A. Correct.
Correct. The
required_providersblock is the supported way to declare the provider source address and version constraints. Usingversion = "~> 5.0"allows patch and minor-within-boundary updates according to Terraform's pessimistic constraint semantics for that range, while preventing unintended major-version upgrades. Committing.terraform.lock.hclhelps ensure consistent provider selections across team members and CI, because Terraform records the exact selected provider version and checksums. This is the recommended approach for reproducible provider installation. - B. Incorrect.
Incorrect. The
.terraformdirectory is a working directory artifact and is not intended to be committed to version control. It contains downloaded provider binaries and other local initialization data that can vary by platform and environment. Committing it is not the recommended mechanism for consistency and often causes portability and repository bloat issues. - C. Incorrect.
Incorrect. Provider version constraints should be declared in the
terraformblock usingrequired_providers, not primarily inside theproviderconfiguration block. Theproviderblock is used for provider-specific configuration such as region or credentials. Relying on each user to runterraform init -upgradealso reduces reproducibility and can lead to different selected versions across environments. - D. Incorrect.
Incorrect. Removing version constraints makes provider selection less predictable and increases the risk of breaking changes being introduced unexpectedly, especially across CI and developer workstations. Terraform best practice is to declare explicit provider constraints and use the dependency lock file for deterministic installs.