Terraform Module Sources and Version Constraints
A large organization uses Terraform to manage infrastructure across multiple AWS accounts. They have a shared module for VPC stored in a private Git repository (git::https://github.com/org/terraform-aws-vpc.git?ref=v1.0.0). After updating the module source to ref=v1.2.0, they run terraform init and then terraform plan. The plan still shows the old module's resources and behavior. They confirm the new tag exists and the module code has changed. The root module source line is correct. What is the most likely cause?
Quick Answer
The answer is that Terraform cached the previous module version and did not download the new one. This occurs because Terraform stores downloaded modules in the `.terraform` directory, and after changing the module source or version constraint—such as updating the `ref` parameter in a Git source URL—you must run `terraform init` with the `-upgrade` flag to force Terraform to re-fetch the module. Without that flag, Terraform reuses the cached copy, causing the plan to reflect the old module’s resources even when the remote repository contains the new tag. On the HashiCorp Terraform Associate TF-003 exam, this tests your understanding of module sources and version constraints, specifically how Terraform’s caching behavior can lead to stale state if you forget to upgrade. A common trap is assuming `terraform init` alone always downloads the latest version; in reality, it only downloads missing modules. Memory tip: think “init upgrades, not just init”—always add `-upgrade` when you change a version constraint or source reference.
⚠ Common exam trap
Terraform caches modules in the `.terraform/modules` directory after `terraform init`. Running `terraform init` without the `-upgrade` flag will not re-download the module even if the source version has changed. You must use `terraform init -upgrade` to force a fresh download and update the lock file.
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
✓
Terraform cached the previous module version and did not download the new one.
Terraform caches modules in the `.terraform/modules` directory after `terraform init`. When the module source version is updated (e.g., from `ref=v1.0.0` to `ref=v1.2.0`), Terraform does not automatically re-download the module unless the lock file changes or `terraform init -upgrade` is used. Running `terraform init` without the `-upgrade` flag will not overwrite the cached module, so the plan still reflects the old version's resources and behavior.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
They forgot to run terraform get.
Why it's wrong here
terraform get is an older command, but terraform init handles module downloads.
- ✗
The module source URL is incorrect.
Why it's wrong here
An incorrect URL would produce an error during terraform init, not a silent use of old cached code.
- ✓
Terraform cached the previous module version and did not download the new one.
Why this is correct
Terraform caches modules; running terraform init with -upgrade or clearing the .terraform directory forces a fresh download.
- ✗
The module's outputs changed and they need to update the root module.
Why it's wrong here
Changes to outputs would affect the plan only after the new module code is loaded; they would not cause the old behavior to persist.
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
4 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. Which TWO statements about Terraform module sources are correct? (Select TWO.)
medium- ✓ A.A module source can be a local file system path.
- B.Modules can only be sourced from the public Terraform Registry.
- C.Running 'terraform plan' automatically downloads any missing modules.
- ✓ D.A module source can be a Git repository URL using the SSH protocol.
- E.The module source is defined in a separate 'source' block within the module.
Why A: Terraform supports various module sources. Option A is correct because a module source can indeed be a local file system path, allowing for development and testing of modules on your local machine using relative or absolute paths (e.g., `./modules/my-module`). Option D is also correct as Terraform can source modules directly from Git repositories, including those accessed via SSH protocol (e.g., `git::ssh://git@github.com/user/repo.git//path/to/module`). Other supported sources include HTTP/HTTPS URLs, S3 buckets, GCS buckets, and the Terraform Registry (public or private).
Variation 2. The above configuration references a module from the Terraform Registry. After running 'terraform init', the user runs 'terraform plan' and gets an error: 'Error: Unsupported argument' for 'version'. What is the most likely cause?
medium- ✓ A.The 'version' argument is not supported for this module because the source is not a registry module.
- B.The 'version' argument must be specified as a constraint like '>= 3.19.0' instead of an exact version.
- C.The module source is from a Git repository, which does not support the 'version' argument.
- D.The 'version' argument should be placed inside a 'required_providers' block.
Why A: The error 'Unsupported argument' for 'version' is a definitive indicator that Terraform does not recognize the module source as a registry module. The 'version' argument is exclusively supported for modules sourced from the Terraform Registry. Therefore, despite the STEM's initial statement, the error implies that the module source is not being treated as a registry module. Option A correctly identifies this core reason. Option C is a specific instance of a non-registry module, but the error itself points to the broader category. Options B and D describe valid syntax or constraints for supported scenarios, which is not the case here.
Variation 3. After adding a new module sourced from a Git repository with a specific tag, terraform init reports that the module is being downloaded. What is the best practice to ensure the team uses the same version of this module consistently?
easy- A.Use a version constraint in the module block, e.g., version = 1.0.0.
- B.Specify the source as the branch name 'main'.
- C.Use the 'latest' tag in the source URL.
- ✓ D.Use a Git tag, like '?ref=v1.0.0', to pin the version.
Why D: Using a Git tag (e.g., `?ref=v1.0.0`) in the module source URL pins the module to a specific, immutable commit. This ensures that every team member downloads the exact same version of the module, regardless of future changes to the default branch. Terraform resolves the tag to a commit hash and caches it, providing deterministic and reproducible infrastructure.
Variation 4. Based on the error, what is the most likely reason the 'acl' argument is not expected?
easy- ✓ A.The module version currently installed does not have an 'acl' variable.
- B.The argument name is misspelled; it should be 'acl_control'.
- C.The module requires the 'acl' to be set inside a separate block.
- D.The 'bucket' argument is missing; 'acl' must follow it.
Why A: The error indicates that the 'acl' argument is not recognized by the Terraform module. This typically occurs when the installed module version does not expose an 'acl' variable in its schema. Terraform validates arguments against the module's declared variables; if 'acl' is absent from the module's variables.tf, Terraform will reject it as an unexpected argument.
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.