Dependencies and Data Sources

How I learned to orchestrate infrastructure by understanding the invisible threads that connect everything

Introduction: The Circular Dependency Nightmare

It was 11 PM on a Friday. I had been staring at this error for two hours:

Error: Cycle: local_file.app_config, local_file.db_config

"Circular dependency detected."

My infrastructure was simple: an application config that referenced a database config, and a database config that referenced the application config. Each needed information from the other.

Terraform refused to apply. It showed me a dependency graph that looked like an infinite loop. My resources were chasing each other's tails.

I tried everything:

Reordering resources (didn't matter)
Removing references (broke functionality)
Creating intermediate resources (made it worse)

Finally, at midnight, a senior engineer looked at my code.

"Your problem isn't the code," they said. "It's your mental model. You're thinking in terms of 'what depends on what' when you should be thinking in terms of 'what data flows where.'"

They showed me how to use data sources to read existing information without creating dependencies. They explained the difference between implicit and explicit dependencies. They taught me about lifecycle rules that break dependency chains.

In 30 minutes, they refactored my tangled mess into a clean, linear dependency graph.

That night changed how I think about infrastructure. Dependencies aren't just about order—they're about data flow, timing, and orchestration.

This article is everything I learned about managing dependencies in Terraform.

What Are Dependencies?

A dependency is when one resource must be created before another.

Simple Example

resource "random_integer" "port" {
  min = 8000
  max = 9000
}

resource "local_file" "config" {
  filename = "app.conf"
  content  = "port: ${random_integer.port.result}"
}

Dependency: local_file.config depends on random_integer.port

Why? The file needs the random port number that hasn't been generated yet.

The Dependency Challenge

Terraform must determine:

What order to create resources
Which resources can be created in parallel
How to handle failures and retries

Dependency Types

Implicit Dependencies

Implicit dependencies are automatically detected by Terraform when you reference one resource in another.

Basic Implicit Dependency

resource "random_string" "id" {
  length = 8
}

resource "local_file" "config" {
  filename = "config.txt"
  content  = "ID: ${random_string.id.result}"
  #              ^^^^^^^^^^^^^^^^^^^^^^^^
  #              Implicit dependency created here
}

Terraform knows:

Create random_string.id first
Then create local_file.config using the generated ID

Multiple Implicit Dependencies

resource "random_integer" "port" {
  min = 8000
  max = 9000
}

resource "random_string" "secret" {
  length  = 32
  special = true
}

resource "local_file" "config" {
  filename = "app.conf"
  content  = <<-EOT
    port: ${random_integer.port.result}
    secret: ${random_string.secret.result}
  EOT
}

Dependencies:

local_file.config depends on random_integer.port
local_file.config depends on random_string.secret

Creation order:

random_integer.port and random_string.secret (parallel)
local_file.config (after both complete)

Chained Dependencies

resource "random_integer" "base_port" {
  min = 8000
  max = 8999
}

resource "random_integer" "offset" {
  min = 0
  max = 100
}

locals {
  final_port = random_integer.base_port.result + random_integer.offset.result
}

resource "local_file" "config" {
  filename = "port.conf"
  content  = "port: ${local.final_port}"
}

Dependency chain:

random_integer.base_port ──┐
                           ├──> local.final_port ──> local_file.config
random_integer.offset ─────┘

Module Output Dependencies

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

resource "local_file" "app_config" {
  filename = "app.conf"
  content  = "db_host: ${module.database.host}"
  #                     ^^^^^^^^^^^^^^^^^^^^^^
  #                     Implicit dependency on module
}

Terraform knows:

Create all resources in module.database
Get output module.database.host
Create local_file.app_config

Explicit Dependencies

Explicit dependencies are manually specified when Terraform can't automatically detect the relationship.

When Implicit Isn't Enough

Sometimes resources depend on each other without referencing attributes:

# This file must exist before the other
resource "local_file" "schema" {
  filename = "schema.sql"
  content  = "CREATE TABLE users..."
}

# This file is separate but depends on schema
resource "local_file" "data" {
  filename = "data.sql"
  content  = "INSERT INTO users..."
  
  # Terraform doesn't know about the dependency!
  # We need to tell it explicitly
}

Problem: No attribute reference, so no implicit dependency.

The depends_on Meta-Argument

The depends_on meta-argument creates explicit dependencies.

Basic Usage

resource "local_file" "schema" {
  filename = "schema.sql"
  content  = "CREATE TABLE users (id INT, name VARCHAR(100));"
}

resource "local_file" "data" {
  filename = "data.sql"
  content  = "INSERT INTO users VALUES (1, 'Alice');"
  
  depends_on = [
    local_file.schema
  ]
}

Result: local_file.data won't be created until local_file.schema completes.

Multiple Dependencies

resource "local_file" "config_1" {
  filename = "config1.yaml"
  content  = "service: web"
}

resource "local_file" "config_2" {
  filename = "config2.yaml"
  content  = "service: api"
}

resource "local_file" "deployment" {
  filename = "deploy.sh"
  content  = "#!/bin/bash\necho 'Deploying...'"
  
  depends_on = [
    local_file.config_1,
    local_file.config_2
  ]
}

Creation order:

config_1 and config_2 (parallel)
deployment (after both complete)

Module Dependencies

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

module "application" {
  source = "./modules/app"
  
  depends_on = [
    module.networking
  ]
}

Result: All networking resources complete before any application resources start.

depends_on with count/for_each

resource "local_file" "prerequisites" {
  count    = 3
  filename = "prereq-${count.index}.txt"
  content  = "Prerequisite ${count.index}"
}

resource "local_file" "main" {
  filename = "main.txt"
  content  = "Main application"
  
  depends_on = [
    local_file.prerequisites
  ]
}

Result: All prerequisite files created before main file.

When to Use depends_on

Use depends_on when:

✅ Resources depend on each other but don't reference attributes
✅ You need to ensure specific ordering for operational reasons
✅ External systems require specific creation order
✅ Module must complete before another starts

Avoid depends_on when:

❌ You can use attribute references (implicit is better)
❌ You're just guessing at dependencies
❌ You're trying to fix unrelated errors

Understanding Data Sources

Data sources read information from external systems without managing those resources.

Resource vs Data Source

Resource: Terraform creates and manages it

resource "local_file" "example" {
  filename = "file.txt"
  content  = "I am managed by Terraform"
}

Data source: Terraform reads it but doesn't manage it

data "local_file" "example" {
  filename = "existing-file.txt"
  # Terraform reads this file but doesn't create/modify/delete it
}

Why Data Sources?

Scenario: You need information about resources created outside Terraform.

Example:

# File created manually or by another process
# $ echo "Manual content" > manual.txt

# Terraform reads it
data "local_file" "manual" {
  filename = "manual.txt"
}

# Use the content
resource "local_file" "processed" {
  filename = "processed.txt"
  content  = "Original: ${data.local_file.manual.content}"
}

Data Source Benefits

Read external data: Access resources not managed by Terraform
No dependencies created: Reading doesn't create resource dependencies
Always fresh: Data sources refresh on every plan/apply
Separation of concerns: Different teams manage different resources

Using Data Sources

Local File Data Source

Read existing file:

data "local_file" "version" {
  filename = "${path.module}/VERSION"
}

output "app_version" {
  value = trimspace(data.local_file.version.content)
}

Template File Data Source

Render template:

data "template_file" "config" {
  template = file("${path.module}/config.tpl")
  
  vars = {
    port        = 8080
    environment = "production"
  }
}

resource "local_file" "rendered_config" {
  filename = "config.yaml"
  content  = data.template_file.config.rendered
}

External Data Source

Run external program:

data "external" "git_info" {
  program = ["bash", "${path.module}/git-info.sh"]
}

output "git_commit" {
  value = data.external.git_info.result.commit
}

git-info.sh:

#!/bin/bash
# Must output JSON
echo "{\"commit\":\"$(git rev-parse HEAD)\",\"branch\":\"$(git branch --show-current)\"}"

HTTP Data Source

Fetch from URL:

data "http" "my_ip" {
  url = "https://api.ipify.org?format=json"
}

locals {
  my_ip = jsondecode(data.http.my_ip.response_body).ip
}

output "current_ip" {
  value = local.my_ip
}

Data Source with Dependencies

Data sources can depend on resources:

resource "local_file" "generated" {
  filename = "generated.txt"
  content  = "Generated content"
}

# Wait for file to be created, then read it
data "local_file" "read_generated" {
  filename = local_file.generated.filename
  
  depends_on = [
    local_file.generated
  ]
}

output "content" {
  value = data.local_file.read_generated.content
}

Remote State Data Sources

Read outputs from another Terraform state.

Why Remote State Data Sources?

Scenario: Infrastructure split across multiple Terraform projects.

Project 1 (Networking):

# networking/main.tf
resource "local_file" "network_config" {
  filename = "network.conf"
  content  = "network_id: vpc-123"
}

output "network_id" {
  value = "vpc-123"
}

output "subnet_ids" {
  value = ["subnet-1", "subnet-2", "subnet-3"]
}

Project 2 (Application):

# application/main.tf
data "terraform_remote_state" "networking" {
  backend = "local"
  
  config = {
    path = "../networking/terraform.tfstate"
  }
}

resource "local_file" "app_config" {
  filename = "app.conf"
  content  = <<-EOT
    network: ${data.terraform_remote_state.networking.outputs.network_id}
    subnets: ${join(", ", data.terraform_remote_state.networking.outputs.subnet_ids)}
  EOT
}

Remote State with S3 Backend

data "terraform_remote_state" "networking" {
  backend = "s3"
  
  config = {
    bucket = "terraform-state"
    key    = "networking/terraform.tfstate"
    region = "us-east-1"
  }
}

locals {
  vpc_id     = data.terraform_remote_state.networking.outputs.vpc_id
  subnet_ids = data.terraform_remote_state.networking.outputs.subnet_ids
}

Remote State Best Practices

1. Explicit outputs:

# networking/outputs.tf
output "vpc_id" {
  value       = aws_vpc.main.id
  description = "VPC ID for application deployment"
}

2. Stable interfaces: Don't change output names—dependent projects rely on them!

3. Documentation: Document what outputs are available and their purpose.

Dependency Graph

Terraform builds a dependency graph to determine creation order.

Visualizing Dependencies

terraform graph | dot -Tpng > graph.png

Requires: graphviz package

# macOS
brew install graphviz

# Ubuntu
sudo apt-get install graphviz

Simple Graph Example

Configuration:

resource "random_integer" "port" {
  min = 8000
  max = 9000
}

resource "local_file" "config" {
  filename = "config.txt"
  content  = "port: ${random_integer.port.result}"
}

Graph:

Complex Graph

Configuration:

resource "random_integer" "port" {
  min = 8000
  max = 9000
}

resource "random_string" "secret" {
  length = 32
}

resource "local_file" "app_config" {
  filename = "app.conf"
  content  = "port: ${random_integer.port.result}"
}

resource "local_file" "db_config" {
  filename = "db.conf"
  content  = "secret: ${random_string.secret.result}"
}

resource "local_file" "main_config" {
  filename = "main.conf"
  content  = <<-EOT
    app: ${local_file.app_config.filename}
    db: ${local_file.db_config.filename}
  EOT
}

Graph:

Execution order:

random_integer.port and random_string.secret (parallel)
local_file.app_config and local_file.db_config (parallel, after step 1)
local_file.main_config (after step 2)

Analyzing the Graph

# Generate graph
terraform graph > graph.dot

# Count resources
grep -c "label" graph.dot

# Find root nodes (no dependencies)
grep "\[root\]" graph.dot

# Find leaf nodes (nothing depends on them)
# (More complex analysis)

Lifecycle Meta-Arguments and Dependencies

Lifecycle meta-arguments affect how dependencies work.

create_before_destroy

Default behavior: Destroy old, then create new

Problem: Can cause downtime

Solution:

resource "local_file" "config" {
  filename = "app.conf"
  content  = var.config_content
  
  lifecycle {
    create_before_destroy = true
  }
}

Result:

Create new app.conf (with different ID)
Update references to point to new file
Destroy old app.conf

prevent_destroy

Prevent accidental deletion:

resource "local_file" "critical" {
  filename = "critical-data.txt"
  content  = "DO NOT DELETE"
  
  lifecycle {
    prevent_destroy = true
  }
}

Attempting to destroy:

terraform destroy

Error:

Error: Instance cannot be destroyed

  on main.tf line 1:
   1: resource "local_file" "critical" {

Resource local_file.critical has lifecycle.prevent_destroy set, but the plan
calls for this resource to be destroyed.

ignore_changes

Ignore specific attribute changes:

resource "local_file" "config" {
  filename = "app.conf"
  content  = "initial content"
  
  lifecycle {
    ignore_changes = [
      content  # Ignore manual edits to content
    ]
  }
}

Use case: Resource modified by external systems

replace_triggered_by

Replace when related resource changes:

resource "random_string" "version" {
  length = 8
}

resource "local_file" "config" {
  filename = "config.txt"
  content  = "version: ${random_string.version.result}"
  
  lifecycle {
    replace_triggered_by = [
      random_string.version.id
    ]
  }
}

Result: File replaced every time version changes

Module Dependencies

Modules can depend on other modules.

Implicit Module Dependencies

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

module "application" {
  source = "./modules/app"
  
  # Implicit dependency via output reference
  network_id = module.networking.network_id
}

Explicit Module Dependencies

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

module "application" {
  source = "./modules/app"
  
  # Explicit dependency
  depends_on = [
    module.database
  ]
}

When to use:

Database must be fully initialized before app starts
Network infrastructure must exist first
Secrets must be created before services

Module Output Dependencies

Networking module:

# modules/networking/outputs.tf
output "vpc_id" {
  value = "vpc-123"
}

output "subnet_ids" {
  value = ["subnet-1", "subnet-2"]
}

Application module:

# main.tf
module "networking" {
  source = "./modules/networking"
}

module "application" {
  source = "./modules/application"
  
  vpc_id     = module.networking.vpc_id
  subnet_ids = module.networking.subnet_ids
}

Common Dependency Patterns

Pattern 1: Sequential Creation

resource "local_file" "step1" {
  filename = "step1.txt"
  content  = "Step 1 complete"
}

resource "local_file" "step2" {
  filename = "step2.txt"
  content  = "Step 2 complete"
  
  depends_on = [local_file.step1]
}

resource "local_file" "step3" {
  filename = "step3.txt"
  content  = "Step 3 complete"
  
  depends_on = [local_file.step2]
}

Pattern 2: Fan-Out

resource "random_string" "id" {
  length = 8
}

# All depend on the same source
resource "local_file" "service1" {
  filename = "service1.conf"
  content  = "id: ${random_string.id.result}"
}

resource "local_file" "service2" {
  filename = "service2.conf"
  content  = "id: ${random_string.id.result}"
}

resource "local_file" "service3" {
  filename = "service3.conf"
  content  = "id: ${random_string.id.result}"
}

Graph:

Pattern 3: Fan-In

resource "local_file" "config1" {
  filename = "config1.yaml"
  content  = "service: web"
}

resource "local_file" "config2" {
  filename = "config2.yaml"
  content  = "service: api"
}

resource "local_file" "config3" {
  filename = "config3.yaml"
  content  = "service: worker"
}

# Depends on all configs
resource "local_file" "deployment" {
  filename = "deploy.sh"
  content  = "#!/bin/bash\necho 'All configs ready'"
  
  depends_on = [
    local_file.config1,
    local_file.config2,
    local_file.config3
  ]
}

Graph:

Pattern 4: Diamond Dependency

resource "random_string" "base" {
  length = 8
}

resource "local_file" "branch1" {
  filename = "branch1.txt"
  content  = "base: ${random_string.base.result}"
}

resource "local_file" "branch2" {
  filename = "branch2.txt"
  content  = "base: ${random_string.base.result}"
}

resource "local_file" "merge" {
  filename = "merge.txt"
  content  = <<-EOT
    branch1: ${local_file.branch1.id}
    branch2: ${local_file.branch2.id}
  EOT
}

Graph:

Real-World Example: Multi-Tier Application with Dependencies

Complete example showing all dependency concepts.

Project Structure

multi-tier-app/
├── main.tf
├── variables.tf
├── outputs.tf
├── data.tf
└── modules/
    ├── database/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    ├── application/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    └── monitoring/
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

Database Module

modules/database/variables.tf:

variable "environment" {
  type = string
}

variable "database_name" {
  type = string
}

modules/database/main.tf:

resource "random_password" "db_password" {
  length  = 32
  special = true
}

resource "local_file" "db_config" {
  filename = "generated/database/${var.environment}/config.yaml"
  
  content = yamlencode({
    database = {
      name     = var.database_name
      host     = "localhost"
      port     = 5432
      user     = "dbuser"
    }
  })
  
  file_permission = "0644"
}

resource "local_file" "db_secret" {
  filename = "generated/database/${var.environment}/secret.txt"
  content  = random_password.db_password.result
  
  file_permission = "0600"
}

resource "local_file" "db_init_script" {
  filename = "generated/database/${var.environment}/init.sql"
  
  content = <<-EOT
    CREATE DATABASE ${var.database_name};
    CREATE USER dbuser WITH PASSWORD '${random_password.db_password.result}';
    GRANT ALL PRIVILEGES ON DATABASE ${var.database_name} TO dbuser;
  EOT
  
  file_permission = "0644"
}

modules/database/outputs.tf:

output "config_file" {
  value = local_file.db_config.filename
}

output "connection_string" {
  value = "postgresql://dbuser:***@localhost:5432/${var.database_name}"
}

output "host" {
  value = "localhost"
}

output "port" {
  value = 5432
}

output "database_name" {
  value = var.database_name
}

output "password" {
  value     = random_password.db_password.result
  sensitive = true
}

Application Module

modules/application/variables.tf:

variable "environment" {
  type = string
}

variable "service_name" {
  type = string
}

variable "database_host" {
  type = string
}

variable "database_port" {
  type = number
}

variable "database_name" {
  type = string
}

variable "database_password" {
  type      = string
  sensitive = true
}

modules/application/main.tf:

resource "random_integer" "app_port" {
  min = 8000
  max = 9000
}

resource "local_file" "app_config" {
  filename = "generated/application/${var.environment}/${var.service_name}.yaml"
  
  content = yamlencode({
    application = {
      name = var.service_name
      port = random_integer.app_port.result
      environment = var.environment
    }
    
    database = {
      host     = var.database_host
      port     = var.database_port
      name     = var.database_name
      password = var.database_password
    }
  })
  
  file_permission = "0644"
}

resource "local_file" "app_env" {
  filename = "generated/application/${var.environment}/${var.service_name}.env"
  
  content = <<-EOT
    SERVICE_NAME=${var.service_name}
    PORT=${random_integer.app_port.result}
    ENVIRONMENT=${var.environment}
    DB_HOST=${var.database_host}
    DB_PORT=${var.database_port}
    DB_NAME=${var.database_name}
    DB_PASSWORD=${var.database_password}
  EOT
  
  file_permission = "0600"
}

modules/application/outputs.tf:

output "service_name" {
  value = var.service_name
}

output "port" {
  value = random_integer.app_port.result
}

output "config_file" {
  value = local_file.app_config.filename
}

output "endpoint" {
  value = "http://localhost:${random_integer.app_port.result}"
}

Monitoring Module

modules/monitoring/variables.tf:

variable "environment" {
  type = string
}

variable "services" {
  type = map(object({
    name = string
    port = number
  }))
}

modules/monitoring/main.tf:

resource "local_file" "prometheus_config" {
  filename = "generated/monitoring/${var.environment}/prometheus.yml"
  
  content = yamlencode({
    global = {
      scrape_interval = "15s"
    }
    
    scrape_configs = [
      for name, service in var.services : {
        job_name = name
        static_configs = [
          {
            targets = ["localhost:${service.port}"]
            labels = {
              service     = service.name
              environment = var.environment
            }
          }
        ]
      }
    ]
  })
  
  file_permission = "0644"
}

resource "local_file" "monitoring_dashboard" {
  filename = "generated/monitoring/${var.environment}/dashboard.json"
  
  content = jsonencode({
    dashboard = {
      title = "${var.environment} Services"
      services = [
        for name, service in var.services : {
          name = service.name
          port = service.port
          url  = "http://localhost:${service.port}"
        }
      ]
    }
  })
  
  file_permission = "0644"
}

modules/monitoring/outputs.tf:

output "prometheus_config" {
  value = local_file.prometheus_config.filename
}

output "dashboard_config" {
  value = local_file.monitoring_dashboard.filename
}

Root Module

data.tf:

# Read external configuration
data "local_file" "version" {
  filename = "${path.module}/VERSION"
}

# Read environment-specific settings
data "local_file" "env_config" {
  filename = "${path.module}/environments/${var.environment}.yaml"
}

locals {
  version     = trimspace(data.local_file.version.content)
  env_config  = yamldecode(data.local_file.env_config.content)
}

variables.tf:

variable "environment" {
  type = string
  validation {
    condition     = contains(["dev", "staging", "production"], var.environment)
    error_message = "Must be dev, staging, or production."
  }
}

variable "project_name" {
  type    = string
  default = "multi-tier-blog"
}

variable "services" {
  type = list(string)
  default = ["web", "api", "worker"]
}

main.tf:

terraform {
  required_version = ">= 1.0"
  
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.4"
    }
    random = {
      source  = "hashicorp/random"
      version = "~> 3.5"
    }
  }
}

