HashiCorp Terraform Associate (004) Question 151
Single answer5d Manage module versionsYour team uses a shared VPC module from the Terraform Registry in several environments. The current configuration is:
module "network" { source = "acme/network/aws" version = ">= 2.0.0" }
A recent release of the module, version 3.0.0, introduced breaking input variable changes. The production workspace has not run terraform init -upgrade, but a new engineer initializes the configuration on their workstation and Terraform selects version 3.0.0, causing plans to fail. You need to prevent unexpected major-version upgrades while still allowing compatible updates. Which change is the best solution?
- A
Change the version constraint to "~> 2.0" for the module.
- B
Remove the version argument and rely on the .terraform directory to keep the current module version.
- C
Change the version constraint to ">= 2.0.0, >= 3.0.0" so Terraform can choose the safest version.
- D
Keep the current constraint and instruct all engineers to avoid running terraform init -upgrade.
Show answer and explanation
Correct answer: A
Explanation
Terraform Registry modules support version constraints through the version argument in a module block. When you want to allow non-breaking updates but block the next major release, a pessimistic constraint such as "~> 2.0" is appropriate because it permits 2.x releases but excludes 3.0.0 and later. This aligns with semantic versioning expectations and Terraform best practices for predictable dependency management. Relying on local state in the .terraform directory or on team process is fragile and does not provide reproducible behavior across workstations and CI. HashiCorp documentation on module sources and version constraints describes using explicit constraints to control acceptable module versions, especially for shared modules consumed across multiple environments.
- A. Correct.
Correct. Using the pessimistic constraint "~> 2.0" allows Terraform to install versions >= 2.0.0 and < 3.0.0. That permits backward-compatible updates within the 2.x series while preventing an automatic upgrade to 3.0.0, which contains breaking changes. This is a common best practice when consuming registry modules and wanting controlled upgrades.
- B. Incorrect.
Incorrect. Removing the version argument makes module selection less controlled, not more controlled. The .terraform directory is a local working directory artifact and should not be relied on as the mechanism for version governance across engineers or CI systems. Terraform configurations should declare version constraints explicitly so all users resolve acceptable versions consistently.
- C. Incorrect.
Incorrect. The combined constraint ">= 2.0.0, >= 3.0.0" effectively just means ">= 3.0.0" because any version satisfying both must be at least 3.0.0. This would force selection of 3.x versions and would not protect against breaking changes.
- D. Incorrect.
Incorrect. Process guidance alone is not sufficient. Different users, automation pipelines, or fresh working directories can still resolve newer versions allowed by the constraint. The proper way to manage module versions is by setting an appropriate version constraint in configuration, not by depending on everyone to avoid a command.