Dependency inversion with modules in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

How does dependency inversion improve Terraform module design?

In Terraform, dependency inversion helps create modules that are more reusable and less tightly coupled. Which statement best describes this benefit?

A Modules depend on concrete resource names inside other modules to ensure exact resource usage.

B Modules avoid using variables and outputs to reduce complexity.

C Modules hardcode provider configurations to avoid external dependencies.

D Modules depend on abstract input variables and outputs rather than specific resource implementations.

💡 Hint

Think about how modules can be flexible and reusable without knowing internal details of other modules.

Dependency inversion means modules rely on abstractions (inputs/outputs) instead of concrete details. This makes modules reusable and easier to maintain.

❓ Configuration

intermediate

Identify the correct way to invert dependency between Terraform modules

Given two Terraform modules, network and app, the app module needs the subnet ID created by network. Which code snippet correctly applies dependency inversion?

Terraform

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

module "app" {
  source    = "./app"
  subnet_id = ???
}

A subnet_id = module.network.subnet_id

B subnet_id = "network_subnet_id"

C subnet_id = var.subnet_id

D subnet_id = aws_subnet.network.id

💡 Hint

Remember that modules expose outputs to share data.

The network module should expose the subnet ID as an output. The app module receives it via input variable. Using module.network.subnet_id correctly passes the value.

❓ security

advanced

What security risk arises from tightly coupling Terraform modules without dependency inversion?

When Terraform modules directly reference each other's internal resources instead of using inputs and outputs, what security risk is most likely?

A Modules automatically encrypt all data, reducing security risks.

B Accidental modification or deletion of resources due to unclear ownership.

C Increased risk of provider credential leakage.

D Exposing sensitive data by hardcoding secrets inside modules.

💡 Hint

Think about what happens if one module changes internal resource names used by another module.

Without dependency inversion, modules tightly coupled to internal resources can cause accidental changes or deletions because ownership and boundaries are unclear.

❓ service_behavior

advanced

How does dependency inversion affect Terraform plan and apply behavior?

When Terraform modules use dependency inversion properly, how does it affect the terraform plan and terraform apply commands?

A Terraform can correctly determine resource dependencies and apply changes in the right order.

B Terraform fails to detect dependencies and applies resources in random order.

C Terraform ignores module outputs and applies all resources simultaneously.

D Terraform requires manual intervention to order resource creation.

💡 Hint

Consider how Terraform uses inputs and outputs to build a dependency graph.

Proper dependency inversion with inputs and outputs allows Terraform to build an accurate dependency graph, ensuring resources are created or updated in the correct order.

✅ Best Practice

expert

Which Terraform module design best follows dependency inversion principles for multi-environment deployment?

You want to deploy the same infrastructure modules to multiple environments (dev, staging, prod) with different configurations. Which design best applies dependency inversion?

A Embed environment logic inside resource names within modules to differentiate environments.

B Create separate copies of modules for each environment with hardcoded values inside.

C Use a single module with input variables for environment-specific settings and outputs for shared data.

D Avoid using modules and write all resources inline for each environment.

💡 Hint

Think about how to reuse code and separate configuration from implementation.

Using input variables for environment-specific settings and outputs for sharing data follows dependency inversion. It keeps modules reusable and decoupled from environment details.

Practice

1. What does dependency inversion mean in Terraform modules?

easy

A. Modules cannot accept variables

B. Modules depend on inputs instead of creating resources themselves

C. Modules always create all resources internally

D. Modules must be written in the root configuration

Solution

1. Step 1: Understand module dependency principle

   Dependency inversion means modules should not create resources directly but rely on inputs.

2. Step 2: Identify correct description

   Modules depend on inputs instead of creating resources themselves correctly states modules depend on inputs, making them flexible and reusable.

3. Final Answer:

   Modules depend on inputs instead of creating resources themselves -> Option B

4. Quick Check:

   Dependency inversion = Modules use inputs [OK]

Hint: Modules get resource info via inputs, not by creating resources [OK]

Common Mistakes:

• Thinking modules must create all resources internally
• Assuming modules cannot accept variables
• Believing modules must be in root config

