Task 5.4: Manage module versions

• Aversion = "~> 3.0" in the module block

  Correct

  Registry modules accept a version constraint; "~> 3.0" allows 3.x releases and excludes 4.0.

• Bversion = "~> 3.0.0" in the module block

  Incorrect

  That allows only 3.0.x patch releases, not 3.1 and later.

• Csource = "terraform-aws-modules/vpc/aws@3"

  Incorrect

  Terraform does not accept an @ version suffix in a source address.

• DA required_providers entry for the module with version "~> 3.0"

  Incorrect

  required_providers is for providers, not modules.

Registry modules carry their own version argument with the usual constraint syntax.

• AThe lock file was stale; deleting it makes both select the same version

  Incorrect

  The lock file never contained module versions.

• BModules are re-downloaded on every plan, so plans must run with -lock=false

  Incorrect

  Modules are installed by init, and state locking is unrelated to module versions.

• CRegistry modules ignore version constraints after the first install

  Incorrect

  Constraints are honored; ">= 2.0" simply allows newer releases.

• DThe lock file tracks only providers, so pin the module with an exact version

  Correct

  Terraform does not record module selections in the lock file; an exact version constraint guarantees the same module version.

Providers are locked by .terraform.lock.hcl; modules are locked only by exact constraints.

• AThe output of terraform version in the working directory

  Incorrect

  version reports Terraform and installed provider versions, not module releases.

• BThe module's page in the Terraform Registry, which shows its versions and usage instructions

  Correct

  Each registry module is versioned, and its page shows usage instructions you can copy to get started.

• CThe dependency lock file of another project that uses the module

  Incorrect

  Lock files record provider selections, not module versions.

• DThe state file, which records every version a module ever had

  Incorrect

  State records resources, not a module's release history.

The Registry page is the catalog of a module's versions and the place to copy its calling syntax.

• Aversion = ">= 1.4, < 2.0"

  Correct

  Multiple conditions are separated by commas, and versions must meet all of them.

• Bversion = "1.4 - 2.0"

  Incorrect

  Terraform has no hyphen range syntax.

• Cversion = "^1.4"

  Incorrect

  ^ is not a Terraform constraint operator.

• Dversion = "1.4+"

  Incorrect

  + is not a Terraform constraint operator.

Terraform constraints use =, !=, >, >=, <, <= and ~>, combined with commas.

• ANo version argument at all, so callers always get the newest release

  Incorrect

  Omitting constraints makes every new install unpredictable.

• BCopy each module's code into every root configuration

  Incorrect

  Copies lose the versioned releases that the registry provides.

• CUse only pre-release versions so changes are visible

  Incorrect

  Pre-releases are for testing, and need exact versions.

• DVersion ranges are reasonable here

  Correct

  The docs suggest version ranges when your organization consistently uses semantic versioning or follows a well-defined release process.

Trusted semantic versioning makes ranges safe; unknown publishers call for tighter pins.

• Aterraform providers -json

  Incorrect

  providers lists provider requirements.

• Bterraform state list -json

  Incorrect

  state list prints resource addresses from state, not module declarations.

• Cterraform version -json

  Incorrect

  version reports Terraform and provider versions.

• Dterraform modules -json

  Correct

  terraform modules (Terraform 1.10 and later) gives a view of the declared modules and can print it as JSON.

terraform modules is built for auditing module use.