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

Spacelift's going to AWS re:Invent in Las Vegas 🚀 🚀

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

Introducing Stack Dependencies v.2  🎉 🎉

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

Cloud-native applications embrace the widely accepted practice of Infrastructure as Code, or IaC. IaC applies software development practices to the management of infrastructure, i.e., networks, virtual machines, load balancers, etc. 
Applying software development techniques to managing infrastructure provides several benefits, including versioning using a repository like GitHub and streamlining provisioning and maintenance by creating repeatable processes. Code reviews and audits can be done to ensure changes to infrastructure are correct and won&#8217;t introduce errors. 
With IaC, infrastructure becomes reproducible in a consistent manner and can be included in a CI/CD deployment pipeline. IaC is scalable and helps to eliminate human error.
Many <a href="https://spacelift.io/blog/infrastructure-as-code-tools" target="_blank" rel="noopener">IaC tools</a> are available to facilitate the provisioning of cloud-native applications across all the major cloud platforms. Terraform and Pulumi are two such tools. In this article, we&#8217;ll take a look at both and provide a comparison between them.
We will cover:
<ol>
<li><a href="https://spacelift.io/blog/pulumi-vs-terraform#what-is-terraform">What is Terraform</a></li>
<li><a href="https://spacelift.io/blog/pulumi-vs-terraform#what-is-pulumi">What is Pulumi</a></li>
<li><a href="https://spacelift.io/blog/pulumi-vs-terraform#feature-comparison-between-pulumi-and-terraform">Feature comparison with examples</a></li>
<li><a href="https://spacelift.io/blog/pulumi-vs-terraform#terraform-or-pulumi-which-is-better">Terraform or Pulumi: which is better?</a></li>
</ol>

<a href="https://www.terraform.io" target="_blank" rel="nofollow noopener">Terraform</a>, is an open-source tool created by Hashicorp. It is probably the most well-known IaC infrastructure provisioning tool. Terraform is cloud-agnostic and allows automating infrastructure stacks from multiple cloud service providers simultaneously. Terraform uses its own domain-specific language called Hashicorp Configuration Language (HCL).
Terraform uses &#8220;plans&#8221; to validate the configuration and display exactly what elements are going to change before the changes are applied. For a detailed look at plans, check out our <a href="https://spacelift.io/blog/terraform-plan" target="_blank" rel="noopener">introduction to Terraform plan</a>.
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu is the future of the Terraform ecosystem, and having a truly open-source project to support all your IaC needs is the main priority.

<a href="https://www.pulumi.com" target="_blank" rel="nofollow noopener">Pulumi</a> is an IaC tool that uses a declarative format to deploy infrastructure. Like Terraform, it is open source on GitHub and is free to use. It offers the ability to use any major development language in the creation of infrastructure template files. Pulumi, like Terraform, supports all of the major cloud providers.
Read more in our <a href="https://spacelift.io/blog/what-is-pulumi" target="_blank" rel="noopener">Pulumi introduction</a>.

Pulumi and Terrafor are both software tools that automate the management of cloud computing infrastructure using code and templates. They help businesses provision and configure servers, storage, databases, and networks without manual intervention or hardware controls. 
They store the documented configurations in version control systems that ensure consistency and reduce turnaround time. They support DevOps and NetOps practices, enabling agility, scalability, and resilience. They can be cloud-specific or cloud-agnostic, depending on the provider and the environment. 
The following table lists the key differences between Pulumi and Terraform:

pulumi-vs-terraform-table-comparison

pulumi vs terraform table comparison

Let&#8217;s take a deeper look into each of the differences listed above with examples.
<h3>1. Language Support</h3>
Terraform&#8217;s HCL is JSON-compatible and is used to create the configuration files that describe the infrastructure resources in the stack. It uses proprietary syntax for common programming constructs like conditionals and loops. Terraform recently released the beta of a development kit that allows you to use programming languages that compile to HCL. 
Here&#8217;s a look at a typical Terraform configuration file created using HCL to provision an Azure Resource Group.

Pulumi supports familiar programming languages like TypeScript, JavaScript, Python, Go, and C#, among others. This flexibility allows you to write your templates in the language you are most comfortable with. Pulumi will also convert HCL configurations into Pulumi templates.
<a href="https://www.pulumi.com/docs/concepts/vs/terraform/terminology" target="_blank" rel="nofollow noopener">This reference</a> provides a document listing Terraform terminology and command equivalents in Pulumi. 
A Pulumi template file written in C# to create the same Resource Group in Azure looks like this:

