Dependency inversion with modules in Terraform - Step-by-Step Execution

Process Flow - Dependency inversion with modules

Define low-level module

↓

Define high-level module

↓

High-level module calls low-level module

↓

Root module calls high-level module

↓

Terraform applies root module

↓

Dependency inversion achieved: root depends on abstraction

Shows how Terraform modules depend on abstractions, not details, by having high-level modules call low-level modules, and root module calling high-level modules.

Execution Sample

Terraform

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

module "app" {
  source = "./modules/app"
  network_id = module.network.id
}

Root module calls network module first, then app module uses network's output, showing dependency inversion.

Process Table

Step	Action	Module	Input/Output	Result
1	Start terraform apply	root	No inputs yet	Begin processing modules
2	Call network module	network	No inputs	Creates network, outputs id=net-123
3	Call app module	app	Input network_id=net-123	Creates app using network id
4	Complete apply	root	All modules applied	Infrastructure ready with app linked to network

💡 All modules applied successfully, dependencies resolved by passing outputs as inputs

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
module.network.id	undefined	net-123	net-123	net-123
module.app.network_id	undefined	undefined	net-123	net-123

Key Moments - 2 Insights

Why does the app module get the network id as input instead of creating the network itself?

Because the network module is a low-level module that creates the network, and the app module depends on it. Passing the network id as input in step 3 (execution_table) shows dependency inversion: app depends on network's abstraction, not implementation.

What ensures the network module runs before the app module?

Terraform automatically orders module execution based on input dependencies. Since app module uses network_id output from network module (step 3), Terraform runs network module first (step 2).

Visual Quiz - 3 Questions

Look at the execution table, what is the value of module.network.id after step 2?

A net-123

B undefined

C null

D app-456

💡 Hint

Check the 'Input/Output' column in row for step 2

At which step does the app module receive the network id as input?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at the 'Action' and 'Input/Output' columns in the execution table

If the app module did not depend on network module output, what would change in the execution table?

A Step 4 would fail

B Step 2 would be skipped

C Step 3 would not have network_id input

D No changes

💡 Hint

Dependency inversion means passing outputs as inputs; removing that breaks input in step 3

Concept Snapshot

Terraform modules can depend on each other by passing outputs as inputs.
Low-level modules provide resources and outputs.
High-level modules use those outputs as inputs.
Root module calls high-level modules.
This inverts dependency: modules depend on abstractions, not details.
Terraform orders execution based on these dependencies.

Full Transcript

This visual execution shows how Terraform modules use dependency inversion. The root module calls a low-level network module first, which creates a network and outputs its id. Then the root calls a high-level app module, passing the network id as input. Terraform runs the network module first, then the app module, ensuring dependencies are respected. Variables track the network id being passed along. This pattern means modules depend on abstractions (outputs) rather than creating resources themselves, making infrastructure modular and flexible.