Why modules enable reusability in Terraform - Visual Breakdown

Process Flow - Why modules enable reusability

Write module code once

↓

Save module as reusable unit

↓

Call module multiple times

↓

Each call creates resources

↓

Manage infrastructure easily

Modules let you write code once and use it many times, making infrastructure easier to manage and reuse.

Execution Sample

Terraform

module "network1" {
  source = "./modules/network"
  cidr_block = "10.0.0.0/16"
}

module "network2" {
  source = "./modules/network"
  cidr_block = "10.1.0.0/16"
}

This code calls the same network module twice with different settings to create two networks.

Process Table

Step	Action	Module Called	Input Variables	Resources Created
1	Start Terraform apply	-	-	-
2	Call module 'network1' first time	network1	cidr_block=10.0.0.0/16	VPC with 10.0.0.0/16
3	Call module 'network2' second time	network2	cidr_block=10.1.0.0/16	VPC with 10.1.0.0/16
4	Finish apply	-	-	Two separate VPCs created
5	Exit	No more modules to call	-	-

💡 All module calls completed, infrastructure created as per inputs

Status Tracker

Variable	Start	After 1	After 2	Final
cidr_block	undefined	10.0.0.0/16	10.1.0.0/16	10.1.0.0/16
resources_created	none	VPC with 10.0.0.0/16	VPC with 10.1.0.0/16	Two VPCs total

Key Moments - 2 Insights

Why can we use the same module multiple times with different inputs?

Because each module call is independent and uses its own input variables, as shown in steps 2 and 3 of the execution_table.

Does writing a module once mean it creates only one resource?

No, each time you call the module it creates resources separately, so multiple calls create multiple resources (see steps 2 and 3).

Visual Quiz - 3 Questions

Look at the execution_table, what is the cidr_block input for the second module call?

A 10.0.0.0/16

B 10.1.0.0/16

C undefined

D 10.2.0.0/16

💡 Hint

Check row 3 under Input Variables in the execution_table

At which step does Terraform finish creating all resources?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Look at the Resources Created column in step 4 of the execution_table

If we change the cidr_block in the first module call, what changes in the variable_tracker?

A Final value for cidr_block changes to the new first call value

B After 2 value for cidr_block changes

C Only After 1 value for cidr_block changes

D No changes happen

💡 Hint

See how cidr_block changes after each module call in variable_tracker

Concept Snapshot

Modules let you write infrastructure code once and reuse it many times.
Each module call can have different inputs.
Each call creates separate resources.
This saves time and reduces errors.
Modules help organize and scale infrastructure easily.

Full Transcript

Modules in Terraform are reusable units of infrastructure code. You write the module once and then call it multiple times with different inputs. Each call creates its own resources based on the inputs provided. This means you can manage similar infrastructure components easily without repeating code. The execution trace shows two calls to the same network module with different CIDR blocks, resulting in two separate virtual networks. Variables track the inputs and resources created at each step. This approach improves efficiency and organization in cloud infrastructure management.

Practice

1. What is the main benefit of using modules in Terraform?

easy

A. They let you reuse code to save time and reduce errors

B. They increase the cost of cloud resources

C. They make Terraform run slower

D. They prevent you from customizing infrastructure

Solution

1. Step 1: Understand what modules do

   Modules are reusable pieces of Terraform code that you can use multiple times.

2. Step 2: Identify the main benefit

   Using modules saves time and reduces errors by avoiding repeated code.

3. Final Answer:

   They let you reuse code to save time and reduce errors -> Option A

4. Quick Check:

   Modules = Reusability and error reduction [OK]

Hint: Modules = reusable code blocks to save time [OK]

Common Mistakes:

• Thinking modules increase costs
• Believing modules slow down Terraform
• Assuming modules prevent customization

2. Which syntax correctly calls a module named network in Terraform?

easy

A. resource "module" "network" { source = "./network" }

B. module "network" { source = "./network" }

C. module network { source = ./network }

D. resource "network" { source = "./network" }

Solution

1. Step 1: Recall module block syntax

   Modules are called using the module "name" { ... } block syntax.

2. Step 2: Check the correct usage

   module "network" { source = "./network" } uses the correct syntax with quotes around the module name and source path.

3. Final Answer:

   module "network" { source = "./network" } -> Option B

4. Quick Check:

   Module call syntax = module "name" [OK]

Hint: Module calls use module "name" { source = ... } [OK]

Common Mistakes:

• Using resource instead of module
• Omitting quotes around source path
• Mixing resource and module keywords

3. Given this module call:

module "web" {
  source = "./webserver"
  instance_count = 3
}

What happens when you change instance_count in the module input?

medium

A. Terraform deletes the module entirely

B. Terraform ignores the change and keeps the old count

C. Terraform creates or destroys instances to match the new count

D. Terraform throws a syntax error

Solution

1. Step 1: Understand module inputs

   Module inputs customize resources inside the module, like instance count.

2. Step 2: Effect of changing input

   Changing instance_count causes Terraform to update resources to match the new number.

3. Final Answer:

   Terraform creates or destroys instances to match the new count -> Option C

4. Quick Check:

   Module inputs control resource changes [OK]

Hint: Changing inputs updates resources accordingly [OK]

Common Mistakes:

• Thinking Terraform ignores input changes
• Assuming module is deleted on input change
• Expecting syntax errors from input changes

4. You wrote this module call:

module "db" {
  source = "./database"
  size = 10
  size = 20
}

What error will Terraform show?

medium

A. Duplicate argument 'size' declared

B. Missing required argument 'size'

C. Invalid source path error

D. No error, uses last 'size' value

Solution

1. Step 1: Check for duplicate arguments

   The module call has two size arguments, which is not allowed.

2. Step 2: Terraform error on duplicates

   Terraform throws an error about duplicate argument names in the same block.

3. Final Answer:

   Duplicate argument 'size' declared -> Option A

4. Quick Check:

   Duplicate args cause errors [OK]

Hint: No duplicate keys allowed in module blocks [OK]

Common Mistakes:

• Assuming last value overrides silently
• Ignoring duplicate argument errors
• Confusing missing argument with duplicates

5. You want to reuse a module for different environments (dev, prod) with different settings. What is the best way to achieve this?

hard

A. Copy the module code into separate folders for each environment

B. Create a new Terraform project for each environment without modules

C. Use one module call and manually edit the code each time

D. Call the module multiple times with different input variables for each environment

Solution

1. Step 1: Understand module reusability

   Modules are designed to be called multiple times with different inputs to customize behavior.

2. Step 2: Best practice for environments

   Calling the same module with different variables for dev and prod avoids code duplication and errors.

3. Final Answer:

   Call the module multiple times with different input variables for each environment -> Option D

4. Quick Check:

   Reuse modules with inputs for different environments [OK]

Hint: Use inputs to customize module calls per environment [OK]

Common Mistakes:

• Copying module code instead of reusing
• Editing module code manually each time
• Avoiding modules for environment separation