locals {
  deployment_id = random_uuid.deployment.result
  timestamp     = timestamp()
}

resource "random_uuid" "deployment" {}

# Step 1: Create database
module "database" {
  source = "./modules/database"
  
  environment   = var.environment
  database_name = "${var.project_name}_${var.environment}"
}

# Step 2: Create applications (depend on database)
module "applications" {
  source   = "./modules/application"
  for_each = toset(var.services)
  
  environment = var.environment
  service_name = each.key
  
  # Implicit dependencies via module outputs
  database_host     = module.database.host
  database_port     = module.database.port
  database_name     = module.database.database_name
  database_password = module.database.password
}

# Step 3: Create monitoring (depends on applications)
module "monitoring" {
  source = "./modules/monitoring"
  
  environment = var.environment
  
  services = {
    for name, app in module.applications :
    name => {
      name = app.service_name
      port = app.port
    }
  }
  
  # Explicit dependency on applications
  depends_on = [
    module.applications
  ]
}

# Step 4: Create deployment manifest
resource "local_file" "deployment_manifest" {
  filename = "generated/${var.environment}/deployment.yaml"
  
  content = yamlencode({
    deployment = {
      id          = local.deployment_id
      timestamp   = local.timestamp
      version     = local.version
      environment = var.environment
    }
    
    database = {
      config = module.database.config_file
      connection = module.database.connection_string
    }
    
    applications = {
      for name, app in module.applications :
      name => {
        config   = app.config_file
        endpoint = app.endpoint
      }
    }
    
    monitoring = {
      prometheus = module.monitoring.prometheus_config
      dashboard  = module.monitoring.dashboard_config
    }
  })
  
  file_permission = "0644"
  
  # Explicit dependency on all modules
  depends_on = [
    module.database,
    module.applications,
    module.monitoring
  ]
}

