Module versioning in Terraform - Step-by-Step Execution

Process Flow - Module versioning

Define module source with version

↓

Terraform init downloads module version

↓

Terraform plan uses module version

↓

Terraform apply deploys infrastructure

↓

Update version in config to upgrade module

↓

Terraform init -upgrade upgrades module version

↓

Terraform apply deploys updated infra

Terraform uses module versioning to control which module code is used during deployment. You specify a version, Terraform downloads that version, and applies it. Updating the version updates the module.

Execution Sample

Terraform

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "3.14.0"
  name    = "my-vpc"
  cidr    = "10.0.0.0/16"
}

This code uses a specific version 3.14.0 of the AWS VPC module to create a VPC named 'my-vpc'.

Process Table

Step	Action	Module Version	Terraform Command	Result
1	Define module with version 3.14.0	3.14.0	terraform init	Module version 3.14.0 downloaded
2	Run terraform plan	3.14.0	terraform plan	Plan created using module 3.14.0
3	Run terraform apply	3.14.0	terraform apply	Infrastructure deployed with module 3.14.0
4	Update module version to 3.15.0	3.15.0	terraform init -upgrade	Module upgraded to 3.15.0
5	Run terraform apply	3.15.0	terraform apply	Infrastructure updated with module 3.15.0
6	No further changes	3.15.0	terraform apply	No changes, infra matches module 3.15.0

💡 Execution stops when infrastructure matches the specified module version and no changes are pending.

Status Tracker

Variable	Start	After Step 1	After Step 4	Final
module_version	undefined	3.14.0	3.15.0	3.15.0

Key Moments - 2 Insights

Why do I need to run 'terraform init' after changing the module version?

Because 'terraform init' downloads the specified module version. Without it, Terraform uses the old version. See execution_table steps 1 and 4.

What happens if I don't specify a version in the module source?

Terraform uses the latest module version available, which can cause unexpected changes. Specifying a version locks the module to a known state.

Visual Quiz - 3 Questions

Look at the execution table, what module version is used during the first 'terraform apply'?

A 3.15.0

B latest

C 3.14.0

D undefined

💡 Hint

Check the 'Module Version' column at step 3 in the execution_table.

At which step does Terraform upgrade the module version?

A Step 2

B Step 4

C Step 5

D Step 6

💡 Hint

Look for 'Module upgraded' in the 'Result' column in execution_table.

If you skip 'terraform init -upgrade' after changing the version, what happens?

A Terraform uses the old module version

B Terraform throws an error

C Terraform uses the new version anyway

D Terraform deletes the module

💡 Hint

Refer to key_moments about why 'terraform init' is needed after version change.

Concept Snapshot

Terraform module versioning:
- Specify 'version' in module block to lock module version
- Run 'terraform init' to download module
- Use 'terraform init -upgrade' to update module version
- Terraform applies infrastructure using specified module version
- Helps keep infrastructure stable and predictable

Full Transcript

Module versioning in Terraform means specifying which version of a module to use in your configuration. When you write a module block with a version, Terraform downloads that exact version during 'terraform init'. Running 'terraform plan' and 'terraform apply' then uses that version to create or update infrastructure. If you want to upgrade the module, you change the version number and run 'terraform init -upgrade' to download the new version. This process ensures your infrastructure uses the module version you expect, avoiding surprises from automatic updates.

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