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.