# Step 5: Create README with instructions
resource "local_file" "readme" {
  filename = "generated/${var.environment}/README.md"
  
  content = <<-EOT
    # ${var.project_name} - ${var.environment}
    
    **Version**: ${local.version}  
    **Deployment ID**: ${local.deployment_id}  
    **Deployed**: ${formatdate("YYYY-MM-DD hh:mm:ss ZZZ", local.timestamp)}
    
    ## Architecture
    
    This deployment consists of:
    - 1 PostgreSQL database
    - ${length(var.services)} application services
    - Monitoring stack (Prometheus + Dashboard)
    
    ## Services
    
    ${join("\n", [
      for name, app in module.applications :
      "### ${title(name)}\n- **Port**: ${app.port}\n- **Endpoint**: ${app.endpoint}\n- **Config**: ${app.config_file}"
    ])}
    
    ## Database
    
    - **Connection**: ${module.database.connection_string}
    - **Config**: ${module.database.config_file}
    
    ## Monitoring
    
    - **Prometheus**: ${module.monitoring.prometheus_config}
    - **Dashboard**: ${module.monitoring.dashboard_config}
    
    ## Deployment Order
    
    1. Database initialized
    2. Application services configured (parallel)
    3. Monitoring configured
    4. Deployment manifest created
    
    ## Quick Start
    
    ```bash
    # Start database
    docker-compose -f docker-compose.db.yml up -d
    
    # Start applications
    ${join("\n    ", [for s in var.services : "docker-compose -f docker-compose.${s}.yml up -d"])}
    
    # Start monitoring
    docker-compose -f docker-compose.monitoring.yml up -d
    ```
  EOT
  
  file_permission = "0644"
  
  depends_on = [
    local_file.deployment_manifest
  ]
}

