Paul is a VP of Technology. He comes from the Microsoft ecosystem, where his focus has been building Web and Windows applications on SQL Server and the .NET Framework stack. He has recently begun a deep dive into AWS, Azure, Docker, Kubernetes, and other DevOps technologies. 

All posts by Paul Delcogliano - DevOps Expert

Paul Delcogliano

Author title

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

AWS: Spacelift Reduces Time Spent on Cloud Management by 90% 🚀

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

Want to level up your Terraform knowledge? Explore our tutorials and step-by-step guides written by Terraform experts. Learn Terraform best practices and solutions to the most difficult problems.

Terraform Guides and Tutorials | Spacelift Blog

Terraform

In this article, you will learn why and how to use Terraform&#8217;s <code>depends_on</code> meta-argument.

Terraform uses resource dependencies to create and destroy resources in the correct order. <a href="https://developer.hashicorp.com/terraform/language/expressions/references" target="_blank" rel="nofollow noopener">Expression references</a> create implicit dependencies between one resource and another resource.
The following shows an implicit dependency created between two Azure resources using an expression reference.

In this example, an implicit dependency is created because the VNet&#8217;s <code>resource_group_name</code> attribute references the name of the resource group.
The object with the dependency, the VNet, is referred to as the &#8220;object declaring the dependency.&#8221; The resource group is referred to as the &#8220;dependency object.&#8221;
Terraform completes all actions on the dependency object first, then performs actions on the object declaring the dependency.

In most scenarios, Terraform automatically determines dependencies between resources based on expressions within a resource block. 
There are rare scenarios, however, where Terraform cannot infer dependencies between resources. In these cases, you will need to create an explicit dependency. This is the purpose of the Terraform <code>depends_on</code> meta-argument.
<code>depends_on</code> allows you to create an explicit dependency between two resources.
Dependencies are not limited to just resources. They can be created between modules. When the dependency is a <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">module</a>, <code>depends_on</code> affects the order in which Terraform processes all the resources and data sources associated with that module.
Both implicit and explicit dependencies affect the order in which resources are <a href="https://spacelift.io/blog/how-to-destroy-terraform-resources" target="_blank" rel="noopener">destroyed</a> as well as created. Explicit dependencies are only necessary when a resource or module relies on another resource&#8217;s behavior but does not access any of that resource&#8217;s data in its arguments.
There are some things you should consider when using Terraform <code>depends_on</code>:
<ul>
<li>Always include a comment to explain why using <code>depends_on</code> is necessary.</li>
<li><code>depends_on</code> causes Terraform to create a more conservative plan. The plan may modify more resources than necessary. For example, there may be more values as unknown &#8220;(known after apply).&#8221; This is more likely to occur when creating explicit dependencies between modules.</li>
<li>Adding explicit dependencies can increase the length of time it takes to build your infrastructure. Terraform must wait until the dependency object is created before continuing.</li>
<li>It is recommended to use expression references to create implicit dependencies whenever possible.</li>
</ul>

Some scenarios that may require the use of an explicit dependency include running a SQL script after a DB is created, deploying containers only after the container registry is created, or you have an application running on a VM instance that expects to use a specific Azure Storage Container.
This dependency is not visible to Terraform since the application’s architecture controls it. The following snippet demonstrates an explicit dependency between a VM and a storage container.

<h3>Adding Multiple Dependency Objects</h3>
Multiple dependencies can be passed to the <code>depends_on</code> argument using a comma-separated list of resources. 
Note: Adding explicit dependencies can increase the length of time it takes to create your infrastructure because Terraform will wait to create the dependent resource until after the specified resource is created.
The following snippet expands on the example from above and adds a second dependency, an Azure SQL Server, to the VM. This example is for illustration purposes and does not represent the best use case for creating an explicit dependency to multiple resources.
&nbsp;

<h3>How to use <code>depends_on</code> for modules in Terraform</h3>
As mentioned above, resources can have explicit dependencies on modules and vice-versa. This next example uses a module from the Terraform registry to create a VM. The module will be dependent upon the successful creation of the storage account.

Here&#8217;s an example of the same two resources with the dependency reversed. In this example, the storage account resource is dependent upon the VM module. Note the use of the <code>module</code> keyword in the dependency resource.

