HashiCorp Terraform Associate (004) Question 154
Single answer5d Manage module versionsYour team uses a shared VPC module from the public Terraform Registry in several environments. In production, the root module currently declares:
module "network" { source = "acme/network/aws" version = "~> 2.4.0" }
A newer module release, 2.5.0, was published yesterday, but your team does not want production to adopt new minor releases automatically. During a maintenance window, an engineer runs terraform init in the production workspace. Which outcome should the engineer expect, and what is the best explanation?
- A
Terraform will install the latest available 2.x version, including 2.5.0, because
~> 2.4.0allows all non-breaking updates within major version 2. - B
Terraform will keep using a 2.4.x version and will not select 2.5.0, because
~> 2.4.0permits patch-level updates only within the 2.4 series. - C
Terraform will fail during
terraform initbecause module versions must be pinned to an exact version such as2.4.3for Registry modules. - D
Terraform will automatically upgrade to 2.5.0 only if the engineer also runs
terraform plan, because module version selection happens during planning rather than initialization.
Show answer and explanation
Correct answer: B
Explanation
This question tests practical use of module version constraints for Terraform Registry modules. In Terraform, the version argument on a module block is supported for Registry-sourced modules and is used by terraform init when selecting and downloading the module. The pessimistic constraint ~> 2.4.0 means >= 2.4.0, < 2.5.0, so production remains on the 2.4 patch line and does not automatically adopt 2.5.0. If the team wanted to allow any 2.x minor or patch release, they could use a broader constraint such as ~> 2.4 or another appropriate range, but that would not meet the stated change-control requirement. This aligns with Terraform version constraint semantics and common best practices for managing module versions predictably across environments.
- A. Incorrect.
Incorrect. This reflects a common misunderstanding of the pessimistic constraint operator.
~> 2.4.0does not allow any version in the entire 2.x range. It allows versions greater than or equal to 2.4.0 but less than 2.5.0, which means only patch releases in the 2.4 series are eligible. - B. Correct.
Correct. For module versions from the Terraform Registry,
version = "~> 2.4.0"constrains selection to>= 2.4.0and< 2.5.0. That meansterraform initcan install a newer patch release such as 2.4.1 or 2.4.9 if available, but it will not move to 2.5.0. This is a common best practice when teams want controlled updates without automatically adopting new minor releases. - C. Incorrect.
Incorrect. Registry modules do not have to be pinned to an exact version. Terraform supports version constraints for Registry modules, including exact versions (
= 2.4.3) and ranged constraints such as~> 2.4.0. Exact pinning may be used for stricter reproducibility, but it is not required. - D. Incorrect.
Incorrect. Module package selection and installation occur during
terraform init, not duringterraform plan.planevaluates configuration and proposed changes after initialization has resolved providers and downloaded child modules. Runningplandoes not change the allowed version range for the module.