Why modules enable reusability in Terraform - Why It Works

Introduction

When building infrastructure, repeating the same code wastes time and can cause mistakes. Modules let you write code once and use it many times, making your work faster and safer.

When you need to create the same type of server or resource multiple times with small differences.

When you want to share infrastructure code with your team to keep things consistent.

When you want to organize your code into smaller, easy-to-understand parts.

When you want to update many resources at once by changing just one module.

When you want to avoid copying and pasting code, which can cause errors.

Config File - main.tf

main.tf

terraform {
  required_version = ">= 1.0"
}

module "web_server" {
  source = "./modules/web_server"
  server_name = "example-web"
  server_port = 8080
}

output "web_server_ip" {
  value = module.web_server.server_ip
}

This file uses a module called web_server from the modules/web_server folder.

The server_name and server_port are inputs to customize the module.

The output web_server_ip shows the IP address created by the module.

Commands

This command sets up Terraform and downloads the module code so it can be used.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...



Terraform has been successfully initialized!



You may now begin working with Terraform. Try running "terraform plan" to see

any changes that are required for your infrastructure.

This command shows what Terraform will do before making any changes. It helps you check that the module is used correctly.

Terminal

terraform plan

Expected Output

An execution plan has been generated and is shown below.

Resource actions are indicated with the following symbols:

  + create



Terraform will perform the following actions:



  # module.web_server.aws_instance.example will be created

  + resource "aws_instance" "example" {

      + ami           = "ami-12345678"

      + instance_type = "t2.micro"

      + tags          = {

          + "Name" = "example-web"

        }

    }



Plan: 1 to add, 0 to change, 0 to destroy.

This command creates the resources defined in the module without asking for confirmation.

Terminal

terraform apply -auto-approve

Expected Output

module.web_server.aws_instance.example: Creating...

module.web_server.aws_instance.example: Creation complete after 10s [id=i-0abcd1234efgh5678]



Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

→

-auto-approve - Skip manual approval to apply changes immediately

This command shows the IP address of the server created by the module.

Terminal

terraform output web_server_ip

Expected Output

54.123.45.67

Key Concept

If you remember nothing else from this pattern, remember: modules let you write infrastructure code once and reuse it many times to save effort and avoid mistakes.

Common Mistakes

Copying and pasting the same resource code instead of using a module

This causes duplicated code that is hard to update and can lead to errors.

Create a module for the repeated resource and call it with different inputs.

Not running 'terraform init' after adding a module

Terraform won't download the module code, causing errors when planning or applying.

Always run 'terraform init' after adding or changing modules.

Forgetting to pass required input variables to the module

Terraform will fail because the module needs those inputs to create resources.

Check the module's input variables and provide values when calling the module.

Summary

Use modules to write reusable infrastructure code once and call it multiple times.

Run 'terraform init' to download module code before planning or applying.

Use 'terraform plan' to check what changes will happen, then 'terraform apply' to create resources.

Use outputs from modules to get information about created resources.

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