HashiCorp Terraform Associate (004) Question 139
Single answer5a Explain how Terraform sources modulesA platform team wants to standardize how application teams consume Terraform modules. One team currently references a networking module with source = "./modules/network", which works on a developer laptop but fails in CI because the module is not present in the pipeline workspace. The team wants a source that Terraform can download automatically during terraform init, while also pinning the module to a specific released version. Which source configuration best meets these requirements?
- A
Use
source = "./modules/network"and addversion = "1.2.0"to pin the local module. - B
Use
source = "app.terraform.io/example-corp/network/aws"and addversion = "1.2.0"so Terraform can download the module from a private registry duringterraform init. - C
Use
source = "hashicorp/network/aws/1.2.0"because the version must be embedded directly in the source string for registry modules. - D
Use
source = "s3::https://s3.amazonaws.com/example-corp/network-module"and addversion = "1.2.0"because all remote module sources support theversionargument.
Show answer and explanation
Correct answer: B
Explanation
Terraform supports multiple module source types, including local paths, registry sources, VCS repositories, and generic remote package locations. Local path modules are not downloaded from elsewhere; Terraform simply reads them from the filesystem where the configuration is executed. That is why a local path may work on a developer workstation but fail in CI if the module directory is missing. To have Terraform automatically install a module during terraform init and pin it to a released version, the best fit is a registry source. Public and private module registries support the version argument, which allows teams to select a specific published version. By contrast, non-registry remote sources such as Git, S3, or HTTP archives do not use the version argument; they are pinned through source-specific mechanisms like Git refs or immutable URLs. This aligns with Terraform module source documentation and registry best practices for reproducible builds.
- A. Incorrect.
Incorrect. A local path source such as
./modules/networkonly works when the module files are already available relative to the root module. Terraform does not fetch local modules from another system duringterraform init. Also, theversionargument is only supported for modules from a module registry, not for local path sources. - B. Correct.
Correct. A private registry source, such as one hosted in HCP Terraform/Terraform Enterprise, allows Terraform to discover and download the module during
terraform init. Registry modules support a separateversionargument, which is the recommended way to pin a specific published module release. - C. Incorrect.
Incorrect. Registry module sources do not include the version in the source string. For registry modules, the source identifies the module address, and the version is specified separately with the
versionargument. Embedding the version in the source string reflects a common misunderstanding of module source syntax. - D. Incorrect.
Incorrect. Terraform can download modules from non-registry remote sources such as S3-backed archives, but the
versionargument does not apply to arbitrary remote sources. Version selection is a registry feature. For non-registry sources, teams typically pin by referencing a specific archive URL, Git ref, or immutable artifact location.