outputs.tf:

output "deployment_info" {
  value = {
    id          = local.deployment_id
    timestamp   = local.timestamp
    version     = local.version
    environment = var.environment
  }
}

output "database" {
  value = {
    connection = module.database.connection_string
    config     = module.database.config_file
  }
  sensitive = true
}

output "applications" {
  value = {
    for name, app in module.applications :
    name => {
      endpoint = app.endpoint
      config   = app.config_file
    }
  }
}

output "monitoring" {
  value = {
    prometheus = module.monitoring.prometheus_config
    dashboard  = module.monitoring.dashboard_config
  }
}

output "files" {
  value = {
    deployment = local_file.deployment_manifest.filename
    readme     = local_file.readme.filename
  }
}

Dependency Graph

Supporting Files

VERSION:

2.0.0

environments/production.yaml:

tier: enterprise
replicas: 5
monitoring: advanced
backup: enabled

Deploy

# Create VERSION file
echo "2.0.0" > VERSION

# Create environment config
mkdir -p environments
cat > environments/production.yaml <<EOF
tier: enterprise
replicas: 5
monitoring: advanced
backup: enabled
EOF

# Deploy
terraform init
terraform apply -var="environment=production"

Result:

✅ Database created first
✅ Applications created in parallel (after database)
✅ Monitoring created (after applications)
✅ Deployment manifest created (after all modules)
✅ README generated (after manifest)

