Module versioning in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Terraform Module Version Pinning Behavior

Given the Terraform module source declaration below, what version of the module will Terraform use when you run terraform init?

module "network" {
  source  = "terraform-aws-modules/vpc/aws"
  version = ">= 2.0, < 3.0"
  name    = "my-vpc"
  cidr    = "10.0.0.0/16"
}

A The latest available module version between 2.0 (inclusive) and 3.0 (exclusive)

B Always version 2.0 exactly

C The latest available module version regardless of version constraints

D The latest available module version less than 2.0

💡 Hint

Think about how version constraints work in Terraform module sources.

Terraform respects semantic version constraints and picks the latest module version that fits the specified range. Here, it will pick the newest version >= 2.0 and < 3.0.

❓ service_behavior

intermediate

Effect of Module Version Change on Terraform Plan

You have a Terraform configuration using a module pinned to version 1.5.0. You update the version to 1.6.0 and run terraform plan. What will happen?

A Terraform will fail with a version conflict error

B Terraform will ignore the version change and plan no changes

C Terraform will detect changes in the module and show resource changes if any exist between versions

D Terraform will automatically upgrade all resources without showing a plan

💡 Hint

Consider how Terraform handles module upgrades during planning.

Changing the module version causes Terraform to download the new module code and compare resource definitions. It will show any changes in resources during the plan phase.

❓ Architecture

advanced

Managing Multiple Module Versions in a Large Terraform Codebase

You manage a large Terraform codebase with multiple teams. Some teams require different versions of the same module. What is the best architecture to support this?

A Use separate module blocks with explicit version pins for each team’s requirements

B Fork the module repository for each team and manage versions independently

C Use a single module block with the latest version and force all teams to upgrade simultaneously

D Avoid versioning and always use the module’s main branch

💡 Hint

Think about how Terraform modules and versioning can coexist in one codebase.

Using separate module blocks with explicit version pins allows teams to use different module versions safely without conflicts.

❓ security

advanced

Security Risks of Using Unpinned Module Versions

What is a key security risk of using Terraform modules without specifying a fixed version?

A Terraform will refuse to run without a pinned version

B Unexpected module updates could introduce malicious code or vulnerabilities

C Modules without versions cannot be downloaded from registries

D There is no security risk; always using latest is safest

💡 Hint

Consider what happens if a module changes unexpectedly.

Without version pinning, Terraform may download a newer module version that contains unreviewed or malicious changes, risking infrastructure security.

✅ Best Practice

expert

Best Practice for Module Versioning in CI/CD Pipelines

In a CI/CD pipeline deploying Terraform infrastructure, what is the best practice regarding module versioning to ensure stable and repeatable deployments?

A Do not specify versions and rely on the latest module code from the registry

B Use version constraints with ranges to always get the latest compatible module

C Manually copy module code into the repository to avoid versioning

D Pin exact module versions in the configuration and update them only after testing

💡 Hint

Think about stability and repeatability in automated deployments.

Pinning exact module versions ensures the same code is used every time, preventing unexpected changes during automated runs.

Practice

1. What is the main purpose of specifying a version when using a Terraform module from a registry?

easy

A. To speed up Terraform plan execution

B. To enable local module usage

C. To automatically update the module to the latest version

D. To keep your infrastructure stable by locking the module version

Solution

1. Step 1: Understand module versioning purpose

   Specifying a version locks the module to a specific release, preventing unexpected changes.

2. Step 2: Compare options

   Only locking the version ensures stability; automatic updates or speed improvements are not guaranteed by versioning.

3. Final Answer:

   To keep your infrastructure stable by locking the module version -> Option D

4. Quick Check:

   Module versioning = Stability [OK]

Hint: Version locks module to prevent unexpected changes [OK]

Common Mistakes:

• Thinking version speeds up execution
• Assuming version auto-updates modules
• Confusing local modules with versioned modules

2. Which of the following is the correct syntax to specify a module version from the Terraform Registry?

easy

A. module "example" { source = "registry/module" version = "1.2.0" }

B. module "example" { source = "registry/module" ver = "1.2.0" }

C. module "example" { source = "registry/module" version: "1.2.0" }

D. module "example" { source = "registry/module" v = "1.2.0" }

Solution

1. Step 1: Recall correct version attribute

   The correct attribute to specify module version is version with an equals sign.

2. Step 2: Check syntax correctness

   module "example" { source = "registry/module" version = "1.2.0" } uses correct attribute and syntax; others use incorrect attribute names or syntax.

3. Final Answer:

   module "example" { source = "registry/module" version = "1.2.0" } -> Option A

4. Quick Check:

   Correct attribute is version = "x.y.z" [OK]

Hint: Use 'version = "x.y.z"' exactly for module versions [OK]

Common Mistakes:

• Using 'ver' or 'v' instead of 'version'
• Using colon instead of equals sign
• Omitting quotes around version number

3. Given this Terraform module block:

module "network" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "3.0.0"
}

What happens if a newer version 3.1.0 is released and you run terraform init without changing the version?

medium

A. Terraform upgrades the module to version 3.1.0 automatically

B. Terraform uses version 3.0.0 and does not upgrade automatically

C. Terraform throws an error about version mismatch

D. Terraform ignores the version and uses the latest

Solution

1. Step 1: Understand version locking behavior

   Specifying version "3.0.0" locks the module to that exact version.

2. Step 2: Effect of terraform init

   Running terraform init downloads the locked version; it does not upgrade unless version is changed.

3. Final Answer:

   Terraform uses version 3.0.0 and does not upgrade automatically -> Option B

4. Quick Check:

   Locked version stays fixed until changed [OK]

Hint: Locked version stays fixed unless manually updated [OK]

Common Mistakes:

• Assuming terraform init upgrades modules automatically
• Expecting errors on version mismatch
• Thinking latest version is always used

4. You have this module block:

module "db" {
  source = "git::https://github.com/example/db-module.git"
}

You want to use a specific version tag v1.4.2. What is missing?

medium

A. Add tag = "v1.4.2" inside the block

B. Add version = "v1.4.2" inside the block

C. Add ?ref=v1.4.2 to the source URL

D. Nothing, it uses latest by default

Solution

1. Step 1: Understand versioning for Git modules

   Git modules use URL query parameter ?ref= to specify version or tag.

2. Step 2: Identify correct way to specify tag

   Adding ?ref=v1.4.2 to source URL locks module to that tag.

3. Final Answer:

   Add ?ref=v1.4.2 to the source URL -> Option C

4. Quick Check:

   Git module version = source URL + ?ref=tag [OK]

Hint: Use ?ref=tag in Git source URL for versioning [OK]

Common Mistakes:

• Using version attribute for Git modules
• Using tag attribute which does not exist
• Assuming latest is always used without specifying ref

5. You have a local module at ./modules/app and a remote module from the registry. You want to ensure only the remote module uses versioning. How should you configure the modules?

hard

A. Specify version only for the remote module; omit for local module

B. Specify version for both local and remote modules

C. Specify version only for the local module

D. Omit version for both modules

Solution

1. Step 1: Recall versioning rules for local modules

   Local modules do not support versioning; version attribute is ignored or causes error.

2. Step 2: Apply version only to remote modules

   Only remote modules from registries or Git support versioning and require version locking.

3. Final Answer:

   Specify version only for the remote module; omit for local module -> Option A

4. Quick Check:

   Version only for remote modules [OK]

Hint: Version attribute only for remote modules, never local [OK]

Common Mistakes:

• Adding version to local modules causing errors
• Omitting version for remote modules causing instability
• Confusing local and remote module versioning rules