Understanding how Terraform uses implicit and explicit dependencies helps you to determine when and how to use the <code>depends_on</code> meta-argument. When necessary, <code>depends_on</code> instructs Terraform to create and destroy resources in the correct order. Misusing the argument can lead to potentially confusing, poor-performing code.
If you need any help <a href="https://docs.spacelift.io/" target="_blank" rel="noopener">managing your Terraform infrastructure</a>, building more complex workflows based on Terraform, and managing AWS credentials per run, instead of using a static pair on your local machine, Spacelift is a fantastic tool for this. It supports Git workflows, policy as code, programmatic configuration, context sharing, drift detection, and many more great <a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">features right out of the box</a>. You can check it for free by <a href="https://spacelift.io/free-trial?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bterraform_depends_on%7D" target="_blank" rel="noopener">creating a trial account</a>.

Spacelift effectively manages Terraform state, more complex workflows, supports policy as code, programmatic configuration, context sharing, drift detection, resource visualization and includes many more features.

The Lifecycle of a Terraform Resource: Lifecycle Meta-Argument

How to Use Terraform Join and Split Functions with Strings

5 Ways to Manage Terraform at Scale - Best Practices

Understanding how Terraform uses implicit and explicit dependencies helps you to determine when and how to use the depends_on meta-argument.

120-terraform-depends-on

terraform depends_on

How to Use Terraform depends_on Meta-Argument

Infrastructure as Code (IaC) is a key attribute of enabling best practices in any organization practicing a DevOps culture. The ability to build up and tear down infrastructure via code has many benefits, like reducing cost, increasing deployment speed, and lowering risk through consistency. There is, however, a dark side to IaC. If not used cautiously and carefully, it is way too easy to cause harm to an environment.

Applying infrastructure changes haphazardly can lead to unwanted changes to your environment. The Terraform <a href="https://www.terraform.io/cli/commands/plan" target="_blank" rel="nofollow noopener"><code>plan</code></a> command is available to bring visibility to your IaC deployments. The <code>plan</code> command reports on changes to infrastructure, but it does not apply any of the proposed changes. Instead, it creates a reviewable execution plan, which you can use to confirm that the proposed changes are expected.
The execution plan can be saved to a file, which can be applied later, or peer-reviewed to enforce quality control. The ability to review the proposed changes prior to applying them can save you from making unexpected infrastructure changes. After you have confirmed the changes as expected, use the Terraform <a href="https://spacelift.io/blog/terraform-apply" target="_blank" rel="noopener"><code>apply</code></a> command to update the remote objects.
The <code>plan</code> command does three things:
<ul>
<li>Ensures the state is up to date by reading the current state of any already-existing remote infrastructure.</li>
<li>Determines the deltas between the current configuration and the prior state data.</li>
<li>Proposes a series of changes that will make the remote infrastructure match the current configuration.</li>
</ul>
If there aren&#8217;t any deltas, the output will report that no actions need to be taken.

Let&#8217;s look at the output resulting from executing <code>plan</code> with a simple Terraform configuration script. For this walkthrough, we&#8217;ll use a new Azure subscription that does not contain any resources. The listing for the configuration script is below.

Run the following command on the command line to generate an execution plan.
Before doing so, be sure to set environment variables for your Azure Subscription Id and Tenant Id, using the subscription id and tenant id from your Azure subscription, respectively. For more details on the different ways, you can configure the AzureRM Terraform provider, <a href="https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs" target="_blank" rel="nofollow noopener">see here</a>.

tf_plan_initial_output_1

Terraform plan - initial output

The output contains a wealth of information, which is highlighted in the image above. Terraform proposed a create action, as indicated by the green plus sign. Changes and deletions appear as yellow tilda and red minus sign, respectively. Terraform is also proposing to create a new resource group named &#8220;rg-tf-plan-example-centralus.&#8221; The execution plan includes a summary count of each action in the proposal. In this case, there is one add, zero change, and zero destroy, actions.
Apply the proposed changes by running the <code>apply</code> command (make sure you confirm the actions by typing <code>yes</code> when prompted):

In addition to creating the resource group, Terraform also updated the local <a href="https://spacelift.io/blog/terraform-state" target="_blank" rel="noopener">state</a> data. Terraform uses state data to remember the remote infrastructure configurations and create deltas when configurations change.
Make the following change to the sample Terraform script. Add the following line to the end of the script, just before the closing curly brace:

The resource group resource should now look like this:

Re-run the <code>plan</code> command:

When the <code>plan</code> command executed, Terraform compared the stored state data for the rg-tf-plan-example-centralus resource to the changes made in the configuration script.

terraform-plan-delta

terraform plan delta output

Looking at the output, you can see Terraform determined an update was necessary. The output also shows the proposed changes, including the actual change itself: the addition of the <code>name</code> tag.
It&#8217;s also worth mentioning that with <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">Spacelift you can use plan policies</a> to make automated decisions based on Terraform plans. Plan policies are evaluated during a planning phase after a vendor-specific change preview command (e.g. <code>terraform plan</code>) executes successfully. The body of the change is exported to JSON, and parts of it are combined with Spacelift metadata to form the data input to the policy.

