- A
Fork the module repository and maintain a custom version that retains the 'enable_dns_hostnames' variable.
Why wrong: Forking adds unnecessary maintenance overhead and is not the simplest solution.
- B
Change the version constraint to ">= 3.0.0, < 3.19.0" and run 'terraform init -upgrade'.
Why wrong: This constraint would prevent updates beyond 3.18.x but is not a standard constraint; using '~> 3.18.0' is clearer and safer.
- C
Change the version constraint to "~> 3.18.0" to stay within the 3.18.x releases.
This pins to the 3.18.x range, avoiding the breaking change in 3.19.0 while still getting patch updates.
- D
Update the configuration to use the new 'enable_dns_support' variable and update the module to version 3.20.1.
Why wrong: This introduces the breaking change immediately, which you want to avoid in production.
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.
TF-003 Interact with Terraform modules Practice Question
This TF-003 practice question tests your understanding of interact with terraform modules. This is a configuration task: choose the command set that satisfies every stated requirement. Small differences — like 'secret' vs 'password' or 'transport input ssh' vs 'all' — change whether the answer is correct. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
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?
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.
Option C is correct because 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.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
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.
Related concept
Read the scenario before looking for a memorised answer.
- ✗
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.
Common exam traps
Common exam trap: answer the scenario, not the keyword
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.
Detailed technical explanation
How to think about this question
The pessimistic version constraint operator (~>) in Terraform behaves differently depending on the number of segments: '~> 3.0' allows upgrades to any 3.x version (e.g., 3.19.0), while '~> 3.18.0' only allows patch-level changes within 3.18.x. This is because Terraform interprets the rightmost segment as the minimum version, and only increments beyond it for the next segment. In real-world scenarios, module authors often introduce breaking changes in minor version bumps (per semantic versioning), so pinning to a specific minor version with the pessimistic operator is a common pattern to balance safety and updates.
KKey Concepts to Remember
- Read the scenario before looking for a memorised answer.
- Find the constraint that changes the correct option.
- Eliminate answers that are true in general but not in this case.
TExam Day Tips
- Watch for words such as best, first, most likely and least administrative effort.
- Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A small business has 20 workstations on the 192.168.1.0/24 network and one public IP from its ISP. The router uses PAT (NAT overload) so all 20 devices share one public address using different source ports. NAT questions test whether you understand the four address terms and which direction each translation applies.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
- →
Interact with Terraform modules — study guide chapter
Learn the concepts, then practise the questions
- →
Interact with Terraform modules practice questions
Targeted practice on this topic area only
- →
All TF-003 questions
519 questions across all exam domains
- →
HashiCorp Terraform Associate TF-003 study guide
Full concept coverage aligned to exam objectives
- →
TF-003 practice test guide
How to use practice tests most effectively before exam day
Related practice questions
Related TF-003 practice-question pages
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Understand IaC concepts practice questions
Practise TF-003 questions linked to Understand IaC concepts.
Understand Terraform basics practice questions
Practise TF-003 questions linked to Understand Terraform basics.
Understand Terraform's purpose practice questions
Practise TF-003 questions linked to Understand Terraform's purpose.
Use Terraform outside the core workflow practice questions
Practise TF-003 questions linked to Use Terraform outside the core workflow.
Interact with Terraform modules practice questions
Practise TF-003 questions linked to Interact with Terraform modules.
Use the core Terraform workflow practice questions
Practise TF-003 questions linked to Use the core Terraform workflow.
Implement and maintain state practice questions
Practise TF-003 questions linked to Implement and maintain state.
Read, generate and modify configuration practice questions
Practise TF-003 questions linked to Read, generate and modify configuration.
TF-003 fundamentals practice questions
Practise TF-003 questions linked to TF-003 fundamentals.
TF-003 scenario practice questions
Practise TF-003 questions linked to TF-003 scenario.
TF-003 troubleshooting practice questions
Practise TF-003 questions linked to TF-003 troubleshooting.
Practice this exam
Start a free TF-003 practice session
Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.
FAQ
Questions learners often ask
What does this TF-003 question test?
Interact with Terraform modules — This question tests Interact with Terraform modules — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: Change the version constraint to "~> 3.18.0" to stay within the 3.18.x releases. — Option C is correct because 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.
What should I do if I get this TF-003 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on TF-003
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: Option B is correct because 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: Option D is correct because pinning to a specific Git tag ensures that each environment uses a known, fixed version of the module until the tag is updated. Option A is incorrect because using separate branches still exposes environments to changes in those branches. Option B is incorrect because setting up a registry is a larger undertaking and not an immediate fix. Option C is incorrect because Terragrunt is an external tool that adds complexity without directly solving the version pinning issue in a native Terraform way.
Last reviewed: Jun 30, 2026
This TF-003 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-003 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.