Creating a child module in Terraform - Performance & Efficiency

Time Complexity: Creating a child module

O(n)

Understanding Time Complexity

When using Terraform, creating a child module means calling a separate set of instructions multiple times.

We want to know how the time to apply changes grows as we add more child modules.

Scenario Under Consideration

Analyze the time complexity of the following operation sequence.

module "child" {
  source = "./child_module"
  count  = var.instance_count
  name   = "example-${count.index}"
}

variable "instance_count" {
  type    = number
  default = 3
}

This code creates multiple instances of a child module based on a count variable.

Identify Repeating Operations

Identify the API calls, resource provisioning, data transfers that repeat.

• Primary operation: Each child module creates its own resources, triggering API calls to provision them.
• How many times: The number of times equals the count variable, as each module instance runs separately.

How Execution Grows With Input

As the count increases, the number of API calls grows proportionally because each module instance provisions resources independently.

Input Size (n)	Approx. API Calls/Operations
10	10 times the resources in one module
100	100 times the resources in one module
1000	1000 times the resources in one module

Pattern observation: The work grows directly with the number of module instances.

Final Time Complexity

Time Complexity: O(n)

This means the time to apply grows linearly as you add more child module instances.

Common Mistake

[X] Wrong: "Adding more child modules won't increase the time much because they run together."

[OK] Correct: Each child module creates resources separately, so more modules mean more total work and API calls.

Interview Connect

Understanding how module count affects provisioning time helps you design scalable infrastructure and explain your choices clearly.

Self-Check

"What if the child module itself creates multiple resources internally? How would that affect the time complexity?"

Practice

1. What is the main purpose of creating a child module in Terraform?

easy

A. To avoid using variables in Terraform

B. To break down infrastructure into smaller, reusable pieces

C. To increase the number of resources in the root module

D. To deploy resources only in one cloud provider

Solution

1. Step 1: Understand module purpose

   Child modules help organize infrastructure by splitting it into smaller parts.

2. Step 2: Identify benefits

   This makes code reusable and easier to manage across projects.

3. Final Answer:

   To break down infrastructure into smaller, reusable pieces -> Option B

4. Quick Check:

   Child modules = reusable infrastructure parts [OK]

Hint: Child modules = smaller reusable parts of infrastructure [OK]

Common Mistakes:

• Thinking child modules increase resource count in root
• Believing child modules remove need for variables
• Assuming child modules limit to one cloud provider

2. Which Terraform block correctly includes a child module located in the folder ./modules/network?

easy

A. variable "network" { source = "./modules/network" }

B. resource "network" { source = "./modules/network" }

C. provider "network" { source = "./modules/network" }

D. module "network" { source = "./modules/network" }

Solution

1. Step 1: Identify correct block type

   Child modules are included using the module block in Terraform.

2. Step 2: Check syntax for source

   The source attribute points to the child module folder path.

3. Final Answer:

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

4. Quick Check:

   Use module block with source path [OK]

Hint: Use module block with source path to include child module [OK]

Common Mistakes:

• Using resource or provider blocks instead of module
• Placing source inside resource or variable blocks
• Incorrect block type for including modules

3. Given this root module code:

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

And the child module variables.tf contains:

variable "instance_count" {
  type = number
}

What will be the value of var.instance_count inside the child module?

medium

A. 3

B. 0

C. null

D. 1

Solution

1. Step 1: Check variable passing

   The root module passes instance_count = 3 to the child module.

2. Step 2: Confirm variable usage

   The child module declares instance_count variable to receive this value.

3. Final Answer:

   3 -> Option A

4. Quick Check:

   Passed variable value = 3 [OK]

Hint: Passed variable values appear inside child module as given [OK]

Common Mistakes:

• Assuming default or null if variable is declared
• Confusing variable names or missing passing
• Thinking child module variables reset automatically

4. You wrote this root module code:

module "db" {
  source = "./modules/database"
  db_name = "prod"
}

But Terraform shows an error: An argument named "db_name" is not expected here. Did you mean to define a variable named "db_name"?
What is the likely cause?

medium

A. Terraform does not support passing variables to modules

B. The source path is incorrect

C. The child module does not declare a variable named db_name

D. The root module must use resource block instead of module

Solution

1. Step 1: Analyze error message

   The error indicates that the argument "db_name" is not expected, which happens when the child module does not declare a variable named "db_name".

2. Step 2: Check child module variables

   If child module does not declare variable "db_name", Terraform cannot accept the passed value.

3. Final Answer:

   The child module does not declare a variable named db_name -> Option C

4. Quick Check:

   Passing undeclared argument causes "not expected" error [OK]

Hint: Declare variables in child module to accept passed values [OK]

Common Mistakes:

• Ignoring variable declaration in child module
• Assuming source path error without checking variables
• Thinking modules can't receive variables

5. You want to create a child module that provisions an AWS S3 bucket with a customizable name and versioning enabled by default. Which of the following variables.tf and main.tf snippets inside the child module is the best practice?

hard

A. variables.tf:variable "bucket_name" { type = string }
variable "versioning" { type = bool, default = true }main.tf:resource "aws_s3_bucket" "bucket" {
bucket = var.bucket_name
versioning {
enabled = var.versioning
}
}

B. variables.tf:variable "bucket_name" { type = string, default = "mybucket" }
variable "versioning" { type = string }main.tf:resource "aws_s3_bucket" "bucket" {
bucket = var.bucket_name
versioning {
enabled = var.versioning
}
}

C. variables.tf:variable "bucket_name" { type = string }
variable "versioning" { type = string, default = "true" }main.tf:resource "aws_s3_bucket" "bucket" {
bucket = var.bucket_name
versioning {
enabled = var.versioning
}
}

D. variables.tf:variable "bucket_name" { type = number }
variable "versioning" { type = bool }main.tf:resource "aws_s3_bucket" "bucket" {
bucket = var.bucket_name
versioning {
enabled = var.versioning
}
}

Solution

1. Step 1: Check variable types and defaults

   Bucket name should be string without default to force user input. Versioning is boolean with default true.

2. Step 2: Validate resource usage

   Resource uses var.bucket_name and var.versioning correctly with boolean type for versioning enabled.

3. Final Answer:

   variables.tf with string and bool (default true), main.tf using these variables correctly -> Option A

4. Quick Check:

   Correct types and defaults = variables.tf:
   

   variable "bucket_name" { type = string }
   variable "versioning" { type = bool, default = true }

   
   main.tf:
   

   resource "aws_s3_bucket" "bucket" {
     bucket = var.bucket_name
     versioning {
       enabled = var.versioning
     }
   }

   [OK]

Hint: Use correct variable types and defaults for best practice [OK]

Common Mistakes:

• Using string type for boolean variables
• Setting wrong default types
• Using number type for bucket name