The <code>plan</code> command can be run in three different modes, normal, which is the default and the mode we&#8217;ve used so far, destroy, and refresh-only. The modes are mutually exclusive. You cannot use more than one mode at a time.
Destroy mode creates a plan which shows you all the remote objects that will be removed. Running the command in destroy mode does not actually perform any actions. A great use case for destroy mode is to delete a temporary development environment.
You activate destroy mode by including the <code>-destroy</code> option on the command line:

terraform-plan-destroy

terraform plan destroy output

There are times when you will intentionally change remote objects without the use of a Terraform script, i.e., directly via the Azure CLI. This can be necessary when troubleshooting a problem in the remote environment. In these cases, the state data will not match the remote object configuration and will need to be reconciled.
Executing <code>plan</code> in refresh-only mode creates a plan with the goal of showing you the deltas between the state data and the remote objects. You can activate refresh-only mode by including the <code>-refresh-only</code> option on the command line.
Note: the <code>-refresh-only</code> option is available only in Terraform v0.15.4 and later.

terraform-plan-refresh-output

terraform plan refresh output

In addition to the alternate <code>plan</code> modes described above, there are a couple of other categories of options available, those affecting behavior and those affecting outputs.
<h3>Options Affecting How the Plan Command Behaves</h3>
Options that modify the <code>plan</code> command&#8217;s behavior are listed below.
<table>
<tbody>
<tr>
<td>Option</td>
<td>Description</td>
</tr>
<tr>
<td><code>-refresh=false</code>
&nbsp;</td>
<td>Ignores external changes to remote objects, i.e., those made via the CLI. This option will not sync the state data with the remote objects before checking for configuration changes. While this improves performance by making less remote API requests, ignoring external changes could result in incomplete or incorrect plans.
&nbsp;</td>
</tr>
<tr>
<td><code>-replace=ADDRESS</code>
&nbsp;</td>
<td>Forces the replacement of the resource instead of an update action or no change at all. This will replace the resource at the given address. It can be applied multiple times to replace many objects at once.
&nbsp;</td>
</tr>
<tr>
<td><code>-var 'NAME=VALUE'</code>
&nbsp;</td>
<td>Applies a value for an input variable. It can be applied multiple times, once per variable.
Note: Errors will occur if a space appears before or after the equals sign (e.g., <code>-var "region = centralus"</code>).
&nbsp;</td>
</tr>
<tr>
<td><code>-var-file=FILENAME</code>
&nbsp;</td>
<td>Applies values for one or more input variables as defined in a <a href="https://spacelift.io/blog/terraform-tfvars" target="_blank" rel="noopener">&#8220;tfvars&#8221; file</a>. It can be used multiple times, once for each &#8220;tfvars&#8221; file.
&nbsp;</td>
</tr>
<tr>
<td><code>-lock-timeout=DURATION</code></td>
<td>Instructs Terraform to retry acquiring a lock for a period of time before returning an error. The duration value must be entered using the format nt where n is a number and t is a letter representing a unit of time, e.g., 3m is 3 minutes.
&nbsp;</td>
</tr>
</tbody>
</table>
Let&#8217;s turn the resource group&#8217;s location attribute into a variable. This adds flexibility and reusability to the script, allowing us to specify the location value at runtime. Modify the sample script as follows.
Add a variable to the sample script named &#8220;region&#8221; just before the provider section and modify the azurerm_resource_group resource so the value for the location attribute comes from a variable.
Note: for simplicity, we are using one &#8220;.tf&#8221; file to define the resources and the variables. In practice, variables are declared in a separate file, typically named &#8220;variables.tf&#8221;. The script below shows the result of making this change.

The &#8220;region&#8221; variable is declared as a string.
Re-run the Terraform <code>plan</code> command. This time you will be prompted for the location in Azure where the resource group resides.

terraform-variable-prompt

terraform variable prompt

Run the <code>plan</code> command again. This time, use the -var option to provide a value for region on the command line and notice that you are no longer prompted to supply a value for the variable.

