TF-004 Interact with Terraform modules Practice Question
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.
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 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.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
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.
Why this is correct
This approach directly pins the module source to an immutable Git tag (e.g., "v1.0.0"). By referencing a specific tag, each environment's configuration explicitly declares the exact module version it requires, preventing unintended updates when the main branch or other tags evolve. Updates to the module are then a deliberate action, requiring a change to the `ref` attribute in the configuration, ensuring controlled and predictable deployments across environments. This provides strong version control without external tools.
- ✗
Create separate Git branches for each environment and reference the branch in the module source.
Why it's wrong here
Referencing Git branches (e.g., `ref=dev` or `ref=prod`) in module sources is problematic because branches are inherently mutable pointers. A branch can be updated at any time with new commits, meaning that a `terraform apply` executed against the "prod" branch today might pull different code than one executed tomorrow, even if the configuration itself hasn't changed. This mutability undermines the goal of consistent, reproducible deployments across environments, making it difficult to ensure stability and auditability.
- ✗
Use Terragrunt to manage module dependencies and lock versions.
Why it's wrong here
While Terragrunt can indeed manage module dependencies and enforce version locking, it introduces an additional layer of abstraction and an external dependency to the Terraform workflow. The core problem of ensuring consistent module versions across environments can be effectively addressed using native Terraform features, such as explicit version constraints within the `source` attribute. Opting for Terragrunt here would be an over-engineering solution when simpler, built-in Terraform mechanisms are sufficient and more direct for this specific challenge.
- ✗
Use the Terraform Registry to host modules with semantic versioning and pin versions.
Why it's wrong here
Utilizing the Terraform Registry (public or private) to host modules with semantic versioning is a robust solution for module distribution and version control. However, for an existing setup, this approach typically demands significant initial effort, including setting up the registry, migrating existing modules, establishing publishing pipelines, and updating all configurations to reference the new registry source. While highly effective long-term, it's a more involved and resource-intensive solution than directly pinning Git references for immediate version control.
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 →
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.