HashiCorp Terraform Associate (004) Question 153
Single answer5d Manage module versionsYour team uses a shared VPC module from the public Terraform Registry in several environments. The current configuration is:
module "network" { source = "hashicorp/consul/aws" version = ">= 0.9.0" }
A recent module release introduced a breaking input change, and your production pipeline picked it up during a fresh initialization on a new runner. You want to reduce the risk of unexpected module upgrades while still allowing non-breaking updates within the same major version. Which change is the best choice?
- A
Change the version constraint to "~> 0.9.0"
- B
Remove the version argument and rely on the .terraform.lock.hcl file to pin the module version
- C
Change the version constraint to ">= 0.9.0, < 1.0.0"
- D
Change the module source to a Git URL and use ref=main so the latest compatible code is always used
Show answer and explanation
Correct answer: A
Explanation
To manage module versions safely, Terraform best practice is to use explicit version constraints for Registry modules. A broad constraint such as ">= 0.9.0" can allow Terraform to install newer releases during init, including versions with breaking changes. The pessimistic operator is often the best fit when a team wants controlled updates. In this case, "~> 0.9.0" means allow versions greater than or equal to 0.9.0 but less than 0.10.0.
This matters especially for pre-1.0 modules, where even minor version increases may contain breaking changes. A constraint like ">= 0.9.0, < 1.0.0" may look safe but is still too permissive for 0.x modules. Also, unlike providers, module version control is not something you should expect .terraform.lock.hcl to manage for Registry modules. HashiCorp documentation on module sources and version constraints emphasizes specifying module versions directly in configuration and using appropriate version constraint syntax to control upgrade behavior.
- A. Correct.
Correct. The pessimistic constraint "~> 0.9.0" allows updates that are compatible with 0.9.x while preventing upgrades to 0.10.0 or later. This is the safest option here because the team wants to permit non-breaking updates only within the current minor release line and avoid unexpected changes on fresh initialization. This is a common best practice for controlling module versions more tightly than a broad lower-bound constraint.
- B. Incorrect.
Incorrect. The dependency lock file primarily records provider selections, not module versions in the way many users assume. Module version selection should be controlled explicitly with the module version argument for Registry modules. Removing the version argument would make version selection less predictable, not more controlled.
- C. Incorrect.
Incorrect. This constraint prevents upgrades to 1.0.0 and later, but it still allows upgrades to 0.10.0, 0.11.0, and other later 0.x releases. In semantic versioning, 0.x releases can include breaking changes between minor versions, so this range is still too broad for the stated goal of limiting upgrades to non-breaking changes.
- D. Incorrect.
Incorrect. Pointing a module source at a Git branch such as ref=main makes the version less predictable because the referenced code can change over time. This increases the risk of unexpected updates rather than reducing it. If Git is used as a module source, immutable tags or commit SHAs are the safer approach.