<h3>Options Related to Formatting and Output</h3>
There will be use cases where you will need to change the <code>plan</code> command&#8217;s output. The following options are available for those use-cases:
<table>
<tbody>
<tr>
<td>Option</td>
<td>Description</td>
</tr>
<tr>
<td><code>-compact-warnings</code>
&nbsp;</td>
<td>Shows warnings as a summary unless the warnings include errors. If there are errors, the text will include useful information for troubleshooting.
&nbsp;</td>
</tr>
<tr>
<td><code>-input=false</code>
&nbsp;</td>
<td>Disables prompts for input variables. that have not otherwise been assigned a value. This option is useful when automating Terraform scripts, like when run in a <a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener">CI/CD pipeline</a>.
&nbsp;</td>
</tr>
<tr>
<td><code>-json</code>
&nbsp;</td>
<td>Returns output in JSON format.
&nbsp;</td>
</tr>
<tr>
<td><code>-no-color</code>
&nbsp;</td>
<td>Removes color from the output.
&nbsp;</td>
</tr>
<tr>
<td><code>-out=FILENAME</code></td>
<td>Saves the plan to a file that can be passed to the Terraform <code>apply</code> command to execute the planned changes. Any filename is allowed, but the recommended naming convention is to name it &#8220;tfplan.&#8221; Do not use the &#8220;.tf&#8221; suffix, as this will lead Terraform to interpret the file as a configuration script and will fail.
Note: the file contains all the values associated with planned changes, including any sensitive data, in cleartext in the plan file. For this reason, you must consider impacts on security when saving plans to a file.
&nbsp;</td>
</tr>
<tr>
<td><code>-parallelism=n</code></td>
<td>By default, Terraform will run 10 operations concurrently, where possible. This option limits the number of concurrent operations to n.
&nbsp;</td>
</tr>
<tr>
<td><code>-detailed-exitcode</code></td>
<td>Includes detailed exit codes, which provide more granular information about the resulting plan. The list of codes is:
&#8211; 0 = Succeeded with empty diff (no changes) 
&#8211; 1 = Error 
&#8211; 2 = Succeeded with non-empty diff (changes present)
&nbsp;</td>
</tr>
</tbody>
</table>

Resource targeting is like the -replace=ADDRESS option in that it tells Terraform to focus the plan only on resources that match the given address. Resource targeting includes all other objects that the selected resource(s) depend on, either directly or indirectly.
You can target resources using the -target=ADDRESS option.
Note: It is not recommended to use -target under normal circumstances.
Terraform enforces this point by including a warning message in the output. Run the following command to see the warning message embedded in the output:

terraform-plan-target-warning

terraform plan target warning

Instead of using -target, split large configurations into several smaller configurations that can each be applied independently. Doing so allows a complicated configuration to be separated into more manageable parts.

The <code>plan</code> command is very powerful despite not actually modifying any resources. Saving plans to output files enables automation and peer review. Supplying variable values on the command line or in files eliminates the need to hard code values, some of which may be sensitive. Using <code>plan</code> to show deltas between state data and remote configurations can help illuminate changes made directly to remote objects, which may need to be refreshed.
With <a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a>, once the workspace is prepared by the <a href="https://docs.spacelift.io/concepts/run/#initializing" target="_blank" rel="noopener">Initializing</a> phase, planning runs a vendor-specific preview command, in this case, <code>terraform plan</code>, and interprets the results. The result of the planning phase is the collection of currently managed resources and outputs as well as planned changes. This is used as an input to <a href="https://docs.spacelift.io/concepts/run/proposed#plan-policies" target="_blank" rel="noopener">plan policies</a> (optional) and to <a href="https://docs.spacelift.io/concepts/run/proposed#delta" target="_blank" rel="noopener">calculate the delta</a> &#8211; always. If you’re interested in finding out more about how to use Spacelift to manage and automate your Terraform deployments check out our <a href="https://docs.spacelift.io/vendors/terraform/" target="_blank" rel="noopener">Terraform documentation</a>.
You should plan to run the <code>plan</code> command prior to applying your changes. This will help you avoid late-night troubleshooting sessions for changes that have gone awry. Remember, failing to plan is planning to fail.

If you are struggling with Terraform automation and management, check out Spacelift. It helps you manage Terraform state, build more complex workflows, and adds several must-have capabilities for end-to-end infrastructure management.

Terraform Cheat Sheet - 21 Terraform CLI Commands & Examples

How to Debug & Troubleshoot Terraform Projects: Tutorial

The Terraform plan command is very powerful despite not actually modifying any resources. Take a look at the usage examples and planning options.

110-terraform_plan

Terraform plan command

Terraform Plan Command - Check Your IaC Deployment 

Practice DRY in Terraform Configurations Using `dynamic` Blocks