<h3>2. IDE Features</h3>
Plugins for Terraform are available for some IDEs like VS Code. IDE integration is limited to the capabilities of the plugin itself. 
Pulumi&#8217;s support for common programming languages means you get the rich IDE integration that comes with the language you choose. For example, when using C#, Visual Studio provides code completion, strong data types, intellisense, etc.
<h3>3. Open Source Licenses</h3>
Terraform uses the <a href="https://www.mozilla.org/en-US/MPL/2.0/" target="_blank" rel="nofollow noopener">Mozilla Public License 2.0</a>. Pulumi uses the <a href="https://www.apache.org/licenses/LICENSE-2.0.html" target="_blank" rel="nofollow noopener">Apache License 2.0</a>. There are differences between each licensing model. Your use case will determine the license that is appropriate for you.
<h3>4. Testability</h3>
Pulumi&#8217;s support for common programming languages like C# allows you to perform unit tests on your IaC templates using .Net test tools like xUnit. Pulumi also provides the ability to perform tests that mock external calls.
Terraform supports <a href="https://spacelift.io/blog/terraform-test#integration-testing" target="_blank" rel="noopener">integration testing</a>. The <code>plan</code> command shows the proposed infrastructure changes before they are applied, allowing you to review the changes prior to their execution. There are also commands to validate and format a configuration file. 
Robust integration testing can be performed using third-party tools like <a href="https://spacelift.io/blog/what-is-terratest" target="_blank" rel="noopener">Terratest</a>, which is a Go library that enables you to write automated tests for infrastructure code. It provides many helper functions and patterns for common infrastructure testing tasks such as unit testing, integration testing, end-to-end testing, dependency injection, testing parallelism, retry logic, error handling, and static analysis.
<h3>5. Cloud Provider Support</h3>
A resource provider handles communications with a cloud service to manage the infrastructure resources defined in IaC configurations.
Both tools support all the major cloud services. Terraform has a community of developers writing custom providers for a myriad of services. Navigating their <a href="https://registry.terraform.io/browse/providers" target="_blank" rel="nofollow noopener">provider registry</a> you&#8217;ll find provider support for services like Ansible and Atlassian. New cloud services aren’t always available to deploy using Terraform on day one.
Pulumi supports over 60 of the major cloud services. They also create &#8220;Native&#8221; providers for AWS, Azure, Google, and Kubernetes, which receive same-day support with every new release. The <a href="https://www.pulumi.com/registry/" target="_blank" rel="nofollow noopener">Pulumi registry</a> provides detailed information for each provider they support. Also of note, Pulumi is able to adapt Terraform providers, so you can use the custom providers created by the Terraform community in your Pulumi templates.
<h3>6. State Management</h3>
IaC tools store metadata about your infrastructure so that it can manage your cloud resources. This metadata is called _state_. Both Terraform and Pulumi offer a desired state model where the code represents the desired infrastructure state, and the tool compares this desired state with the stack’s current state to determine the resources to be created, updated, or deleted.
By default, Terraform stores the state locally in a file named <a href="https://spacelift.io/blog/terraform-state" target="_blank" rel="noopener">terraform.tfstate</a>. Terraform state can be stored using a centrally located file, i.e., Azure blob container. This is the recommended configuration for the state file. Storing state in a centrally located file provides for backup and recovery scenarios and allows larger teams to collaborate and manage infrastructure with shared state.
In contrast, Pulumi stores its state in the Pulumi Cloud by default. Pulumi&#8217;s use of common development languages allows state to be compared as a &#8220;diff&#8221;, like how code is compared and reviewed across versions.
<h3>7. Secrets Management</h3>
The management of secrets, e.g., database credentials, API keys, etc., in code can become a security risk. 
Terraform manages secrets through a separate product named Vault. Vault enables the management secrets without the need for developers to have direct access to the secrets. Vault encrypts the values it stores. It can be deployed as a SaaS or run locally as a service. Variables marked as &#8220;secret&#8221; will be excluded from an output unless the <code>secrets</code> command line argument is provided.

