Why modules enable reusability in Terraform - See It in Action

Why modules enable reusability

📖 Scenario: You are managing cloud infrastructure using Terraform. You want to create reusable code blocks to deploy virtual machines with consistent settings across different projects.

🎯 Goal: Build a Terraform module for a virtual machine and reuse it twice with different names and IP addresses.

📋 What You'll Learn

Create a Terraform module with variables for VM name and IP address

Use the module twice in the main configuration with different inputs

Output the VM names from the module instances

💡 Why This Matters

🌍 Real World

Cloud engineers use Terraform modules to reuse infrastructure code for similar resources across projects, saving time and reducing errors.

💼 Career

Understanding modules is essential for infrastructure as code roles, enabling scalable and maintainable cloud deployments.

1

Create a Terraform module with variables

Create a Terraform module folder named vm_module. Inside it, create a file main.tf that defines a resource aws_instance with the name set to the variable vm_name and private IP set to the variable vm_ip. Also create a variables.tf file defining the variables vm_name and vm_ip as strings.

Terraform

# Your code here to create vm_module/main.tf and vm_module/variables.tf with variables vm_name and vm_ip

Hint

Define variables in variables.tf and use them in main.tf inside the module folder.

2

Add module usage in main Terraform configuration

In the root Terraform configuration, create a file main.tf. Add two module blocks named vm1 and vm2 that use the vm_module source. Set vm_name to "web-server-1" and vm_ip to "10.0.1.10" for vm1. Set vm_name to "web-server-2" and vm_ip to "10.0.1.11" for vm2.

Terraform

variable "vm_name" {
  type = string
}

variable "vm_ip" {
  type = string
}

resource "aws_instance" "vm" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"
  private_ip    = var.vm_ip
  tags = {
    Name = var.vm_name
  }
}

# Add two module blocks named vm1 and vm2 using vm_module source
# Your code here

Hint

Use module "name" { source = "./vm_module" ... } blocks to reuse the module with different inputs.

3

Add outputs in the module

Inside the vm_module folder, create a file outputs.tf. Add an output named vm_name_output that outputs the tag Name of the aws_instance.vm resource.

Terraform

variable "vm_name" {
  type = string
}

variable "vm_ip" {
  type = string
}

resource "aws_instance" "vm" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"
  private_ip    = var.vm_ip
  tags = {
    Name = var.vm_name
  }
}

# Add output vm_name_output in vm_module/outputs.tf
# Your code here

Hint

Outputs allow you to expose values from modules. Use output "name" { value = ... }.

4

Output module instance names in root configuration

In the root main.tf, add two outputs named vm1_name and vm2_name. Set their values to the outputs vm_name_output from the modules vm1 and vm2 respectively.

Terraform

variable "vm_name" {
  type = string
}

variable "vm_ip" {
  type = string
}

resource "aws_instance" "vm" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"
  private_ip    = var.vm_ip
  tags = {
    Name = var.vm_name
  }
}

output "vm_name_output" {
  value = aws_instance.vm.tags["Name"]
}

module "vm1" {
  source  = "./vm_module"
  vm_name = "web-server-1"
  vm_ip   = "10.0.1.10"
}

module "vm2" {
  source  = "./vm_module"
  vm_name = "web-server-2"
  vm_ip   = "10.0.1.11"
}

# Add outputs vm1_name and vm2_name in root main.tf
# Your code here

Hint

Use output "name" { value = module.module_name.output_name } to expose module outputs.

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