TF-004 Read, generate and modify configuration Practice Question
A team is writing Terraform configurations for a multi-region deployment. They want to use a module from the public Terraform Registry that provisions AWS VPCs. The module has been updated recently, but the team wants to ensure that all deployments use the same version of the module to avoid unexpected changes. Which configuration approach should they take to lock the module version?
⚠ Common exam trap
HashiCorp often tests the distinction between module version pinning (using 'version' in the module block) and provider version pinning (using 'required_providers' and the lock file), leading candidates to confuse 'terraform lock' or 'required_version' as valid mechanisms for locking module versions.
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 the 'version' argument in the module block to specify the exact version.
The 'version' argument in a module block is the standard Terraform mechanism for pinning a module from the Terraform Registry to a specific semantic version. This ensures that all deployments use the exact same module version, preventing unexpected changes from newer releases. The version constraint is evaluated against the registry's metadata and enforces the specified version during 'terraform init'.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run 'terraform lock' on the module to record its version in the dependency lock file.
Why it's wrong here
Running 'terraform lock' is specifically designed to manage and record the versions of *providers* used in a Terraform configuration within the `.terraform.lock.hcl` file. This mechanism ensures consistent provider behavior across different execution environments. It does not, however, manage or record the versions of external modules; module versioning is handled directly within the configuration's module blocks.
- ✓
Use the 'version' argument in the module block to specify the exact version.
Why this is correct
Using the 'version' argument within a module block is the standard and recommended method for specifying and pinning the exact version of a module, especially when sourcing from the Terraform Registry. This ensures that Terraform downloads and utilizes only the specified module version, providing crucial predictability and preventing unintended changes or breaking updates from newer module releases. This explicit version constraint is vital for maintaining configuration stability and reproducibility.
- ✗
Reference the module source with a git URL and tag, such as 'git::https://github.com/...?ref=v1.0'.
Why it's wrong here
While referencing a module source with a Git URL and a specific tag (e.g., `git::https://github.com/...?ref=v1.0`) is a technically viable method to pin a module to a particular version, especially for private repositories or specific development branches, it is not the conventional approach for modules published on the public Terraform Registry. This method bypasses the registry's native versioning system, which the `version` argument is designed to leverage for cleaner syntax and integrated resolution.
- ✗
Set the 'required_version' argument in the root module to match the module's version.
Why it's wrong here
The 'required_version' argument, typically declared within the `terraform` block of a configuration, serves to specify the compatible version range for the *Terraform CLI itself*. Its purpose is to ensure that the configuration is executed using a Terraform binary that meets specific version requirements, preventing issues from API incompatibilities or deprecated features. This argument has no direct control over, nor does it specify, the versions of any external modules being consumed by the configuration.
Go deeper
Related to this question
About these practice questions
This TF-004 question is part of Courseiva's 428-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.