Debugging Dependency Issues

Enable Debug Logging

export TF_LOG=DEBUG
terraform plan

Analyze Dependency Graph

terraform graph | dot -Tpng > graph.png
open graph.png

List Resource Dependencies

terraform state show local_file.config

Output includes dependencies:

# local_file.config:
resource "local_file" "config" {
    # ...
    
    dependencies = [
        "random_integer.port"
    ]
}

Trace Execution Order

terraform apply -parallelism=1

Shows sequential execution

Circular Dependencies

The nightmare scenario.

Example of Circular Dependency

resource "local_file" "app_config" {
  filename = "app.conf"
  content  = "db_config: ${local_file.db_config.filename}"
}

resource "local_file" "db_config" {
  filename = "db.conf"
  content  = "app_config: ${local_file.app_config.filename}"
}

Error:

Error: Cycle: local_file.app_config, local_file.db_config

Breaking Circular Dependencies

Solution 1: Remove one dependency

resource "local_file" "app_config" {
  filename = "app.conf"
  content  = "db_config: db.conf"  # Hardcode instead of reference
}

resource "local_file" "db_config" {
  filename = "db.conf"
  content  = "app_config: app.conf"  # Hardcode instead of reference
}

Solution 2: Use intermediate resource

locals {
  app_config_path = "app.conf"
  db_config_path  = "db.conf"
}

