TF-Associate-004 - Terraform modules (11% of the exam) - Section 5d
Manage module versions.
The version argument, supported for registry modules, pins or constrains a module version so upgrades are deliberate. Candidates should reason about version constraints on modules and why pinning protects against an unexpected upstream change.
module version argumentversion constraintsregistry module versioningdeliberate module upgrades
Practice question for this objective
lock_openFree sampleTerraform modulesmedium
Why is pinning a registry module to a specific version considered good practice for deliberate upgrades?
AIt makes Terraform fetch the newest available release on every init so the configuration stays current automatically.
BIt removes the need to run terraform init after the module author publishes a new release.
CIt gives repeatable installs, so a module upgrade happens only when someone changes the constraint and reviews the new version.check_circle Correct
DIt allows the module to skip provider version resolution because the pinned module already carries compatible providers.
Explain that pinning a module version gives repeatable installs and makes upgrades deliberate and reviewable. A fixed version constraint resolves to the same module release on every run and every machine, so adopting a newer release requires a conscious edit that can be reviewed and tested rather than being pulled in silently.
Why A is wrong: This describes the opposite behaviour; automatic newest fetching is what pinning is meant to prevent, since it can introduce unreviewed changes.
Why B is wrong: This is tempting because pinning does reduce churn, but a new release still requires editing the constraint and re-initialising to adopt it, so init is not eliminated.
Why C is correct: Pinning fixes the resolved version across runs and machines, so a version change is an explicit, reviewable edit rather than an implicit shift when the registry gains a release.
Why D is wrong: Module version pinning does not bypass provider constraint resolution; providers are still resolved separately during init regardless of how the module is pinned.
Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.
Set source to "git::ssh://git@example.com/network.git" and add version = "1.2.0" as a separate argument.
errorWhy it is wrong: The version argument only applies to registry modules; for a raw Git source Terraform ignores it and would track the default branch instead of the tag.
Local modules are always considered experimental, so Terraform disables versioning for them until they are published.
errorWhy it is wrong: Local modules are fully supported, not experimental. The reason versioning does not apply is about published releases, not any experimental status.
The version argument is supported for any module block regardless of where the source points.
errorWhy it is wrong: This is tempting because version constraints feel like a general module feature, but Terraform only honours version for modules pulled from a registry; local path and direct VCS sources ignore or reject it.