Terraform Registry Module Source and Version Constraints
Which TWO options are valid ways to reference a Terraform module from a registry?
Quick Answer
The correct answer is that `source = "hashicorp/consul/aws"` and `version = "~> 0.1"` are the two valid ways to specify a Terraform module source from a registry and apply a version constraint. The source syntax must follow the strict three-part format of `namespace/name/provider`, where `hashicorp/consul/aws` correctly points to the public Terraform Registry, and the `~>` operator defines a pessimistic version constraint that allows only patch-level updates within the specified minor version. On the HashiCorp Terraform Associate TF-003 exam, this question tests your understanding of module sourcing fundamentals and version constraint syntax, often appearing as a multiple-select trap where candidates confuse Git URLs or local paths with registry references. A common mistake is forgetting that the registry source requires exactly three segments separated by slashes, or misapplying version constraints like `>= 1.0` when the `~>` operator is the standard for compatible updates. Remember the memory tip: “Three slashes for the registry, tilde-greater for safety.”
⚠ Common exam trap
HashiCorp often tests the distinction between registry module syntax and Git-based module references, so the trap here is that candidates mistakenly apply Git-style `?ref=` syntax to registry modules, not realizing that registry modules require the `version` argument instead.
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
✓
source = "hashicorp/consul/aws"
The Terraform registry module source syntax requires the format `namespace/name/provider`, and `hashicorp/consul/aws` follows this exactly. This tells Terraform to fetch the module from the public registry, using the `hashicorp` namespace, the `consul` module name, and the `aws` provider. The `version` constraint in option C is also valid, as it pins the module to a compatible version range using the `~>` operator, which is a standard Terraform version constraint syntax.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
source = "hashicorp/consul/aws"
Why this is correct
Correct; omitting the version defaults to the latest.
- ✗
source = "consul/aws"
Why it's wrong here
Registry modules require the full three-part address including namespace.
- ✓
source = "hashicorp/consul/aws" version = "~> 0.1"
Why this is correct
Correct; specifying a version constraint is valid for registry modules.
- ✗
from = "hashicorp/consul/aws"
Why it's wrong here
The argument is 'source' not 'from'.
- ✗
source = "hashicorp/consul/aws?ref=v1.0.0"
Why it's wrong here
The 'ref' parameter is used for Git sources, not registry modules.
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 →
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. A team is using a module from the public Terraform Registry. They want to ensure that the module is pinned to a specific version to avoid unexpected changes. Which approach should they use?
easy- A.Use 'required_providers' block in the root module to lock the module version.
- B.Add a 'version' argument inside the module block.
- ✓ C.Set 'version' in the module's source attribute, e.g., source = "terraform-aws-modules/vpc/aws" with version = "3.2.0".
- D.Store the module locally in a vendor directory and reference it by path.
Why C: It correctly demonstrates the Terraform syntax for pinning a module from the public registry: the `version` argument is a separate attribute within the module block, not embedded in the source string. Option B is ambiguous; while adding a `version` argument inside the module block is the right idea, the phrasing could be misinterpreted as placing the version inside the source attribute. The official Terraform documentation requires the version to be a standalone argument as shown in Option C. Option A is incorrect because `required_providers` locks provider versions, not module versions. Option D is a valid approach but is not the standard practice for registry modules.
Variation 2. A team is using a module from the Terraform Registry. They want to ensure that changes to the module's source version are tested in a non-production environment before being applied to production. Which approach best supports this workflow?
medium- A.Fork the module repository and manage the module internally as a private module.
- B.Pin the module to an exact version (e.g., version = "1.2.3") and update it manually after testing in isolation.
- C.Configure the module source to reference the latest commit from the default branch of the repository.
- ✓ D.Use a version constraint like ~> 1.0 in the module configuration and test the module in a non-production workspace before promoting to production.
Why D: Using a version constraint like `~> 1.0` allows Terraform to automatically select the latest compatible patch version within the specified minor version range. This enables safe, incremental updates that can be tested in a non-production workspace first, and then promoted to production by simply applying the same configuration. The constraint ensures that breaking changes (major version bumps) are not automatically pulled in, giving the team control over when to adopt them.
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.