resource "local_file" "app_config" {
  filename = local.app_config_path
  content  = "db_config: ${local.db_config_path}"
}

resource "local_file" "db_config" {
  filename = local.db_config_path
  content  = "app_config: ${local.app_config_path}"
}

Solution 3: Split into separate applies

# First apply - create app config
resource "local_file" "app_config" {
  filename = "app.conf"
  content  = "app configuration"
}

# Second apply - create db config with reference
resource "local_file" "db_config" {
  filename = "db.conf"
  content  = "app_config: ${local_file.app_config.filename}"
}

Parallel Resource Creation

Terraform creates independent resources in parallel.

Default Parallelism

terraform apply
# Default: 10 resources in parallel

Adjust Parallelism

# More parallelism (faster, more load)
terraform apply -parallelism=20

# Less parallelism (slower, less load)
terraform apply -parallelism=2

# Sequential (debugging)
terraform apply -parallelism=1

What Can Run in Parallel?

These can run in parallel:

resource "random_integer" "port1" {
  min = 8000
  max = 9000
}

resource "random_integer" "port2" {
  min = 8000
  max = 9000
}

resource "random_string" "id" {
  length = 8
}

These cannot (dependencies):

resource "random_integer" "port" {
  min = 8000
  max = 9000
}

resource "local_file" "config" {
  filename = "config.txt"
  content  = "port: ${random_integer.port.result}"
  # Must wait for port to be generated
}