It is important to note that Terraform state files store secrets in plain text. Because of this you should restrict access to the state file to only those with the appropriate level of authorization. A recommended best practice is to always encrypt your state file to prevent accidentally leaking sensitive information.
Learn more about <a href="https://spacelift.io/blog/terraform-secrets" target="_blank" rel="noopener">Terraform secrets management and best practices</a>.
As mentioned above, Pulumi stores secrets in state in the Pulumi Cloud. You can also choose your own provider to store your secrets. Pulumi always stores and transmits secrets securely. It also supports encrypting sensitive data for extra protection. Configuration settings can be encrypted via the CLI command <code>config set</code> with the <code>--secret flag</code>. Secrets can also be set during runtime.
<h3>8. Infrastructure Reuse</h3>
A development best practice is to avoid duplicating code. The same practice applies to IaC. The ability to reuse configurations lowers the overall overhead involved with managing infrastructure.
Terraform provides a library of reusable <a href="https://registry.terraform.io/browse/modules" target="_blank" rel="nofollow noopener">modules</a>. A <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform module</a> is comprised of a collection of .tf and/or .tf.json files stored in the same folder. Modules are the main way to package and reuse resource configurations with Terraform. Modules can be referenced from a public online registry or your own local module library.
Since Pulumi uses common programming languages, structures like classes, functions, and packages are reusable. Pulumi also provides a searchable <a href="https://www.pulumi.com/registry/" target="_blank" rel="nofollow noopener">registry</a> where you can find packages that can be installed directly into your project. You can also create your own library of reusable packages.

<ul>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Improve Your Infrastructure as Code using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Improve Your Infrastructure as Code using Terraform</a></li>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">5 Ways to Manage Terraform at Scale</a></li>
</ul>

As in most decisions in software development, the answer is &#8211; it depends. Pulumi&#8217;s native language support is its biggest advantage. By using native languages, you can embed IaC code directly within your application, perform unit testing, and reduce the learning curve by using a familiar language. This would be most important to developers who are new to DevOps. IT administrators with little coding experience will probably prefer the simplicity of HCL. 
Bottom line, if the prospect of having to learn a proprietary language like HCL scares you, or if you think you&#8217;ll need to integrate your IaC deployments within your application, choose Pulumi. Otherwise, go with Terraform. 
Either way, there is no wrong choice with Terraform or Pulumi. Both are more than capable of meeting your IaC requirements.

If you are looking to manage infrastructure as code, <a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a> is the way to go. It&#8217;s a continuous integration and deployment (CI/CD) platform that supports Git workflows, policy as code, programmatic configuration, context sharing, and many more great features. It currently works with both <a href="https://docs.spacelift.io/vendors/terraform/" target="_blank" rel="noopener">Terraform</a> and <a href="https://docs.spacelift.io/vendors/pulumi/" target="_blank" rel="noopener">Pulumi</a>, also supporting AWS CloudFormation, Kubernetes, and Ansible. You can test drive it by creating a <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">free trial account</a>.
You can also use Spacelift to mix and match Terraform, Pulumi, and CloudFormation Stacks and have them talk to one another. For example, you can set up Terraform Stacks to provision required infrastructure (like an ECS/EKS cluster with all its dependencies) and then connect that to a CloudFormation Stack, which then transactionally deploys your services there using <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">trigger policies</a>, and the Spacelift provider <a href="https://registry.terraform.io/providers/spacelift-io/spacelift/latest/docs/resources/run" target="_blank" rel="noopener">run resources</a> for workflow orchestration and <a href="https://docs.spacelift.io/concepts/configuration/context#remote-state-alternative-terraform-specific" target="_blank" rel="noopener">Contexts</a> to export Terraform outputs as CloudFormation input parameters.

<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation and controls to simplify and accelerate the provisioning of cloud based infrastructures.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation and controls to simplify and accelerate the provisioning of cloud based infrastructures.

Terraform vs. Kubernetes : Key Differences and Comparison

Atlantis vs. Terraform Cloud / Terraform Enterprise - Comparison

Terraform vs. Ansible : Key Differences and Comparison of Tools

Check out the key differences between Pulumi and Terraform with features comparison and see which tool to choose.

226-terraform-vs-pulumi

Terraform vs. Pulumi

Pulumi vs. Terraform : Key Differences and Comparison

Flavius Dinu

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.
Terraform <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>

Terraform’s implicit dependencies mechanism is more than enough for most use cases. Usually, when you use depends_on, there is a problem with your code, rather than a need for a particular dependency. However, dependencies are required in some cases:
<ul>
<li style="font-weight: 400;" aria-level="1">Ensuring resource configuration – You may need a resource to be fully configured before starting the creation of another one that depends on it</li>
<li style="font-weight: 400;" aria-level="1">Terraform provisioners – If you are using null resources and terraform data in conjunction with a provisioner, you will need to ensure that an instance is created before you can run a script on it</li>
<li style="font-weight: 400;" aria-level="1">Enforcing creation order – If there are resources in your configuration that must be created in a particular order, you can use depends_on to enforce it</li>
<li style="font-weight: 400;" aria-level="1">Workarounds – Terraform may have limitations that can only be addressed by using the depends_on block.</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.

