Controlling Resource Order with Explicit Dependencies

depends_on is a Terraform meta-argument that creates explicit ordering between resources. Terraform usually determines ordering automatically via implicit dependencies when one resource references another’s attributes. For example, a subnet that references a VPC ID creates an implicit dependency and Terraform ensures the VPC is created first. But when Terraform cannot infer the relationship from resource attributes — for instance, when one resource must be fully ready before another starts — you should use depends_on to enforce ordering and prevent race conditions. Key benefits of depends_on:

Forces a specific creation order in Terraform plans and applies.
Prevents race conditions when resources must be fully provisioned before others start.
Ensures downstream resources that perform startup actions (migrations, initializations) have their upstream dependencies available.
Use sparingly — prefer implicit dependencies where possible to retain parallelism and faster provisioning.

A purple presentation slide titled "depends-on Meta-Argument" about ensuring resources are created in the right order with Terraform. It lists tips like explicitly defining dependencies, ensuring correct provisioning order, and preventing race conditions.

Example: RDS database and EC2 web server

Without depends_on, Terraform may create both resources in parallel. If the web server expects the database to be available and initialized at startup (beyond just knowing its ID), you should enforce order with depends_on.

resource "aws_db_instance" "db" {
  identifier          = "mydb"
  engine              = "mysql"
  instance_class      = "db.t3.micro"
  allocated_storage   = 20
  username            = "admin"
  password            = "SuperSecurePassword123!"
  skip_final_snapshot = true
}

resource "aws_instance" "app_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t2.micro"

  # Ensure the EC2 instance is created only after the DB instance exists.
  depends_on = [aws_db_instance.db]
}

This depends_on prevents Terraform from creating the EC2 instance until the database resource has been created. Use this pattern when the application will try to connect or run migrations at startup and requires the database to be fully provisioned.

Prefer implicit dependencies (resource attribute references) when possible. Overusing depends_on serializes execution and reduces Terraform’s ability to parallelize resource creation.

Implicit vs explicit dependencies — clarification and examples

Implicit dependency: Terraform infers ordering from attribute references between resources.
Explicit dependency: You use depends_on when no attribute reference exists that would create the dependency automatically, but you still require a specific order.

Implicit dependency example (security group referenced by EC2 instance)

resource "aws_security_group" "web" {
  name = "web-sg"
}

resource "aws_instance" "app" {
  ami                   = "ami-12345"
  instance_type         = "t2.micro"
  vpc_security_group_ids = [aws_security_group.web.id]  # Implicit dependency on aws_security_group.web
}

In this example, Terraform automatically orders creation so the security group exists before the instance. Explicit dependency example (Lambda function depending on a policy attachment that isn’t referenced)

resource "aws_iam_role" "lambda" {
  name = "lambda-role"
  # role configuration...
}

# Assume this resource exists elsewhere in your configuration and attaches a policy to the role.
resource "aws_lambda_function" "app" {
  function_name = "my-function"
  role          = aws_iam_role.lambda.arn

  # The function needs the policy attachment to exist first, but we do not reference its attributes here.
  depends_on = [aws_iam_role_policy_attachment.lambda_logs]
}

Here, because the Lambda function does not reference attributes from the policy attachment resource, Terraform would not infer the dependency. depends_on explicitly enforces the order.

Only use depends_on when necessary. If an attribute reference already expresses the dependency, prefer that implicit dependency. Misusing depends_on can hide configuration issues and slow down apply operations.

When to use depends_on — quick reference table

Use case	Best practice
Resource attributes reference other resources (e.g., `vpc_security_group_ids = [aws_security_group.web.id]`)	Use implicit dependency; no `depends_on` needed
A resource must be fully ready before another starts but no attribute reference exists	Use `depends_on` to enforce ordering (e.g., DB ready before app server performing migrations)
Resource relationship exists but is represented outside Terraform or via side-effects	Use `depends_on` combined with proper provisioning checks or external data sources

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules

Managing Resource Behavior and Dependencies

Securing Terraform Configurations

Terraform Troubleshooting

HCP Terraform

Controlling Resource Order with Explicit Dependencies

Watch Video

Practice Lab