Best Practices

1. Prefer Implicit Dependencies

Good:

resource "local_file" "config" {
  content = random_string.id.result  # Implicit
}

Avoid:

resource "local_file" "config" {
  content = "hardcoded"
  depends_on = [random_string.id]  # Explicit when not needed
}

2. Use depends_on Sparingly

Only when you can't use attribute references.

3. Document Dependencies

module "application" {
  source = "./modules/app"
  
  # Explicit dependency required because app needs DB to be fully
  # initialized before starting, even though we don't reference
  # specific DB attributes
  depends_on = [
    module.database
  ]
}

4. Avoid Circular Dependencies

Design your infrastructure to have clear dependency direction.

5. Use Data Sources for External Resources

# Read, don't manage
data "local_file" "existing" {
  filename = "existing.txt"
}

6. Visualize Dependencies

terraform graph | dot -Tpng > graph.png

Review the graph regularly.

7. Test Dependency Order

terraform apply -parallelism=1

Ensures resources are created in correct order.

What I Learned About Dependencies

1. Dependencies Are About Data Flow

Not just creation order. Resources depend on each other because they need data from each other.

Understanding data flow is key to understanding dependencies.

2. Implicit > Explicit

Terraform is smart. Let it detect dependencies automatically whenever possible.

Only use depends_on when you must.

3. Data Sources Break Dependency Chains

Reading external resources doesn't create dependencies the same way managing them does.

Use data sources to access existing resources without creating tight coupling.

4. Circular Dependencies Mean Design Problems

If you have circular dependencies, your infrastructure design needs refactoring.

Think about which resources truly depend on which.

5. The Graph Is Your Map

The dependency graph shows the truth about your infrastructure relationships.

Visualize it. Study it. Learn from it.

6. Modules Are Dependency Boundaries

Modules help organize dependencies into logical groups.

Clear module interfaces (inputs/outputs) make dependencies explicit.

Next Steps

Congratulations! You've mastered dependencies and data sources:

✅ Implicit vs explicit dependencies ✅ The depends_on meta-argument ✅ Data sources for external data ✅ Remote state data sources ✅ Dependency graphs ✅ Lifecycle rules ✅ Module dependencies ✅ Common patterns ✅ Multi-tier application with complex dependencies ✅ Debugging and troubleshooting

Practice Exercises

Exercise 1: Dependency Analysis

1. Take existing Terraform code
2. Generate dependency graph
3. Identify implicit vs explicit dependencies
4. Optimize by removing unnecessary depends_on

Exercise 2: Data Sources

1. Create resources manually
2. Read them with data sources
3. Use data in new resources
4. Observe no dependency creation

Exercise 3: Multi-Module Architecture

1. Split infrastructure into modules
2. Define clear interfaces (inputs/outputs)
3. Chain modules with dependencies
4. Visualize the graph

Coming Up Next

In Article 8: Testing Terraform - Validation, Testing, and Quality Assurance, we'll explore:

Input validation
terraform validate
terraform fmt and linting
Testing frameworks (Terratest, kitchen-terraform)
Integration testing
Policy as code (OPA, Sentinel)
CI/CD for Terraform

Dependencies connect your infrastructure. Testing ensures it works correctly.

This Week's Challenge: Map out all dependencies in your current infrastructure. Visualize the graph. Find opportunities to simplify using data sources or better module design.

See you in Article 8! 🔗

"The day I understood dependency graphs was the day circular dependencies stopped haunting me. Infrastructure isn't just code—it's relationships, data flow, and orchestration." - Me, after finally understanding the graph

PreviousState Management and Multi-Environment Workspaces NextTesting and Validation

Last updated 1 month ago

hashtagTable of Contents

hashtagIntroduction: The Circular Dependency Nightmare

hashtagWhat Are Dependencies?

hashtagSimple Example

hashtagThe Dependency Challenge