2. Which of the following is the correct way to pass a resource ID to a module in Terraform?

easy

A. module "example" { resource_id = aws_instance.example.id }

B. module "example" { input_id = aws_instance.example.id }

C. module "example" { instance_id = var.instance_id }

D. module "example" { instance_id = aws_instance.example.id }

Solution

1. Step 1: Identify correct variable passing syntax

   Modules accept variables by name; the value can be a resource attribute like aws_instance.example.id.

2. Step 2: Check option correctness

   module "example" { instance_id = aws_instance.example.id } correctly passes instance_id with the resource ID aws_instance.example.id.

3. Final Answer:

   module "example" { instance_id = aws_instance.example.id } -> Option D

4. Quick Check:

   Pass resource ID as variable = module "example" { instance_id = aws_instance.example.id } [OK]

Hint: Use variable name = resource.attribute to pass IDs [OK]

Common Mistakes:

• Using undefined variable names like resource_id or input_id
• Passing resource IDs without variable names
• Confusing variable and resource references

3. Given this Terraform root module snippet:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

module "network" {
  source = "./modules/network"
  vpc_id = aws_vpc.main.id
}

What is the expected behavior of the network module?

medium

A. It ignores the VPC ID and creates a subnet only

B. It creates a new VPC inside the module

C. It uses the existing VPC ID passed as input

D. It fails because VPC ID cannot be passed as input

Solution

1. Step 1: Analyze root module resource and module call

   The root module creates an aws_vpc resource and passes its ID to the network module as vpc_id.

2. Step 2: Understand module behavior with input

   The network module uses the passed vpc_id to configure resources inside that VPC, not create a new one.

3. Final Answer:

   It uses the existing VPC ID passed as input -> Option C

4. Quick Check:

   Module uses input vpc_id = It uses the existing VPC ID passed as input [OK]

Hint: Modules use passed IDs to link resources, not recreate them [OK]

Common Mistakes:

• Assuming module creates a new VPC ignoring input
• Thinking passing resource IDs is invalid
• Believing module fails without explicit VPC creation

4. You have this module call:

module "db" {
  source = "./modules/db"
  subnet_id = aws_subnet.app.id
}

Inside the module, the variable is declared as variable "subnet" { type = string }. What error will occur?

medium

A. Error: Unknown variable 'subnet_id' in module

B. Error: Variable 'subnet' not provided

C. No error, variable names can differ

D. Error: aws_subnet.app.id is invalid

Solution

1. Step 1: Compare variable name and input argument

   The module expects a variable named 'subnet' but the input is 'subnet_id'.

2. Step 2: Understand Terraform variable matching

   Terraform matches input arguments to variable names exactly. 'subnet_id' does not match any variable, causing an unsupported argument error.

3. Final Answer:

   Error: Unknown variable 'subnet_id' in module -> Option A

4. Quick Check:

   Variable name mismatch causes unknown variable error [OK]

Hint: Variable names must match exactly between module and call [OK]

Common Mistakes:

• Assuming variable names can differ
• Confusing variable name with resource attribute name
• Ignoring error messages about missing variables

5. You want to create a reusable module for an AWS security group that attaches to any VPC. Which approach follows dependency inversion best?

hard

A. Module accepts a VPC ID as input and creates security group in that VPC

B. Module hardcodes a VPC ID inside the module code

C. Module requires the user to create security group outside and passes its ID

D. Module creates its own VPC and security group inside

Solution

1. Step 1: Understand dependency inversion for modules

   Modules should not create dependent resources like VPCs but accept them as inputs.

2. Step 2: Evaluate options for best practice

   Module accepts a VPC ID as input and creates security group in that VPC accepts VPC ID as input and creates the security group inside that VPC, following dependency inversion.

3. Final Answer:

   Module accepts a VPC ID as input and creates security group in that VPC -> Option A

4. Quick Check:

   Pass dependencies as inputs for flexibility [OK]

Hint: Pass VPC ID as input; module creates resources inside it [OK]

Common Mistakes:

• Hardcoding resource IDs inside modules
• Modules creating dependent resources themselves
• Requiring users to create resources outside without module help