<ul>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">5 Ways to Manage Terraform at Scale</a></li>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments and Infrastructure Provisioning</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">How to Improve Your Infrastructure as Code using Terraform</a></li>
</ul>

<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 <a href="https://spacelift.io/blog/terraform-registry" target="_blank" rel="noopener">Terraform registry</a> 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.

Terraform depends_on can be helpful in some situations, but you need to follow best practices when leveraging it:
<ul>
<li aria-level="1">Limit usage – Overuse of depends_on can lead to complex code that is difficult to troubleshoot.</li>
</ul>
<ul>
<li aria-level="1">Test your dependencies – Catch any potential issues early, to reduce the risk of problems during actual infrastructure provisioning.</li>
</ul>
<ul>
<li aria-level="1">Be specific – Avoid broad dependencies if you can use a specific one.</li>
</ul>
<ul>
<li aria-level="1">Try to use it only for workarounds – Use it for temporary workarounds for limitations or bugs in Terraform providers.</li>
</ul>
Document the reasoning behind using it – Specify if it is a workaround, you are ensuring resource configuration, or any other use case you may have. This will help the team understand the reason for using it.

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" target="_blank" rel="noopener">creating a trial account</a>.
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu works with your existing Terraform state file, so you won’t have any issues when you are migrating to it.

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.

Initialize/ plan/ apply your IaC, manage modules, state, and more. 

frame-8479-2

Frame 8479

Terraform Resource Lifecycle - Examples using 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.

Terraform plan is a Terraform CLI command that previews the changes that will be made to the infrastructure based on the current code configuration. It generates and displays an execution plan, detailing which actions will be taken on which resources, allowing for a review before actual application. 
This step is crucial for understanding the potential impact of changes and ensuring that they align with intentions, thereby preventing unintended modifications. With <code>terraform plan</code>, you will always have a summary at the end, in which you observe the number of resources that will be created/modified/destroyed.
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu works with your existing Terraform state file, so you won’t have any issues when you are migrating to it.

The terraform <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.
<h3>1. Prepare the configuration script</h3>
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.

<h3>2. Run <code>terraform plan</code></h3>
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.
<h3>4. Apply the changes</h3>
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.
<h3>5. Make a change</h3>
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:

<h3>6. Re-run <code>terraform plan</code></h3>
Re-run the <code>plan</code> command:

<h3>7. Observe the output again</h3>
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.

<ul>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">5 Ways to Manage Terraform at Scale</a></li>
<li><a href="https://spacelift.io/blog/terraform-best-practices" target="_blank" rel="noopener">20 Best Practices for Using Terraform</a></li>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments</a></li>
</ul>

Terraform doesn’t have any planning modes per se, but you can use different flags to achieve different behaviors. 
<h3>Normal mode</h3>
The normal mode is running <code>terraform plan</code> without any flags, which will display the actions Terraform will take based on the configuration files in that directory, without applying any changes.
You can also use plan with the <code>-destroy</code> or <code>-refresh-only</code> options, and all of these “modes” are mutually exclusive – this means that you cannot use more than one mode at a time.
<h3>Destroy mode</h3>
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.
<h3>Refresh-only mode</h3>
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

<h3>Using Terraform plan to create a new resource</h3>
Let’s see a plan for creating a new resource. As mentioned before, this is done by simply running <code>terraform plan</code> without any arguments:
Step 1 – Prepare your Terraform configuration.

Step 2 –  Save the configuration to a main.tf file.
Step 3 –  Go to the directory that contains this main.tf.
Step 4 –  Run <code>terraform plan</code>.

<h3>Using Terraform plan to modify an existing resource</h3>
We will reuse the last example for changing the resource. I have applied the code in order to be able to make changes to it. Now let’s see the steps we will need to go through to make changes to a resource:
Step 1 – Go to your main.tf file.
Step 2 – Make a change to your configuration – I will add a new tag.

Step 3 – Run <code>terraform plan</code> again from the location containing your main.tf file.

<h3>Using Terraform plan to destroy an existing resource</h3>
Let’s see a destroy plan in action for the same code example:
Step 1 – Go to the location containing the code base.
Step 2 – Run <code>terraform plan -destroy</code>.

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 Terraform 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>

<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>

<h3>Example &#8211; Using Terraform plan -out</h3>
<h4>Saving Terraform output plan as JSON</h4>
Let’s show the terraform plan as JSON. This is a two-step process:
First, save the plan to a file:

Next, let’s use <code>terraform show</code> command and save the output to a JSON file:

Now, let’s view the content of myplan.json:

<h3>Example &#8211; Using Terraform plan with variables</h3>
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>Example &#8211; Using Terraform plan with tfvars</h3>
Now, let’s pass a tfvars file to the terraform plan that contains the value for the region:

