HashiCorp Terraform Associate (004) Question 155
Single answer5d Manage module versionsYour team uses a shared VPC module from the public Terraform Registry in several environments. The production configuration currently includes:
module "network" { source = "acme/network/aws" version = "~> 2.3.0" }
A new module release, 2.4.0, introduces a breaking input variable change that production is not ready to adopt. You need to allow patch updates within the 2.3 series, prevent upgrades to 2.4.0 or later, and ensure Terraform uses the newest allowed version after you update dependencies. Which action should you take?
- A
Keep version = "~> 2.3.0" and run terraform init -upgrade
- B
Change to version = ">= 2.3.0" and run terraform get -update
- C
Change to version = "~> 2.4" and run terraform init
- D
Remove the version argument and rely on .terraform.lock.hcl to prevent upgrades
Show answer and explanation
Correct answer: A
Explanation
To manage module versions safely, use an explicit version constraint in the module block and update dependencies with terraform init -upgrade when you want Terraform to check for newer allowed versions. The constraint ~> 2.3.0 is the correct choice here because it means >= 2.3.0 and < 2.4.0. This is a common best practice for consuming shared modules in production: permit non-breaking patch releases while blocking minor or major upgrades until they are tested.
Terraform version constraints for modules are defined with the version argument in a module block when the module source supports versioning, such as the Terraform Registry. The init -upgrade flag causes Terraform to select the newest version matching the configured constraint instead of reusing an already-installed dependency. This aligns with HashiCorp guidance on dependency version constraints and dependency installation behavior.
- A. Correct.
Correct. The pessimistic constraint ~> 2.3.0 allows versions greater than or equal to 2.3.0 but less than 2.4.0, which permits patch releases such as 2.3.1 or 2.3.5 while blocking 2.4.0 and later. Running terraform init -upgrade tells Terraform to ignore the previously selected version and query for the newest available version that still satisfies the constraint. This is the appropriate workflow for managing module versions safely.
- B. Incorrect.
Incorrect. The constraint >= 2.3.0 would also allow 2.4.0, 3.0.0, and any later version unless restricted by another upper bound, so it does not protect production from the breaking 2.4.0 release. Also, terraform get -update is from older workflows and is not the standard command expected for current Terraform dependency upgrades; terraform init -upgrade is the relevant command.
- C. Incorrect.
Incorrect. The constraint ~> 2.4 allows versions in the 2.4 series, which explicitly includes the breaking 2.4.0 release that the scenario says production must avoid. Running terraform init without -upgrade may also continue using a previously installed version rather than selecting the newest acceptable one.
- D. Incorrect.
Incorrect. Omitting the version constraint is not a best practice for shared modules because it allows Terraform to select any available version from the source. While .terraform.lock.hcl helps record selected provider versions, candidates should know that version constraints are how you intentionally control module version selection in configuration. Relying solely on removing the version argument would not meet the stated requirement to allow only 2.3 patch updates.