hashtagDependency Types

hashtagImplicit Dependencies

hashtagBasic Implicit Dependency

hashtagMultiple Implicit Dependencies

hashtagChained Dependencies

hashtagModule Output Dependencies

hashtagExplicit Dependencies

hashtagWhen Implicit Isn't Enough

hashtagThe depends_on Meta-Argument

hashtagBasic Usage

hashtagMultiple Dependencies

hashtagModule Dependencies

hashtagdepends_on with count/for_each

hashtagWhen to Use depends_on

hashtagUnderstanding Data Sources

hashtagResource vs Data Source

hashtagWhy Data Sources?

hashtagData Source Benefits

hashtagUsing Data Sources

hashtagLocal File Data Source

hashtagTemplate File Data Source

hashtagExternal Data Source

hashtagHTTP Data Source

hashtagData Source with Dependencies

hashtagRemote State Data Sources

hashtagWhy Remote State Data Sources?

hashtagRemote State with S3 Backend

hashtagRemote State Best Practices

hashtagDependency Graph

hashtagVisualizing Dependencies

hashtagSimple Graph Example

hashtagComplex Graph

hashtagAnalyzing the Graph

hashtagLifecycle Meta-Arguments and Dependencies

hashtagcreate_before_destroy

hashtagprevent_destroy

hashtagignore_changes

hashtagreplace_triggered_by

hashtagModule Dependencies

hashtagImplicit Module Dependencies

hashtagExplicit Module Dependencies

hashtagModule Output Dependencies

hashtagCommon Dependency Patterns

hashtagPattern 1: Sequential Creation

hashtagPattern 2: Fan-Out

hashtagPattern 3: Fan-In

hashtagPattern 4: Diamond Dependency

hashtagReal-World Example: Multi-Tier Application with Dependencies

hashtagProject Structure

hashtagDatabase Module

hashtagApplication Module

hashtagMonitoring Module

hashtagRoot Module

hashtagDependency Graph

hashtagSupporting Files

hashtagDeploy

hashtagDebugging Dependency Issues

hashtagEnable Debug Logging

hashtagAnalyze Dependency Graph

hashtagList Resource Dependencies

hashtagTrace Execution Order

hashtagCircular Dependencies

hashtagExample of Circular Dependency

hashtagBreaking Circular Dependencies

hashtagParallel Resource Creation

hashtagDefault Parallelism

hashtagAdjust Parallelism

hashtagWhat Can Run in Parallel?

hashtagBest Practices

hashtag1. Prefer Implicit Dependencies

hashtag2. Use depends_on Sparingly

hashtag3. Document Dependencies

hashtag4. Avoid Circular Dependencies

hashtag5. Use Data Sources for External Resources

hashtag6. Visualize Dependencies

Table of Contents

Introduction: The Circular Dependency Nightmare

What Are Dependencies?

Simple Example

The Dependency Challenge

Dependency Types

Implicit Dependencies

Basic Implicit Dependency

Multiple Implicit Dependencies

Chained Dependencies

Module Output Dependencies

Explicit Dependencies

When Implicit Isn't Enough

The depends_on Meta-Argument

Basic Usage

Multiple Dependencies

Module Dependencies

depends_on with count/for_each

When to Use depends_on

Understanding Data Sources

Resource vs Data Source

Why Data Sources?

Data Source Benefits

Using Data Sources

Local File Data Source

Template File Data Source

External Data Source

HTTP Data Source

Data Source with Dependencies

Remote State Data Sources

Why Remote State Data Sources?

Remote State with S3 Backend

Remote State Best Practices

Dependency Graph

Visualizing Dependencies

Simple Graph Example

Complex Graph

Analyzing the Graph

Lifecycle Meta-Arguments and Dependencies

create_before_destroy

prevent_destroy

ignore_changes

replace_triggered_by

Module Dependencies

Implicit Module Dependencies

Explicit Module Dependencies

Module Output Dependencies

Common Dependency Patterns

Pattern 1: Sequential Creation

Pattern 2: Fan-Out

Pattern 3: Fan-In

Pattern 4: Diamond Dependency

Real-World Example: Multi-Tier Application with Dependencies

Project Structure

Database Module

Application Module

Monitoring Module

Root Module

Dependency Graph

Supporting Files

Deploy

Debugging Dependency Issues

Enable Debug Logging

Analyze Dependency Graph

List Resource Dependencies

Trace Execution Order

Circular Dependencies

Example of Circular Dependency

Breaking Circular Dependencies

Parallel Resource Creation

Default Parallelism

Adjust Parallelism

What Can Run in Parallel?

Best Practices

1. Prefer Implicit Dependencies

2. Use depends_on Sparingly

3. Document Dependencies

4. Avoid Circular Dependencies

5. Use Data Sources for External Resources

6. Visualize Dependencies