The Don&#8217;t Repeat Yourself (DRY) principle of software development states that code should be written once and not repeated. An important goal of the DRY principle is to improve the maintainability of code.
See how you can <a href="https://spacelift.io/blog/terragrunt-with-spacelift" target="_blank" rel="noopener">keep your configuration DRY with Terragrunt on Spacelift</a>.
Some Terraform resources include repeatable nested blocks in their arguments. These nested blocks represent separate resources that are related to the containing resource. For example, Azure VNets contain a subnet block attribute that repeats for each subnet within the VNet. This can lead to repeated configuration blocks in a Terraform script, which violates the DRY principle.
Dynamic blocks are a solution for applying DRY in Terraform configuration scripts.

Terraform provides the <code>dynamic</code> block to create repeatable nested blocks within a resource. A <code>dynamic</code> block is similar to the <code>for</code> expression. Where <code>for</code> creates repeatable top-level resources, like VNets, <code>dynamic</code> creates nested blocks within a top-level resource, like subnets within a VNet. A <code>dynamic</code> block iterates over a child resource and generates a nested block for each element of that resource.
<h3>Example</h3>
The following code shows the configuration of an Azure VNet and four subnets. In this example, the subnet blocks are written out explicitly, creating repeated code.

That same configuration using a <code>dynamic</code> block is shown below. Replacing the four <code>subnet</code> blocks with a <code>dynamic</code> block removes repeated attributes, leading to cleaner code that is easier to maintain.

Here is the definition of the variable subnets:

The values for the subnets variable are defined in a <a href="https://spacelift.io/blog/terraform-tfvars" target="_blank" rel="noopener">tfvars file</a>. Sample values are:

<code>dynamic</code> blocks are supported inside of <code>resource</code>, <code>data</code>, <code>provider</code>, and <code>provisioner</code> blocks. A <code>dynamic</code> block consists of the following components:
<table>
<tbody>
<tr>
<td>Component</td>
<td>Description</td>
</tr>
<tr>
<td>label
&nbsp;</td>
<td>Specifies what kind of nested block to generate. In the above example, the label is &#8220;subnet&#8221;. A subnet resource will be generated for each element in the <code>var.subnets</code> variable.
&nbsp;</td>
</tr>
<tr>
<td>for_each
&nbsp;</td>
<td>The complex value to iterate over.
&nbsp;</td>
</tr>
<tr>
<td>iterator
&nbsp;</td>
<td>(optional) Sets the name of a temporary variable that represents the current element. If not provided, the name of the variable defaults to the label of the dynamic block. An iterator has two attributes: key and value. Key is the element index. Value is the element value.
&nbsp;</td>
</tr>
<tr>
<td>content
&nbsp;</td>
<td>Defines the body of each generated block.
&nbsp;</td>
</tr>
</tbody>
</table>

A <code>dynamic</code> block can only generate attributes that belong to the resource type being created. It isn&#8217;t possible to generate meta-argument blocks like <code>lifecycle</code>. Some resource types have blocks with multiple levels of nesting.
When working with multi-level nested blocks, the iterators for each block are important. It is recommended to use the optional <code>iterator</code> component to clearly define each level in the configuration, and to remove any ambiguities resulting from attributes with the same name as a parent block.
The listing below illustrates a nested block example, with clearly defined iterators for each block.

A <code>dynamic</code> block is a great way to apply the DRY principle in Terraform configuration scripts. Implementing a <code>dynamic</code> block where appropriate removes repeated code leading to configurations that are easier to read, maintain, and reuse &#8211; just as the DRY principle aims to do.
You can also check out <a href="https://docs.spacelift.io/" target="_blank" rel="noopener">how Spacelift makes it easy to work with Terraform</a>.  It brings with it a GitOps flow, so your infrastructure repository is synced with your Terraform Stacks, and pull requests show you a preview of what they&#8217;re planning to change. It also has an extensive selection of <a href="https://docs.spacelift.io/concepts/policy/">policies</a>, which lets you <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy">automate compliance checks</a> and <a href="https://docs.spacelift.io/concepts/policy/trigger-policy">build complex multi-stack workflows</a>. You can test drive it for free by creating a <a href="https://spacelift.io/free-trial?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bterraform_dynamic_blocks%7D" target="_blank" rel="noopener">trial account</a>.

12 Terraform Best Practices to Improve your TF workflow

Terraform Count vs. For Each Meta-Argument - When to Use It

Learn what Terraform Dynamic Blocks are, what are their components and how to use them for applying the DRY principle.

Paul Delcogliano

How to Use Terraform depends_on Meta-Argument

Get the newsletter

Recent posts

Terraform Plan Command – Check Your IaC Deployment

Practice DRY in Terraform Configurations Using Dynamic Blocks