For tfvars files, if you use the names “terraform.tfvars” or “*.auto.tfvars”, you won’t need to pass them directly to the plan/apply/destroy commands, as they will be read automatically by Terraform.

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 the <a href="https://spacelift.io/blog/terraform-target" target="_blank" rel="noopener">Terraform -target flag</a>, 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.

<h3>1. Leverage <code>terraform plan</code> as much as possible</h3>
Whenever you are making changes to your Terraform code base, it is a best practice to use <code>terraform plan</code> before applying the changes per se. This is also valid for pushing changes to your code base, you should always check that your code works properly.
<h3>2. Use VCS for your Terraform code base</h3>
Although this is not a best practice for planning, storing your code in a VCS in conjunction with planning as much as possible will facilitate collaboration and minimize human-error.
<h3>3. Save your plan to an output file</h3>
After you run a <code>terraform plan</code>, Terraform tells you it cannot guarantee it will take exactly these actions if you run a <code>terraform apply</code>. This changes when you save the plan to an output file
<h3>4. Use Terraform Automation and Collaboration Software (TACOS)</h3>
Spacelift facilitates storing state remotely, shows plans in a prettified format, enables policies for better governance of your code, integrates with third party security tools for vulnerability scanning, and more.

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.

frame-8479

Terraform Cheat Sheet - 23 Terraform CLI Commands & Examples

How to Debug & Troubleshoot Terraform Projects: Tutorial

What does the Terraform plan command do? See examples including output, plan to file, tfvars, variables, and others. Planning options and parameters.

110-terraform_plan

Terraform plan command

Terraform Plan Command: Examples & How It Works

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.

Dynamic Blocks in Terraform let you repeat configuration blocks inside a resource/provider/provisioner/datasource based on a variable/local/expression you use inside them. Apart from keeping your configuration DRY, Dynamic Blocks also help you generate dynamic configurations based on your input, enabling your modules to accommodate several different use cases.

<h3>Terraform Dynamic Block components</h3>
<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. (More on <a href="https://spacelift.io/blog/terraform-for-each" target="_blank" rel="noopener">Terraform for each</a>.)
&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.

Having Dynamic Blocks in your configuration strengthens your Terraform code’s overall capabilities, making it easy to repeat blocks in your resource. They are a fundamental capability of Terraform and you should leverage them when you want to repeat blocks inside a resource.

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.

Let&#8217;s see examples for using Terraform Dynamic Blocks in resource blocks and a data source
<h3>Using Terraform Dynamic Block in Resource Blocks</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.
The iterator is optional, and if you omit it, the iterator itself will become the name of the dynamic block. So if we were to omit the iterator above, in the content block for the name, we would have to use subnet.value.name instead of item.value.name

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:

<h3>Using Terraform Dynamic Block in Data Blocks</h3>

In the above example, we are using a dynamic block to filter AMIs in a data source based on some of their tags. If we get any matches, all these AMIs will be returned in a list that we can use further in our configuration code.

Don’t overuse Dynamic Blocks – As mentioned before, you should use dynamic blocks in every block that may be repeated (you may even need to not create a block, and you can also do this with Dynamic Blocks). However, overusing them and going for deep levels of nesting can hurt your overall understanding of the configuration in the future, and it will be harder to explain to other colleagues.
Use a meaningful name for your iterator – If you want to skip using an iterator, that’s totally fine because it will reuse the name of the block, but if you do use it, it should have a meaningful name.
Validate your data – Dynamic Blocks rely on data to be generated. If you are using a variable, take advantage of the validation block and put different conditions in place. On the other hand, if you are using a local, ensure that you perform data checks through loops and functions.
Scalability Considerations – As you can create multiple instances of resources or resources configurations with Dynamic Blocks, you should be aware of the potential scalability concerns, especially in cloud environments where provisioning many resources can affect performance and cost, and even hit service limits.
Consistent Documentation – Thoroughly document your Terraform code — especially your nested dynamic blocks — to make things easier to understand for your team.

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.
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu is the future of the Terraform ecosystem, and having a truly open-source project to support all your IaC needs is the main priority.
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" target="_blank" rel="noopener">trial account</a>.

20 Terraform Best Practices to Improve your TF workflow

Terraform For Loop - Expression Overview with Examples

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

Paul Delcogliano

Pulumi vs. Terraform : Key Differences and Comparison

Get the newsletter

Recent posts

How to Use Terraform depends_on Meta-Argument

Terraform Plan Command: Examples & How It Works

What are Terraform Dynamic Blocks – Examples