The combination of meta-argument depends_on with Data Resources

Avatar
Patrick Munne
  • Updated

Introduction

Terraform uses the depends_on meta-argument to handle hidden resource or module dependencies that it cannot automatically infer. This argument instructs Terraform to complete all actions on a dependency object, including read actions, before performing actions on the object declaring the dependency.

When you use depends_on with a data source, it can lead to unexpected behavior. If a resource that a data source depends_on changes, Terraform marks the data source to be read during the apply phase. Terraform does this because it cannot know the outcome of the resource change on the data source's values until after the change is applied. This can affect other resources that consume the data source's output.

This guide demonstrates two scenarios where using depends_on with a data source can produce an unexpected plan. The examples use the tfcoremock provider to simulate real-world resources and can be executed in any environment.

Prerequisites

Scenario 1: Unexpected Plan to Update a Resource

This scenario demonstrates how depends_on can cause Terraform to propose an update to a resource in the plan phase that does not occur during the apply phase.

Procedure

  1. Create a directory named example1.

  2. Inside this directory, create a file named main.tf with the following content. This configuration defines a resource hero1, a data source heroes that depends on it, and a resource hero2 that uses the data source's output.

    terraform {
  required_providers {
    tfcoremock = {
      source  = "hashicorp/tfcoremock"
      version = "0.2.0"
    }
  }
}

provider "tfcoremock" {}

resource "tfcoremock_simple_resource" "hero1" {
  string = "Wonder Woman"
}

data "tfcoremock_simple_resource" "heroes" {
  id = "heroes_data"
  depends_on = [
    tfcoremock_simple_resource.hero1
  ]
}

resource "tfcoremock_simple_resource" "hero2" {
  string = data.tfcoremock_simple_resource.heroes.string
}
  3. Create a subdirectory named terraform.data.

  4. Inside terraform.data, create a file named heroes_data.json with the following content. This file provides the static data for the heroes data source.

    {
  "values": {
    "string": {
      "string": "Batman"
    }
  }
}

  5. Confirm your directory structure matches the following.

    .
├── main.tf
└── terraform.data
    └── heroes_data.json

  6. Initialize the configuration.

    $ terraform init

  7. Apply the configuration to create the resources.

    $ terraform apply

    The output shows two resources created.

    tfcoremock_simple_resource.hero1: Creating...
tfcoremock_simple_resource.hero1: Creation complete after 0s [id=...]
data.tfcoremock_simple_resource.heroes: Reading...
data.tfcoremock_simple_resource.heroes: Read complete after 0s
tfcoremock_simple_resource.hero2: Creating...
tfcoremock_simple_resource.hero2: Creation complete after 0s [id=...]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

  8. Modify main.tf to change the value of hero1 to Superman.

    resource "tfcoremock_simple_resource" "hero1" {
  string = "Superman"
}

  9. Run terraform plan. Notice that the plan proposes changes to both hero1 and hero2. Because hero2 uses the data source output and the data source depends_on a changed resource, Terraform marks its value as (known after apply).

    $ terraform plan

    The output shows a plan to change two resources.

    ## data.tfcoremock_simple_resource.heroes will be read during apply
## (depends on a resource or a module with changes pending)
<= data "tfcoremock_simple_resource" "heroes" {
      + bool    = (known after apply)
      + float   = (known after apply)
      + id      = "heroes_data"
      + integer = (known after apply)
      + number  = (known after apply)
      + string  = (known after apply)
    }

# tfcoremock_simple_resource.hero1 will be updated in-place
  ~ resource "tfcoremock_simple_resource" "hero1" {
        id     = "..."
      ~ string = "Wonder Woman" -> "Superman"
    }

# tfcoremock_simple_resource.hero2 will be updated in-place
  ~ resource "tfcoremock_simple_resource" "hero2" {
        id     = "..."
      ~ string = "Batman" -> (known after apply)
    }

Plan: 0 to add, 2 to change, 0 to destroy.

  10. Run terraform apply. Notice that only hero1 is modified. During the apply phase, Terraform re-reads the heroes data source and finds its value (Batman) has not changed, so no update to hero2 is necessary.

    $ terraform apply

    The output shows only one resource was changed.

    tfcoremock_simple_resource.hero1: Modifying... [id=...]
tfcoremock_simple_resource.hero1: Modifications complete after 0s [id=...]
data.tfcoremock_simple_resource.heroes: Reading...
data.tfcoremock_simple_resource.heroes: Read complete after 0s

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Scenario 2: Unexpected Plan to Replace a Resource

This scenario demonstrates how depends_on can cause Terraform to plan to destroy and re-create a resource, even when the underlying data does not change.

Procedure

  1. Create a directory named example2.

  2. Inside this directory, create a file named main.tf with the following content. This configuration is similar to the first, but it uses the data source output to set the id attribute of hero2.

    terraform {
  required_providers {
    tfcoremock = {
      source  = "hashicorp/tfcoremock"
      version = "0.2.0"
    }
  }
}

provider "tfcoremock" {}

resource "tfcoremock_simple_resource" "hero1" {
  string = "Wonder Woman"
}

data "tfcoremock_simple_resource" "heroes" {
  id = "heroes_data"
  depends_on = [
    tfcoremock_simple_resource.hero1
  ]
}

resource "tfcoremock_simple_resource" "hero2" {
  id = data.tfcoremock_simple_resource.heroes.string
}
  3. Follow steps 3-7 from Scenario 1 to create the terraform.data/heroes_data.json file and apply the configuration.

  4. Modify main.tf to change the value of hero1 to Superman.

    resource "tfcoremock_simple_resource" "hero1" {
  string = "Superman"
}

  5. Run terraform plan. Because the id attribute of hero2 is derived from the data source, and the data source's value is (known after apply), Terraform determines that hero2 must be replaced.

    $ terraform plan

    The output shows a plan to replace hero2.

    ## ... (output for data source and hero1) ...

# tfcoremock_simple_resource.hero2 must be replaced
-/+ resource "tfcoremock_simple_resource" "hero2" {
      ~ id = "Batman" -> (known after apply) # forces replacement
    }

Plan: 1 to add, 1 to change, 1 to destroy.

  6. Run terraform apply. Terraform destroys hero2 before it re-reads the data source. After re-reading the data and confirming the value is still Batman, it re-creates hero2 with the same ID.

    $ terraform apply

    The output shows the resource was destroyed and re-created.

    tfcoremock_simple_resource.hero2: Destroying... [id=Batman]
tfcoremock_simple_resource.hero2: Destruction complete after 0s
tfcoremock_simple_resource.hero1: Modifying... [id=...]
tfcoremock_simple_resource.hero1: Modifications complete after 0s [id=...]
data.tfcoremock_simple_resource.heroes: Reading...
data.tfcoremock_simple_resource.heroes: Read complete after 0s
tfcoremock_simple_resource.hero2: Creating...
tfcoremock_simple_resource.hero2: Creation complete after 0s [id=Batman]

Apply complete! Resources: 1 added, 1 changed, 1 destroyed.

Recommendation

In both scenarios, removing the depends_on meta-argument from the data source results in a more predictable plan. When a resource depends on the output of a data source, Terraform can infer the dependency automatically. Avoid using depends_on with data sources unless it is necessary to manage a hidden dependency that Terraform cannot detect, such as a dependency on a resource that modifies a file read by the local_file data source.

Additional Information

Articles in this section

See more

Related articles