- A
Publish the module to the public Terraform Registry and use a version constraint in each root module.
Why wrong: The module is private; publishing to a public registry is not appropriate and doesn't address consistency.
- B
Pin each root module to a specific Git tag (e.g., ref=v1.2.3) and manually update each root module when a new tag is created.
Why wrong: This is the current workflow and still requires manual updates per root module, leading to drift.
- C
Remove the version constraint from the module source so that Terraform always fetches the latest commit from the default branch.
Why wrong: This would cause all environments to automatically get the latest changes, risking unintended breaking changes.
- D
Use a version constraint like "~> 1.2" in the module source and adopt a workflow to update the constraint across all root modules simultaneously only when ready.
This allows controlled updates: patch updates are automatic, but major/minor updates require explicit version constraint changes across all environments.
Quick Answer
The answer is to use a version constraint like `~> 1.2` in the module source and adopt a coordinated workflow to update the constraint across all root modules simultaneously. This approach is correct because the pessimistic version constraint operator (`~>`) allows only the rightmost version component to increment—so `~> 1.2` permits patch-level updates (e.g., 1.2.0 to 1.2.5) but blocks minor or major breaking changes, ensuring all environments stay on a compatible, consistent release while still receiving safe fixes. On the HashiCorp Terraform Associate TF-003 exam, this question tests your understanding of version constraints as a mechanism for managing shared modules across multiple root configurations, a common scenario in multi-environment setups. A frequent trap is choosing a fixed version like `= 1.2.0`, which prevents drift but also blocks all upgrades, or relying on manual source URL updates, which causes the drift described. Memory tip: think of the tilde as a “gentle tether”—it lets the module stretch to the next patch but snaps back before a breaking change.
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.
Your company manages infrastructure for multiple environments (dev, staging, prod) using Terraform. You have a shared networking module stored in a private Git repository. The module is used by several root configurations. The current workflow requires developers to manually update the module version in each root module's source attribute when a new version is tagged. This has led to configuration drift and occasional use of incompatible module versions. You want to implement a more reliable approach that ensures all environments use the same consistent version of the module, while still allowing controlled upgrades. Which approach best addresses this concern?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue:
"best"Why it matters: Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.
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
Use a version constraint like "~> 1.2" in the module source and adopt a workflow to update the constraint across all root modules simultaneously only when ready.
Option D is correct because it uses a version constraint (e.g., `~> 1.2`) to allow automatic patch-level updates while preventing major or minor breaking changes, and it enforces a coordinated workflow where all root modules update the constraint simultaneously. This eliminates configuration drift and ensures consistent module versions across environments, while still enabling controlled upgrades. The approach leverages Terraform's built-in version constraint syntax to balance consistency with flexibility.
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.
- ✗
Publish the module to the public Terraform Registry and use a version constraint in each root module.
Why it's wrong here
The module is private; publishing to a public registry is not appropriate and doesn't address consistency.
- ✗
Pin each root module to a specific Git tag (e.g., ref=v1.2.3) and manually update each root module when a new tag is created.
Why it's wrong here
This is the current workflow and still requires manual updates per root module, leading to drift.
- ✗
Remove the version constraint from the module source so that Terraform always fetches the latest commit from the default branch.
Why it's wrong here
This would cause all environments to automatically get the latest changes, risking unintended breaking changes.
- ✓
Use a version constraint like "~> 1.2" in the module source and adopt a workflow to update the constraint across all root modules simultaneously only when ready.
Why this is correct
This allows controlled updates: patch updates are automatic, but major/minor updates require explicit version constraint changes across all environments.
Clue confirmation
The clue word "best" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
Common exam traps
Common exam trap: answer the scenario, not the keyword
HashiCorp often tests the misconception that removing version constraints or using the latest commit is a valid way to ensure consistency, but the trap here is that this actually introduces unpredictability and breaks controlled upgrades, which is the opposite of what the scenario requires.
Detailed technical explanation
How to think about this question
Terraform's version constraint syntax (e.g., `~> 1.2`) uses semantic versioning to restrict updates to only the rightmost non-zero component, so `~> 1.2` allows versions from 1.2.0 up to but not including 2.0.0. Under the hood, Terraform resolves module sources by fetching the specified Git tag or commit, and the version constraint is evaluated during `terraform init` to select a compatible version from the registry or Git tags. In a real-world scenario, using a shared module registry (private or public) with version constraints ensures that all root modules pull the same module version, and a coordinated update workflow (e.g., via CI/CD pipeline or pull request) prevents drift.
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: Use a version constraint like "~> 1.2" in the module source and adopt a workflow to update the constraint across all root modules simultaneously only when ready. — Option D is correct because it uses a version constraint (e.g., `~> 1.2`) to allow automatic patch-level updates while preventing major or minor breaking changes, and it enforces a coordinated workflow where all root modules update the constraint simultaneously. This eliminates configuration drift and ensures consistent module versions across environments, while still enabling controlled upgrades. The approach leverages Terraform's built-in version constraint syntax to balance consistency with flexibility.
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.
Are there clue words in this question I should notice?
Yes — watch for: "best". Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.
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. A module block references a module with version constraint '>= 2.0, < 3.0'. An older version 1.5 is already cached from a previous init. The team wants to ensure they use a newer version. After running terraform init -upgrade, what happens?
hard- A.Terraform upgrades to version 3.0 because it is the latest.
- B.Terraform returns an error because version 1.5 is incompatible with the constraint.
- C.Terraform uses the cached version 1.5 because it is already present.
- ✓ D.Terraform upgrades to the latest version in the range 2.x that is not yet cached.
Why D: Option B is correct because terraform init -upgrade re-checks the source and uses the latest version matching the constraint. Option A is wrong because it ignores the cache if -upgrade is used. Option C is wrong because it will upgrade within constraint. Option D is wrong because no error occurs.
Variation 2. A company uses a Terraform module from the registry for AWS VPC (source = "terraform-aws-modules/vpc/aws", version = "3.0.0"). They updated the module version to "3.1.0" and ran terraform plan. To their surprise, the plan shows that all VPC resources will be replaced (destroyed and recreated) instead of updated in place. They did not change any input variables. The module's release notes mention only bug fixes and minor improvements. What is most likely causing the full resource replacement?
easy- A.The module's new version introduced a new required variable.
- B.The module's new version changed the default CIDR block.
- C.The module's new version uses a different provider version.
- ✓ D.The module's new version changed the resource names or identifiers.
Why D: Option A is most likely because the newer version might have changed resource names (e.g., from aws_vpc.main to aws_vpc.this), causing Terraform to see old resources as removed and new ones to create. Option B would only cause replacement if they changed the CIDR variable, which they did not. Option C (provider version) usually does not force replacement unless there are incompatible schema changes. Option D (new required variable) would cause an error, not a plan showing changes.
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.