Using Version Constraints to Avoid Breaking Changes
You are managing a Terraform configuration that uses a public module from the registry to deploy an AWS VPC. The module is defined with a version constraint of '~> 3.0'. After running 'terraform init', you run 'terraform plan' and notice that the plan output indicates the module will be updated from version 3.18.0 to 3.20.1. However, you are concerned because the module's changelog shows that version 3.19.0 introduced a breaking change: it removed the 'enable_dns_hostnames' variable and replaced it with 'enable_dns_support'. Your configuration currently uses the 'enable_dns_hostnames' variable. You want to avoid any breaking changes in the production environment while still receiving non-breaking updates. What should you do?
Quick Answer
The answer is to change the version constraint to "~> 3.18.0". This is correct because the pessimistic constraint operator (~>) with three segments locks both the major and minor version, restricting updates to only patch releases within the 3.18.x series, such as 3.18.1 or 3.18.2, which will never include the breaking change introduced in version 3.19.0. On the HashiCorp Terraform Associate TF-003 exam, this scenario tests your understanding of how version constraints interact with module updates and breaking changes—a common trap is assuming that "~> 3.0" protects against all breaking changes, when in fact it only locks the major version, allowing minor version bumps that can introduce removals. A reliable memory tip is to remember the "three-segment lock": when you specify three numbers after the tilde-greater-than, you freeze the first two segments, ensuring only safe patch updates pass through.
⚠ Common exam trap
HashiCorp often tests the nuance of the pessimistic version constraint operator (~>) in Terraform, specifically that '~> 3.0' and '~> 3.18.0' have very different behaviors, and candidates mistakenly assume both only allow patch updates.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Change the version constraint to "~> 3.18.0" to stay within the 3.18.x releases.
The version constraint '~> 3.18.0' restricts updates to only patch versions within the 3.18.x series (e.g., 3.18.1, 3.18.2), which will never include the breaking change introduced in 3.19.0. This allows you to receive non-breaking bug fixes and security patches while avoiding the removal of the 'enable_dns_hostnames' variable. The pessimistic version constraint operator (~>) in Terraform locks the major and minor version when specified with three segments, ensuring no unexpected breaking changes from higher minor versions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Fork the module repository and maintain a custom version that retains the 'enable_dns_hostnames' variable.
Why it's wrong here
Forking adds unnecessary maintenance overhead and is not the simplest solution.
- ✗
Change the version constraint to ">= 3.0.0, < 3.19.0" and run 'terraform init -upgrade'.
Why it's wrong here
This constraint would prevent updates beyond 3.18.x but is not a standard constraint; using '~> 3.18.0' is clearer and safer.
- ✓
Change the version constraint to "~> 3.18.0" to stay within the 3.18.x releases.
Why this is correct
This pins to the 3.18.x range, avoiding the breaking change in 3.19.0 while still getting patch updates.
- ✗
Update the configuration to use the new 'enable_dns_support' variable and update the module to version 3.20.1.
Why it's wrong here
This introduces the breaking change immediately, which you want to avoid in production.
Go deeper
Related to this question
About these practice questions
Courseiva writes every TF-004 question from scratch — 428 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on TF-004
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Refer to the exhibit. The configuration fails with an error indicating that the module does not support the 'enable_vpn_gateway' argument. What is the most likely cause?
easy- A.The argument name is misspelled; it should be 'enable_vpn' instead.
- ✓ B.The module version '3.18.0' does not include the 'enable_vpn_gateway' variable; it was added in a later version.
- C.The module does not support VPN gateways at all.
- D.The module source is incorrectly specified; it should use a git URL instead of the registry path.
Why B: The error message indicates that the module does not support the 'enable_vpn_gateway' argument. In Terraform, module arguments are defined by the module's published variables. The module version '3.18.0' predates the introduction of the 'enable_vpn_gateway' variable, which was added in a later version. Upgrading the module version to one that includes this variable resolves the error.
Variation 2. A DevOps team manages Terraform configurations for a multi-environment infrastructure (dev, staging, prod). They maintain a central repository of reusable modules stored in a Git repository. Developers often update modules in the master branch to add features or fix bugs. Recently, after a developer updated the 'vpc' module in the master branch, the staging environment's infrastructure was destroyed and recreated during a terraform apply, causing an outage. The team needs to prevent such unintended changes across environments. They currently reference modules using the source argument with a git URL pointing to the master branch: source = "git::https://github.com/org/terraform-modules//vpc?ref=master". The team is looking for a solution that allows controlled updates and ensures each environment uses a fixed version of a module until explicitly upgraded.
hard- ✓ A.Use module version constraints in the configuration, such as source = "git::https://github.com/org/terraform-modules//vpc?ref=v1.0.0" and update the ref tag when ready.
- B.Create separate Git branches for each environment and reference the branch in the module source.
- C.Use Terragrunt to manage module dependencies and lock versions.
- D.Use the Terraform Registry to host modules with semantic versioning and pin versions.
Why A: Referencing a specific Git tag (e.g., v1.0.0) ensures that each environment uses a fixed version of the module until the tag is explicitly updated. This prevents unintended changes from the master branch affecting environments. Option B is incorrect because separate branches can still receive updates that may cause unintended changes; it does not solve the version pinning problem. Option C is incorrect because Terragrunt is an additional tool that manages dependencies but does not inherently enforce module version pinning without additional configuration, and it adds complexity. Option D is incorrect in this context because the team already uses a Git repository; migrating to the Terraform Registry is not an immediate solution and may not be feasible, whereas using Git tags is a straightforward native approach.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.