HashiCorp Terraform Associate (004) Question 134
Single answer5 Terraform modulesYour team maintains a reusable Terraform module named network that provisions a VPC and subnets. Several application teams consume it from a shared Git repository. A recent module update added new tagging logic and an optional variable for flow logs, but one application team reports that running terraform apply in their root module still uses the old behavior even though the latest code is in the repository. Their root configuration references the module like this:
module "network" { source = "git::https://example.com/infra-modules.git//network" }
What is the best action to ensure the root module downloads and uses the latest version of the remote module source?
- A
Run
terraform get -updateorterraform init -upgradein the root module directory to refresh the downloaded module code - B
Run
terraform refreshso Terraform reloads the module source from Git before planning - C
Delete the
.tfstatefile and rerunterraform planso Terraform detects the module code has changed - D
Add
version = "latest"inside the module block so Terraform automatically pulls the newest Git commit
Show answer and explanation
Correct answer: A
Explanation
Terraform modules are packages of configuration that can be reused from local paths, the Terraform Registry, or remote sources such as Git. When a root module references a remote child module, Terraform downloads it into the .terraform directory during initialization. If the remote source changes later, Terraform does not automatically replace the cached module code during a normal plan or apply. The correct operational response is to reinitialize and upgrade modules with terraform init -upgrade (or terraform get -update in older workflows).
This scenario tests practical module usage: understanding how Terraform installs child modules, how module source caching works, and the difference between module source management and state management. It also checks a common exam objective distinction: the version argument applies to Registry modules, while Git sources are controlled via the source address, commonly with ?ref= for reproducible version pinning. HashiCorp documentation on module sources and terraform init behavior supports this best practice.
- A. Correct.
Correct. Terraform caches downloaded child modules in the working directory under
.terraform. When a module source points to a remote location such as Git, Terraform does not automatically fetch newer code on every plan or apply. To update installed modules, you use module installation/update commands such asterraform get -updateor, in current workflows,terraform init -upgrade. This is the appropriate way to refresh the local copy of the remote module. - B. Incorrect.
Incorrect.
terraform refreshupdates state to match real infrastructure, not downloaded module source code. It does not reinstall or upgrade child modules from a Git repository. This distractor reflects the common misconception that all update-related Terraform actions are handled through refresh. - C. Incorrect.
Incorrect. State tracks managed infrastructure objects, not the current contents of module source code. Deleting
.tfstateis destructive and unrelated to downloading updated module code. Terraform module installation is handled in the.terraformdirectory and byinit/get, not by manipulating state files. - D. Incorrect.
Incorrect. The
versionargument is supported for modules installed from the Terraform Registry, not arbitrary Git sources. For Git-based modules, version selection is typically controlled through thesourceURL, often using a?ref=query parameter to pin a branch, tag, or commit. There is no validversion = "latest"mechanism for Git module sources.