HashiCorp Terraform Associate (004) Question 152
Single answer5d Manage module versionsYour team uses a shared VPC module from the public Terraform Registry. The root module currently references it as source = "hashicorp/consul/aws" with no version specified. After a new release of the module introduced breaking input changes, a CI pipeline failed during terraform init and terraform plan. You want to prevent unexpected module upgrades in future runs while still allowing controlled adoption of compatible updates. Which change is the best way to manage this module version?
- A
Add
version = "~> 1.0"inside the module block and review/update the constraint intentionally when you are ready to adopt newer compatible releases. - B
Add
required_version = "~> 1.0"to the root module so Terraform locks the module to the 1.0 release series. - C
Run
terraform fmtafter each release so the module source is normalized and Terraform will not download incompatible module versions. - D
Replace the Registry source with a local path such as
source = "./modules/consul"so Terraform automatically freezes the module at the current downloaded copy.
Show answer and explanation
Correct answer: A
Explanation
To manage module versions safely, specify a version constraint directly in the module block when the source is a Terraform Registry module. Without a version, Terraform may select the newest available release during initialization, which can introduce breaking changes unexpectedly. A constraint like ~> 1.0 is a practical choice when you want to accept backward-compatible updates but avoid major-version upgrades until you explicitly review and change the constraint. This aligns with Terraform module source and version best practices documented by HashiCorp: Registry modules support the version argument, while required_version applies only to the Terraform CLI. In real environments, teams typically combine explicit module version constraints with code review and testing before changing those constraints.
- A. Correct.
Correct. For Terraform Registry modules, the supported way to control module upgrades is to set the
versionargument in themoduleblock. Using a pessimistic constraint such as~> 1.0allows compatible updates within the 1.x line while preventing automatic adoption of newer major versions that may contain breaking changes. This is the recommended practice for managing shared module versions predictably. - B. Incorrect.
Incorrect.
required_versioncontrols the Terraform CLI version, not module versions. A common misconception is that it applies to providers or modules, but module version constraints are managed separately with theversionargument in themoduleblock. - C. Incorrect.
Incorrect.
terraform fmtonly reformats configuration files. It has no effect on dependency resolution, module downloads, or version selection. Someone might choose this if they confuse formatting and initialization workflows, but it does not solve upgrade control. - D. Incorrect.
Incorrect. Switching to a local path does not automatically pin the module to a managed version in a safe or maintainable way. It changes the source type entirely and usually implies manually vendoring code, which can create drift and bypass normal Registry versioning practices. Terraform does not treat a local path as a versioned Registry dependency.