HashiCorp Terraform Associate (004) Question 30
Single answer2a Install and version Terraform providersA platform team maintains a shared Terraform configuration used by several application teams. The configuration currently works with version 4.x of the HashiCorp AWS provider, but one application team ran terraform init -upgrade locally and their .terraform.lock.hcl now references a newer 5.x provider version. After they commit the lock file change, CI fails because parts of the configuration are not yet compatible with AWS provider 5.x. The team wants to prevent Terraform from selecting provider 5.x while still allowing non-breaking updates within the 4.x series. What is the best change to make in the root module?
- A
Add a
required_providersblock forawswithversion = "~> 4.0", then runterraform initto update the dependency selection accordingly. - B
Add
provider "aws" { version = "4.0.0" }to pin the provider version directly in the provider configuration block. - C
Delete
.terraform.lock.hcland rely on Terraform to automatically keep using the previously installed provider version from.terraform/. - D
Set
required_version = "~> 4.0"in theterraformblock so Terraform itself enforces AWS provider 4.x releases.
Show answer and explanation
Correct answer: A
Explanation
The correct solution is to declare an explicit provider version constraint in the root module's terraform block using required_providers. For example: terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 4.0" } } }. This follows Terraform best practices for provider installation and version management. The pessimistic constraint ~> 4.0 permits upgrades within the 4.x line but blocks 5.x, which is appropriate when a configuration is known to be compatible only with a major provider series. The .terraform.lock.hcl file records the selected provider versions for reproducible installs, but it does not replace the need for explicit constraints. If someone runs terraform init -upgrade, Terraform still resolves versions within the allowed constraints and updates the lock file accordingly. HashiCorp documentation for provider requirements and dependency lock files emphasizes using required_providers for source and version constraints, and using the lock file to capture the exact selections made from those constraints.
- A. Correct.
Correct. Provider version constraints belong in the
terraformblock insiderequired_providers, not in the provider configuration block. Usingversion = "~> 4.0"allows Terraform to install compatible updates in the 4.x series while preventing selection of 5.0 or later. After changing the constraint,terraform initreconciles provider selection and the lock file with the declared requirements. - B. Incorrect.
Incorrect. Older Terraform versions allowed a
versionargument in the provider block, but this approach is deprecated and not the recommended practice for Terraform Associate 004. Current best practice is to specify provider source and version constraints interraform.required_providersso dependency resolution is centralized and explicit. - C. Incorrect.
Incorrect. Deleting the lock file does not solve the version compatibility problem. Terraform would re-resolve provider versions based on the configuration, and without an appropriate version constraint it could still select AWS provider 5.x. The
.terraform/directory is also a local working directory artifact and should not be relied on for deterministic team or CI behavior. - D. Incorrect.
Incorrect.
required_versionconstrains the Terraform CLI version, not provider versions. Settingrequired_version = "~> 4.0"would attempt to restrict the Terraform binary to 4.x versions, which is unrelated to the AWS provider version and would not prevent provider 5.x from being selected.