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

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

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

Terraform

In this post, I will explain what the <code class="gs kk kl km kn b">terraform apply</code> command is used for, what it does, the available options, and when to run it.

The <code class="gs kk kl km kn b">terraform apply</code> command executes the actions proposed in a <code class="gs kk kl km kn b">terraform plan</code>. It is used to deploy your infrastructure. Typically <code class="gs kk kl km kn b">apply</code> should be run after <a href="https://spacelift.io/blog/terraform-init" target="_blank" rel="noopener"><code class="gs kk kl km kn b">terraform init</code></a> and <code class="gs kk kl km kn b">terraform plan</code>.

If the <code class="gs kk kl km kn b">apply</code> command is run without any options it will run a <code class="gs kk kl km kn b">terraform plan</code> first, ask the user to confirm the planned actions, and then execute those changes once confirmed.
The <code class="gs kk kl km kn b">apply</code> command can also be used with a previously generated planfile, from the <code class="gs kk kl km kn b">terraform plan -out=&lt;path to file&gt;</code>.

<code class="gs kk kl km kn b">terraform apply</code> — Creates or updates infrastructure depending on the configuration files. By default, a plan will be generated first and will need to be approved before it is applied.
<code class="gs kk kl km kn b">terraform apply -auto-approve</code> — Apply changes without having to interactively type ‘yes’ to the plan. Useful in automation CI/CD pipelines.
<code class="gs kk kl km kn b">terraform apply &lt;planfilename&gt;</code> — Provide the file generated using the <code class="gs kk kl km kn b">terraform plan -out</code> command. If provided, Terraform will take the actions in the plan without any confirmation prompts.
<code class="gs kk kl km kn b">terraform apply -var="domainpassword=password123"</code> — Pass in a variable value.
<code class="gs kk kl km kn b">terraform apply -var-file="varfile.tfvars"</code> — Pass in variables contained in a file.
<code class="gs kk kl km kn b">terraform apply -target=”module.appgw.0"</code> — Apply changes only to the targeted resource.
<code class="gs kk kl km kn b">terraform apply -lock=false</code> — Do not hold a state lock during the Terraform apply operation. Use with caution if other engineers might run concurrent commands against the same workspace.
<code class="gs kk kl km kn b">terraform apply -parallelism=&lt;n&gt;</code> — Specify the number of operations run in parallel.

If there are no changes in the configuration files compared to the current Terraform state, then no changes will be made to the infrastructure. Terraform is a declarative language, so it is absolutely safe to run the <code class="gs kk kl km kn b">apply</code> command multiple times.

In automation <code class="gs kk kl km kn b">terraform apply</code> can be run after the plan stage, passing in the plan output file. If there is no plan stage prior to the apply stage (not recommended), then the <code class="gs kk kl km kn b">terraform apply -auto-approve</code> option can be used. Another useful option to avoid encoding issues when running <a href="https://spacelift.io/blog/ci-cd-pipeline" target="_blank" rel="noopener">pipelines in some CI/CD systems</a>, i.e. Azure DevOps, is the <code class="gs kk kl km kn b">terraform apply -no-color</code> option, as the colored output is not handled correctly by the build agents.

<code class="gs kk kl km kn b">terraform apply</code> is a core command in the Terraform workflow, used for deploying infrastructure as described in your configuration files.
For more documentation on the <code class="gs kk kl km kn b">terraform apply</code> command check out the <a href="https://www.terraform.io/cli/commands/apply" target="_blank" rel="nofollow noopener">Hashicorp website</a>.

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: Commands Reference & Useful Examples

12 Terraform Best Practices to Improve your TF workflow

Destroy Command - How to Destroy Resources from Terraform

Terraform apply is a core command in the Terraform workflow. Learn what this command is used for, what it does, the available options, and when to run it.

77-terraform_apply_1

Terraform apply

When to Run Terraform Apply - Quick Usage Examples

Managing variables effectively is one of the most important aspects of a fantastic IaC project. An IaC project can have multiple modules, all of which would use multiple types of resources, and they could possibly have different values across various environments. To make this setup configurable, the project should be able to use variables and manage them effectively.
Let’s dive into understanding everything about the tfvars files and paving the way for creating the most awesome IaC projects.

Tfvars files allow us to manage variable assignments systematically in a file with the extension .tfvars or .tfvars.json. Despite the fact that there are numerous ways to manage <a href="https://spacelift.io/blog/how-to-use-terraform-variables" target="_blank" rel="noopener">variables in Terraform</a>, tfvars files are the best and most common way to do so due to their simplicity and effectiveness. 
Knowing that the best way to learn new things is to do them ourselves, we’ll approach this hands-on to understand the various ways of managing variables in Terraform. In the code example below, we will set up a project to spin up an EC2 instance and learn about declaring and managing variables for it. There are code snippets as well as git repository code to refer to at each step.
<h3>Setting up the base code</h3>
Let’s spin up a simple EC2 instance through Terraform.

Check out the base code <a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/commit/154b7ade9b5409bdee4ffe5d6da318c7afcdf3fe" target="_blank" rel="nofollow noopener">here</a>.
<h3>Introducing variables</h3>
The base code works perfectly. However, imagine working in multiple environments such as test, staging, and production. We would prefer to deploy a larger instance in production and a smaller instance in the test environment to save money. Meaning that the code remains the same except for the instance type, which varies depending on the environment.
We already know that variables can be used to solve this problem. To keep things running, we&#8217;ll create a variable for the instance type and set its default value to &#8220;t2.micro&#8221;.

The variable can be referred to by using the var keyword followed by . and then the &lt;variable_name&gt;.

<a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/commit/3a501197102dd3e44cb20c11b2e20d4d593fbee4" target="_blank" rel="nofollow noopener">Introducing-variable-github-code</a>
The above code works but still relies on the default value. What if we want to change the instance type just for the production environment? How do we pass it a different value when deploying it to production?
There are numerous ways to accomplish this. Let’s look at them one by one.
<ul>
<li style="font-weight: 400;" aria-level="1">Assigning a value through the command line.</li>
</ul>

image1-19

Assigning a value through the command line

<ul>
<li>Using environment variables to set a value.</li>
</ul>

image12-6

Using environment variables to set a value

Sure, both of these methods work. But imagine typing in values for 10 to 20 variables for 5–10 different environments! 🤯 
Even if we save the command somewhere, consider how time-consuming simple changes like changing a few values would be.
This is where tfvars files come in handy. Terraform can load variable definitions from these files automatically. Let&#8217;s have a look.
Note: It’s not uncommon to have 10-20 variables in your IaC when deploying to multiple environments.
Tip: It is wise to break down the project into various small projects whenever the number of variables increases significantly.
<h3>Introducing tfvars files</h3>
Let’s assign the variable a value using the terraform.tfvars file:
<ul>
<li style="font-weight: 400;" aria-level="1">We will start by creating a file named terraform.tfvars. </li>
<li style="font-weight: 400;" aria-level="1">Next, we will assign the instance_type variable a value in this file.</li>
</ul>

image7-9

Introducing tfvars files

<a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/commit/d398604a7d7d62a44f45d4a480e4d09ea5b6f2e8" target="_blank" rel="nofollow noopener">Add-terraform-tfvars-file-github-code</a>
<ul>
<li>Let us see if Terraform picks the assigned value in terraform.tfvars file when we run <code>terraform plan</code>. Remember the default instance_type variable value is t2.micro and value assigned in terraform.tfvars file is t2.large. </li>
</ul>

image10-6

terraform plan

<ul>
<li>Notice that not only did Terraform load the value from the terraform.tfvars file, but it also overwrote the default value assigned to the variable.</li>
</ul>
<h3>Halfway there</h3>
Great! We solved the problem of manually writing large commands and making edits to those commands. But the other half of the problem remains, the problem of managing different versions of the variable values for different environments.
Some questions to think about:
<ul>
<li style="font-weight: 400;" aria-level="1">Should we manually edit the tfvars file every time we deploy to a different environment? </li>
<li style="font-weight: 400;" aria-level="1">Would this solution scale for 10-20 variables with frequent deployments to various environments?</li>
</ul>
Continuously updating the tfvars file may become tiresome. 
What if we created multiple files like test.tfvars, staging.tfvars, production.tfvars, and then passed these variables into Terraform at runtime.
<ul>
<li style="font-weight: 400;" aria-level="1">Let’s create two versions of the tfvars file by the name dev.tfvars and prod.tfvars </li>
<li style="font-weight: 400;" aria-level="1">We will set the instance_type as t2.large for dev version and t2.xlarge for production.</li>
</ul>
<a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/commit/f0978370ae6a0149be097c90636cb87a71a94edd" target="_blank" rel="nofollow noopener">Add-dev-prod-versions-github-code</a>
<ul>
<li>Let’s try running <code>terraform plan</code> again and see which version terraform picks up by default. Take a guess before you run this command 😉</li>
</ul>

image9-6

t2.micro

<ul>
<li style="font-weight: 400;" aria-level="1">It picked neither of the versions we defined; it actually went with the t2.micro default value that is assigned to the variable.</li>
</ul>
How do we ask Terraform to use either of our versions then?
This can be done using the -var-file flag to specify the tfvars file to load. For instance, to load the production version, we will use the following command.

image11-7

t2.xlarge

Awesome! We learned how to pass values to Terraform variables in a variety of ways and solved our many to many problems of managing multiple variables for many environments.
<h4>Autoloading tfvars file</h4>
Terraform auto loads tfvars files only when they are named terraform.tfvars or terraform.tfvars.json.
Is it possible to ensure that tfvars files following custom naming schemes are loaded automatically?
It is in fact possible to name your file whatever you wish and have Terraform load it automatically. All we have to do is provide the file name with .auto.tfvars as an extension. Let’s try it out.
We will rename the dev.tfvars file to dev.auto.tfvars and run <code>terraform plan</code> on it. The expectation is that Terraform should automatically pick the value t2.large from the dev.auto.tfvars file instead of the default value t2.micro.
<a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/commit/6dc2e8a760529617705ee0a81d93ed71311d6202" target="_blank" rel="nofollow noopener">Rename-dev-to-dev-auto-tfvars-github-code</a>

image6-9

dev.auto.tfvars

image1-20

Output: terraform plan

We notice that Terraform automatically loads out our dev.auto.tfvars file as expected.
Terraform can load variable definitions from these files automatically if:
<ul>
<li style="font-weight: 400;" aria-level="1">Files named exactly terraform.tfvars or terraform.tfvars.json.</li>
<li style="font-weight: 400;" aria-level="1">Any files with names ending in .auto.tfvars or .auto.tfvars.json.</li>
</ul>

An interesting thing to ponder is the precedence of the various methods of providing variable values.

image8-9

Variable loading precedence

A typical Terraform project can have 10-20 variables. With this in mind, it becomes a priority to better manage the structure by logically separating all variables in a single place.
This way, we can easily declare and find variables in a single place.
Terraform recommends this single place be the variables.tf file.
Let us quickly extract the instance_type variable we created in the main.tf file into a new file named variable.tf file.
<a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/commit/6c74e1b8d8638f41989c5dd70a1be4458a6b8362" target="_blank" rel="nofollow noopener">Move-all-variables-to-variable-tf-file-github-code</a>

image3-18

Variable.tf files

Remember that variable.tf is like any other Terraform file; there is nothing special about it, and it is only used as a way to logically separate variable declaration into a separate file.

Do not confuse terraform.tfvars files with variable.tf files. Both are completely different and serve different purposes.
<ul>
<li style="font-weight: 400;" aria-level="1">variable.tf are files where all variables are declared; these might or might not have a default value.</li>
<li style="font-weight: 400;" aria-level="1">variable.tfvars are files where the variables are provided/assigned a value.</li>
</ul>

image3-19

variable.tf file containing variable declaration

image6-10

terraform.tfvars file containing variable assignment

The difference becomes clear if we try assigning the variable a value that is not declared in the variable.tf file.

image13-5

Assigning value to an undeclared variable.

image4-17

Warning of an undeclared variable.

We notice that terraform raises a warning about assigning a value to an undeclared variable.
We conclude the difference as that the variables.tf just declare valid variables and optionally their types, and the tfvars file assigns them values.

By default, Terraform only loads .tf present in the current directory. Any files in the subdirectories are not loaded. To load files from subdirectories, Terraform uses a module structure.
It’s vital to keep in mind that .tfvars values only apply to variables in the root module.
The root .tfvars files are essential and authoritative, while child .tfvars files have no effect.
Let us understand this by our code example.
<ul>
<li style="font-weight: 400;" aria-level="1">Let us create a child module that spins another EC2 instance.</li>
</ul>

Create another variable.tf and terraform.tfvarsfiles inside the modules directory. Assign the instance_type variable a value as t2.small.
<a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/commit/0dd90729a4e2dfcb1416f89149d9564f87460864" target="_blank" rel="nofollow noopener">Add-child-module-to-show-hierarchy-github-code</a>

image5-15

variable.tf and terraform.tfvars files

<ul>
<li style="font-weight: 400;" aria-level="1">Call the child module in the root module.</li>
</ul>
<a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/commit/fd796f2e875b16b39ce1e4e055ba409b69759013" target="_blank" rel="nofollow noopener">Call-child-module-in-root-module-github-code</a>
<ul>
<li style="font-weight: 400;" aria-level="1">Run <a href="https://spacelift.io/blog/terraform-init" target="_blank" rel="noopener"><code>terraform init</code></a> for Terraform to load the module statically.</li>
<li style="font-weight: 400;" aria-level="1">Run <code>terraform plan</code>.</li>
</ul>
We notice that the child module tfvars file is ignored and the instance type is set as t2.xlarge (root terraform.tfvars) instead of t2.small (child module terraform.tfvars).

image2-20

Child modules and hierarchy of processing

<a href="https://spacelift.io/blog/iac-architecture-patterns-terragrunt" target="_blank" rel="noopener">Terragrunt</a> is a tool outside terraform that allows us to keep the Terraform configuration DRY and to reduce variable usage redundancies.
Terragrunt aims to minimize repetition, whether it’s in remote backends, multiple environments, or multiple variables per environment.
It employs a terragrunt.hcl file to centrally define a common template configuration and generate code from the defined template.
For a multi-environment use case, Terragrunt allows us to define our Terraform code once and to promote a versioned, immutable “artifact” of that same code from the environment to the environment. For instance, for the example we discussed, the Terragrunt structure would be as follows:

<h3>Inputs</h3>
You can set values for your module’s input parameters by specifying an inputs block in terragrunt.hcl

Whenever you run a Terragrunt command, Terragrunt will set any inputs you pass in as environment variables.

Using inputs, the Terragrunt file prod looks like this:

The terragrunt.hcl file in the test environment will look similar, but it will configure smaller instances type to save money:

When we run <code>terragrunt apply</code>, Terragrunt downloads the ec2 module into a temporary folder and passes the module with the input variables followed by the <code>terraform apply</code> command in that folder. This way, each module in each environment is defined by a single terragrunt.hcl file that solely specifies the <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform module</a> to deploy and the input variables specific to that environment.

Terraform provides a number of methods for declaring and assigning variables. Variable.tf and terraform.tfvars files are excellent for externalizing configurations and passing values so they can be easily deployed across multiple environments.
Terragrunt is a handy tool to keep terraform configuration DRY.

Build more complex workflows based on Terraform using policy as code, programmatic configuration, context sharing, drift detection, resource visualization, and many more.

Terraform Output Values : Complete Guide & Examples

Terraform Locals: What Are They, How to Use Them [Examples]

How to Use Terraform Variables (Locals, Input, Output, Environment)

.tfvars files are the best and most common way to manage variables in Terraform. Learn how to use them effectively in your IaC projects.

59-tfvars

Terraform tfvars

Terraform .tfvars files: Variables Management with Examples

In this article, we explore best practices for managing Infrastructure as Code (IaC) with Terraform. Terraform is one of the most used tools in the <a href="https://spacelift.io/blog/infrastructure-as-code" target="_blank" rel="noopener">IaC</a> space that enables us to safely and predictably apply changes to our infrastructure. 
Starting with Terraform can feel like an intimidating task at first, but a beginner can quickly reach a basic understanding of the tool. After the initial learning period, a new user can then start running commands, creating, and refactoring Terraform code. During this process, many new users face nuances and issues around how to structure their code correctly, use advanced features, apply software development best practices in their IaC process, etc. 
Let’s check together some best practices that will assist you in pushing your Terraform skills to the next level. If you are entirely new to Terraform, look at the <a href="https://spacelift.io/blog/terraform" target="_blank" rel="noopener">Terraform Spacelift Blog</a>, where you can find a plethora of material, tutorials, and examples to boost your skills.

In this section, we will describe some key Terraform concepts briefly. If you are already familiar with these, you can skip this section.
<h3>Terraform Configuration Language</h3>
Terraform uses its own <a href="https://www.terraform.io/language" target="_blank" rel="noopener">configuration language</a> to declare infrastructure objects and their associations. The goal of this language is to be declarative and describe the system’s state that we want to reach.
<h3>Resources</h3>
Resources represent infrastructure objects and are one of the basic blocks of the Terraform language. 
<h3>Data Sources</h3>
<a href="https://spacelift.io/blog/terraform-data-sources-how-they-are-utilised" target="_blank" rel="noopener">Data sources</a> feed our Terraform configurations with external data or data defined by separate Terraform projects.
<h3>Modules</h3>
<a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Modules</a> help us group several resources and are the primary way to package resources in Terraform for reusability purposes. 
<h3>State</h3>
Terraform keeps the information about the state of our infrastructure to store track mappings to our live infrastructure and metadata, create plans and apply new changes. 
<h3>Providers</h3>
To interact with resources on cloud providers, Terraform uses some plugins named providers.

Before moving to Terraform, first, let&#8217;s check some fundamental best practices that apply to all Infrastructure as Code projects. These should be used in your processes regardless of your tool to manage your cloud infrastructure. 
<h3>1. Use version control and prevent manual changes</h3>
This seems like an obvious statement in 2022, but it’s the basis of everything else. We should treat our infrastructure configurations as application code and apply the same best practices for managing, testing, reviewing, and bringing it to production. We should embrace a <a href="https://www.weave.works/technologies/gitops/" target="_blank" rel="nofollow noopener">GitOps</a> approach that fits our use case and implement an automated CI/CD workflow for applying changes.
<h3>2. Shift your culture to Collaborative IaC</h3>
Keeping your infrastructure in version-controlled repositories is the first step to improving your manual infrastructure management. Next, we should strive to enable usage across teams with self-service infrastructure, apply policies and compliance according to our organization’s standards, and access relevant insights and information. Thankfully, <a href="https://spacelift.io/?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bterraform_best_practices%7D" target="_blank" rel="noopener">Spacelift</a> can assist you along the way to achieving these.

This section will explore some strategies for structuring our Terraform projects. In the world of Terraform, there is no right or wrong way to structure our configurations, and most of the suggested structures that you will find online are heavily opinionated.
When deciding how to set up your Terraform configuration, the most important thing is to understand your infrastructure needs and your use case and craft a solution that fits your team and the project.
If we are dealing with a small project with limited infrastructure components, it’s not a bad idea to keep our Terraform configuration as simple as possible. In these cases, we can configure only the necessary files for our root module, which are the configuration files that exist in the root directory. A small project can contain just these files main.tf, variables.tf, README.md. Some other files that you might find handy to use are the outputs.tf to define the output values of your project, versions.tf to gather any pinned versions for the configurations, and providers.tf to configure options related to the providers you use, especially if there are multiple. 
Our primary entry point is main.tf, and in simple use cases, we can add all our resources there. We define our <a href="https://spacelift.io/blog/how-to-use-terraform-variables" target="_blank" rel="noopener">variables</a> in variables.tf and assign values to them in terraform.tfvars. We use the file outputs.tf to declare <a href="https://spacelift.io/blog/terraform-output" target="_blank" rel="noopener">output values</a>. You can find a similar example project structure <a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/tree/master/terraform-best-practices/small-terraform-project-structure" target="_blank" rel="nofollow noopener">here</a>.

image2-21

smal Terraform project structure

When dealing with larger projects, things get a bit more complicated, and we have to take a step back to figure out the best structure for our projects. 
We first have to break down our Terraform code into reusable components that abstract details from consumers and different teams can use and customize accordingly. We can achieve this by creating separate modules for pieces of infrastructure that should be reused in different environments, projects, and teams. 
A common practice is to separate our modules according to ownership and responsibility, rate of change, and ease of management. For every module, we need to define its inputs and outputs and document them thoroughly to enable consumers to use them effectively. We can then leverage outputs and terraform_remote_state to reference values across modules or even different Terraform states. Beware that using the terraform_remote_state data source implies access to the entire state snapshot and this might post a security issue. Another option to share parameters between different states is to <a href="https://www.terraform.io/language/state/remote-state-data#alternative-ways-to-share-data-between-configurations" target="_blank" rel="nofollow noopener">leverage an external tool</a> for publishing and consuming the data like Amazon SSM Parameter Store or HashiCorp Consul.
We have to make the next decision to either keep all our Terraform code in a single repository (monorepo) or to separate our Terraform configurations in multiple code repositories. This is considered a <a href="https://www.hashicorp.com/blog/terraform-mono-repo-vs-multi-repo-the-great-debate" target="_blank" rel="nofollow noopener">great debate</a> since both approaches have drawbacks and benefits. There is a tendency in the industry to avoid gigantic monorepos and use separate configurations to enable faster module development and flexibility. Personally, this is the approach I prefer too.
Usually, we have to deal with a plethora of different Infrastructure environments, and there are multiple ways to handle this in Terraform. A good and easy practice to follow is to separate Terraform configurations for different environments. This way, different environments have their own state and can be tested and managed separately, while shared behavior is achieved with shared or remote modules. 
One option is using a separate directory per environment and keeping a separate state for each directory. Another option would be to keep all the Terraform configurations in the same directory and pass different environment variables per environment to parametrize the configuration accordingly. Check out the <a href="https://www.youtube.com/watch?v=wgzgVm7Sqlk" target="_blank" rel="nofollow noopener">Evolving Your Infrastructure with Terraform</a> and <a href="https://www.youtube.com/watch?v=Nr5Km_xGLVs" target="_blank" rel="nofollow noopener">How I Manage More Environments with Less Code in Terraform </a>talks for some inspiration around structuring your projects. 
<a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/tree/master/terraform-best-practices/separate-environments-project-structure" target="_blank" rel="nofollow noopener">Here</a>, you can find an example structure for three different environments per directory: production, staging, and test. Each environment has its own state and is managed separately from the others while leveraging common or shared modules.  Although this approach comes with some code duplication, we gain improved clarity, environment isolation, and scalability.

image1-21

Separate environments project structure

As a general rule, we want to define Terraform configurations with limited scope and blast radius with specific owners. To minimize risk, we should try to decompose our projects into small workspaces/stacks and segment access to them using Role-based access control(RBAC).

Alright, in the previous sections, we talked about some generic IaC best practices. We explored some options for optimizing our Terraform code according to our organizational structure and needs. 
In this part, we are deep-diving into specific points that will take our Terraform code to the next level. This list isn’t exhaustive, and some parts are opinionated based on my personal preferences and experiences. 
The goal here is to give you hints and guidance on experimenting, researching, and implementing the practices that make sense to your use case.
<h3>1. Remote state</h3>
It’s ok to use the local state when experimenting, but use a remote shared state location for anything above that point. Having a single remote backend for your state is considered one of the first best practices you should adopt when working in a team. Pick one that supports state locking to avoid multiple people changing the state simultaneously. Treat your state as immutable and avoid manual state changes at all costs. Make sure you have backups of your state that you can use in case of a disaster. For some backends, like AWS S3, you can enable versioning to allow for quick and easy state recovery.
<h3>2. Use existing shared and community modules</h3>
Instead of writing your own modules for everything and reinventing the wheel, check if there is already a module for your use case. This way, you can save time and harness the power of the Terraform community. If you feel like it, you can also help the community by improving them or reporting issues. You can check the <a href="https://registry.terraform.io/browse/modules" target="_blank" rel="nofollow noopener">Terraform Registry</a> for available modules. 
<h3>3. Import existing infrastructure</h3>
If you inherited a project that is a couple of years old, chances are that some parts of its infrastructure were created manually. Fear not, you can <a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform" target="_blank" rel="noopener">import existing infrastructure into Terraform</a> and avoid managing infrastructure from multiple endpoints.  
<h3>4. Avoid variables hard-coding</h3>
It might be tempting to hardcode some values here and there but try to avoid this as much as possible. Take a moment to think if the value you are assigning directly would make more sense to be defined as a variable to facilitate changes in the future. Even more, check if you can get the value of an attribute via a data source instead of setting it explicitly. For example, instead of finding our AWS account id from the console and setting it in terraform.tfvars as

We can get it from a data source.

<h3>5. Always format and validate</h3>
In IaC, consistency is essential long-term, and Terraform provides us with some tools to help us in this quest. Remember to run terraform fmt and terraform validate to properly format your code and catch any issues that you missed. Ideally, this should be done auto-magically via a <a href="https://spacelift.io/blog/ci-cd-pipeline" target="_blank" rel="noopener">CI/CD pipeline</a> or pre-commit hooks.
<h3>6. Use a consistent naming convention</h3>
You can find online many suggestions for naming conventions for your Terraform code. The most important thing isn’t the rules themselves but finding a convention that your team is comfortable with and trying collectively to be consistent with it. If you need some guidance, here’s a list of rules that are easy to follow:
<ul>
<li style="font-weight: 400;" aria-level="1">Use underscores(_) as a separator and lowercase letters in names. </li>
<li style="font-weight: 400;" aria-level="1">Try not to repeat the resource type in the resource name.</li>
<li style="font-weight: 400;" aria-level="1">For single-value variables and attributes, use singular nouns. For lists or maps, use plural nouns to show that it represents multiple values.</li>
<li style="font-weight: 400;" aria-level="1">Always use descriptive names for variables and outputs, and remember to include a description.</li>
</ul>
<h3>7. Tag your Resources</h3>
A robust and consistent tagging strategy will help you tremendously when issues arise or trying to figure out which part of your infrastructure exploded your cloud vendor’s bill. You can also craft some nifty access control policies based on tags when needed. Like when defining naming conventions, try to be consistent and always tag your resources accordingly.
The Terraform argument tags should be declared as the last argument(only depends_on or lifecycle arguments should be defined after tags if relevant). A handy option to help you with tagging is defining some default_tags that apply to all resources managed by a provider. Check out <a href="https://learn.hashicorp.com/tutorials/terraform/aws-default-tags" target="_blank" rel="nofollow noopener">this example</a> to see how to set and override default tags for the AWS provider. If the provider you use doesn’t support default tags, you must manually pass these tags through to your modules and apply them to your resources.
<h3>8. Introduce Policy as Code</h3>
As our teams and infrastructure scale, our trust in individual users is generally reduced. We should set up some policies to ensure our systems continue to be operational and secure. Having a <a href="https://docs.spacelift.io/concepts/policy" target="_blank" rel="noopener">Policy as Code </a>process in place allows us to define the rules of what is considered secure and acceptable at scale and automatically verify these rules.  Spacelift leverages an open-source engine to achieve this, <a href="https://spacelift.io/blog/what-is-open-policy-agent-and-how-it-works" target="_blank" rel="noopener">Open Policy Agent(OPA)</a>. 
<h3>9. Implement a Secrets Management Strategy</h3>
Usually, users won’t admit that they have secrets in their Terraform code, but we have all been there. When you are starting with Terraform, it’s normal that secret management isn’t your top priority, but eventually, you will have to define a strategy for handling secrets. 
As you probably heard already, never store secrets in plaintext and commit them in your version control system. One technique that you can use is to pass secrets by setting environment variables with TF_VAR and marking your sensitive variables with sensitive = true.
A more mature solution would be to set up a secret store like Hashicorp Vault or AWS Secrets Manager to handle access to secrets for you. This way, you can protect your secrets at rest and enforce encryption without too much trouble. You can also opt for more advanced features like secret rotation and audit logs. Beware that this approach usually comes with the cost of using this managed service. 
<h3>10. Test your Terraform code</h3>
As with all other code, IaC code should be tested properly. There are different approaches here, and again, you should find one that makes sense for you. Running terraform plan is the easiest way to verify if your changes will work as expected quickly. Next, you can perform some static analysis for your Terraform code without the need to apply it. Unit testing is also an option to verify the normal operation of distinct parts of your system.
Another step would be to integrate a Terraform linter to your CI/CD pipelines and try to catch any possible errors related to Cloud Providers, deprecated syntax, enforce best practices, etc. One step ahead, you can set up some integration tests by spinning up a replica sandbox environment, applying your plan there, verifying that everything works as expected, collecting results, destroying the sandbox, and moving forward by applying it to production. 
There are a lot of tools out there that can help you with testing your Terraform code. I will list some of them in the “Helper Tools” section below.
<h3>11. Enable debug/troubleshooting</h3>
When issues arise, we have to be quick and effective in gathering all the necessary information to solve them. You might find it helpful to set the Terraform log level to debug in these cases.

Another thing that you might find helpful is to persist logs in a file by setting the TF_LOG_PATH environment variable. Check out this <a href="https://spacelift.io/blog/terraform-debug" target="_blank" rel="noopener">Terraform Debug </a><a href="https://spacelift.io/blog/terraform-debug" target="_blank" rel="noopener">tutorial</a> for some hands-on examples.
<h3>12. Leverage Helper tools to make your life easier</h3>
Terraform is one of the most used and loved IaC tools out there, and naturally, there is a big community around it. Along with this community, many helper tools are being constantly created to help us through our Terraform journey. Picking up and adopting the right tools for our workflows isn’t always straightforward and usually involves an experimentation phase. Here you can find a list of tools that I find helpful based on my experience, but it is definitely not an exhaustive list. 
<ul>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/terraform-linters/tflint" target="_blank" rel="nofollow noopener">tflint</a> &#8211; Terraform linter for errors that the plan can’t catch.</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/tfutils/tfenv" target="_blank" rel="nofollow noopener">tfenv</a> &#8211; Terraform version manager</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/bridgecrewio/checkov/" target="_blank" rel="nofollow noopener">checkov</a> &#8211;  Terraform static analysis tool </li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/gruntwork-io/terratest/" target="_blank" rel="nofollow noopener">terratest</a> &#8211; Go library that helps you with automated tests for Terraform</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/antonbabenko/pre-commit-terraform" target="_blank" rel="nofollow noopener">pre-commit-terraform</a> &#8211; Pre-commit git hooks for automation </li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/terraform-docs/terraform-docs" target="_blank" rel="nofollow noopener">terraform-docs</a> &#8211; Quickly generate docs from modules</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bterraform_best_practices%7D" target="_blank" rel="noopener">spacelift</a> &#8211; Collaborative Infrastructure Delivery Platform for Terraform (<a href="https://spacelift.io/terraform-cloud-alternative" target="_blank" rel="noopener">Terraform Cloud alternative</a>)</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/runatlantis/atlantis" target="_blank" rel="nofollow noopener">atlantis</a> &#8211; Workflow for collaborating on Terraform projects</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/antonbabenko/terraform-cost-estimation" target="_blank" rel="nofollow noopener">terraform-cost-estimation</a> &#8211; Free cost estimation service for your plans.</li>
</ul>
Check out also this list that includes a lot more <a href="https://github.com/shuaibiyy/awesome-terraform#tools)" target="_blank" rel="nofollow noopener">awesome terraform tools</a>.

We have explored many different best practices for Terraform and Infrastructure as Code, analyzed various options for handling and structuring our Terraform projects, and saw how adopting helper tools could make our life easier. 
Remember, this isn’t a recipe that you have to follow blindly but a guide that aims to provide pointers and cues and trigger you to build your own optimal Terraform workflows and projects.
Thank you for reading, and I hope you enjoyed this “Terraform Best Practices” article as much as I did.

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.

How to Deploy your Infrastructure in CI/CD using Terraform

5 Ways to Manage Terraform at Scale - Best Practices

Learn some best practices that will assist you in pushing your Terraform skills to the next level. See how they can make your IaC management easier.

57-terraform_best_practices-2

terraform best practices

Terraform Best Practices for Better Infrastructure Management

Sometimes you just want to get straight to the commands you need to use with a particular tool, without having to trawl through all the documentation. In this post, I’ll highlight the commonly used commands used on the Terraform CLI so you can get straight into the action without the pain!
This command reference guide was written using the <a href="https://spacelift.io/blog/terraform-version-upgrade" target="_blank" rel="noopener">latest version of Terraform</a> at the time of writing, v.1.1.9. New commands and subcommands can be added and depreciated over time with different versions, but should not change too dramatically. You can get the latest version of Terraform <a href="https://www.terraform.io/downloads" target="_blank" rel="nofollow noopener">here</a>.

<h3 id="5ad0" class="mw mf ip bn mg mx my mz mk na nb nc mo kn nd ne mq kr nf ng ms kv nh ni mu nj gt">Contents</h3>
<ul class="">
<li id="f240" class="nk nl ip kg b kh nm kk nn kn no kr np kv nq kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#get-help">Get Help</a></li>
<li id="2b2a" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#show-your-terraform-version">Show your Terraform version</a></li>
<li id="4562" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#format-your-terraform-code">Format your Terraform code</a></li>
<li id="1ce2" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#initialize-your-directory">Initialize your directory</a></li>
<li id="f905" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#download-and-install-modules">Download and install modules</a></li>
<li id="dcb1" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#validate-your-terraform-code">Validate your Terraform code</a></li>
<li id="5649" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#plan-your-infrastructure">Plan your Infrastructure</a></li>
<li id="0ef2" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#deploy-your-infrastructure">Deploy your Infrastructure</a></li>
<li id="0701" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#destroy-your-infrastructure">Destroy your infrastructure</a></li>
<li id="e016" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#taint-or-untaint-your-resources">‘Taint’ or ‘Untaint’ your resources</a></li>
<li id="c1eb" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#refresh-the-state-file">Refresh the state file</a></li>
<li id="c6df" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#viewyour-state-file">View your state file</a></li>
<li id="60ea" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#manipulate-your-state-file">Manipulate your state file</a></li>
<li id="c28a" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#import-existing-infrastructure-into-your-terraform-state">Import existing Infrastructure into your Terraform state</a></li>
<li id="c203" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#get-provider-information">Get provider information</a></li>
<li id="0556" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#manage-your-workspaces">Manage your workspaces</a></li>
<li id="5c08" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#view-your-outputs">View your outputs</a></li>
<li id="4e3b" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#release-a-lock-on-your-workspace">Release a lock on your workspace</a></li>
<li id="aa3f" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#log-in-and-out-to-a-remote-host-terraform-cloud">Log in and out to a remote host (Terraform Cloud)</a></li>
<li id="3100" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#produce-a-dependency-diagram">Produce a dependency diagram</a></li>
<li id="bc46" class="nk nl ip kg b kh nv kk nw kn nx kr ny kv nz kz nr ns nt nu gt" data-selectable-paragraph=""><a href="https://spacelift.io/blog/terraform-commands-cheat-sheet#test-your-expressions">Test your expressions</a></li>
</ul>

<code class="gs od oe of og b">terraform -help</code> — Get a list of available commands for execution with descriptions. Can be used with any other subcommand to get more information.
<code class="gs od oe of og b">terraform fmt -help</code> — Display help options for the <code class="gs od oe of og b">fmt</code> command.

<code class="gs od oe of og b">terraform version</code> — Shows the current version of your Terraform and notifies you if there is a newer version available for download.

This should be the first command you run after creating your configuration files to ensure your code is formatted using the HCL standards. This makes it easier to follow and aids collaboration.
<code class="gs od oe of og b">terraform fmt</code> — Format your Terraform configuration files using the HCL language standard.
<code class="gs od oe of og b">terraform fmt --recursive</code> — Also formats files in subdirectories
<code class="gs od oe of og b">terraform fmt --diff</code> — Display differences between original configuration files and formatting changes.
<code class="gs od oe of og b">terraform fmt --check</code> — Useful in automation <a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener">CI/CD pipelines</a>, the check flag can be used to ensure the configuration files are formatted correctly, if not the exit status will be non-zero. If files are formatted correctly, the exit status will be zero.

<code class="gs od oe of og b">terraform init</code> — In order to prepare the working directory for use with Terraform, the <code class="gs od oe of og b">terraform init</code> command performs Backend Initialization, Child Module Installation, and Plugin Installation.
<code class="gs od oe of og b">terraform init -get-plugins=false</code> — Initialize the working directory, do not download plugins.
<code class="gs od oe of og b">terraform init -lock=false</code> — Initialize the working directory, don’t hold a state lock during backend migration.
<code class="gs od oe of og b">terraform init -input=false</code> — Initialize the working directory, and disable interactive prompts.
<code class="gs od oe of og b">terraform init -migrate-state</code> — Reconfigure a backend, and attempt to migrate any existing state.
<code class="gs od oe of og b">terraform init -verify-plugins=false</code> — Initialize the working directory, do not verify plugins for Hashicorp signature
For a detailed rundown of the <code class="gs od oe of og b">terraform init</code> command see <a class="au oh" href="https://spacelift.io/blog/terraform-init" target="_blank" rel="noopener">our post here</a>!

Note this is usually not required as this is part of the <code class="gs od oe of og b">terraform init</code> command.
<code class="gs od oe of og b">terraform get</code> — Downloads and installs <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">modules</a> needed for the configuration.
<code class="gs od oe of og b">terraform get -update</code> — Checks the versions of the already installed modules against the available modules and installs the newer versions if available.

<code class="gs od oe of og b">terraform validate</code> — Validates the configuration files in your directory, and does not access any remote state or services. <code class="gs od oe of og b">terraform init</code> should be run before this command.

<code class="gs od oe of og b">terraform plan</code> — Plan will generate an execution plan, showing you what actions will be taken without actually performing the planned actions.
<code class="gs od oe of og b">terraform plan -out=&lt;path&gt;</code> — Save the plan file to a given path. Can then be passed to the <code class="gs od oe of og b">terraform apply</code> command.
<code class="gs od oe of og b">terraform plan -destroy</code> — Creates a plan to destroy all objects, rather than the usual actions.

<code class="gs od oe of og b">terraform apply</code> — Creates or updates infrastructure depending on the configuration files. By default, a plan will be generated first and will need to be approved before it is applied.
<code class="gs od oe of og b">terraform apply -auto-approve</code> — Apply changes without having to interactively type ‘yes’ to the plan. Useful in automation CI/CD pipelines.
<code class="gs od oe of og b">terraform apply &lt;planfilename&gt;</code> — Provide the file generated using the <code class="gs od oe of og b">terraform plan -out</code> command. If provided, Terraform will take the actions in the plan without any confirmation prompts.
<code class="gs od oe of og b">terraform apply -lock=false</code> — Do not hold a state lock during the Terraform apply operation. Use with caution if other engineers might run concurrent commands against the same workspace.
<code class="gs od oe of og b">terraform apply -parallelism=&lt;n&gt;</code> — Specify the number of operations run in parallel.
<code class="gs od oe of og b">terraform apply -var="domainpassword=password123"</code> — Pass in a variable value.
<code class="gs od oe of og b">terraform apply -var-file="varfile.tfvars"</code> — Pass in variables contained in a file.
<code class="gs od oe of og b">terraform apply -target=”module.appgw.0"</code> — Apply changes only to the targeted resource.

<code class="gs od oe of og b">terraform destroy</code> — <a href="https://spacelift.io/blog/how-to-destroy-terraform-resources" target="_blank" rel="noopener">Destroys</a> the infrastructure managed by Terraform.
<code class="gs od oe of og b">terraform destroy -target=”module.appgw.0"</code> — Destroy only the targeted resource.
<code class="gs od oe of og b">terraform destroy -auto-approve</code> — Destroys the infrastructure without having to interactively type ‘yes’ to the plan. Useful in automation CI/CD pipelines.

Use the <code class="gs od oe of og b">taint</code> command to mark a resource as not fully functional. It will be deleted and re-created.
<code class="gs od oe of og b">terraform taint vm1.name</code> — Taint a specified resource instance.
<code class="gs od oe of og b">terraform untaint vm1.name</code> — Untaint the already tainted resource instance.

<code class="gs od oe of og b">terraform refresh</code> — Modifies the state file with updated metadata containing information on the resources being managed in Terraform. Will not modify your infrastructure.

<code class="gs od oe of og b">terraform show</code> — Shows the state file in a human-readable format.
<code class="gs od oe of og b">terraform show &lt;path to statefile&gt;</code> — If you want to read a specific state file, you can provide the path to it. If no path is provided, the current state file is shown.

<code class="gs od oe of og b">terraform state</code> — One of the following subcommands must be used with this command in order to manipulate the state file.
<code class="gs od oe of og b">terraform state list</code> — Lists out all the resources that are tracked in the current state file.
<code class="gs od oe of og b">terraform state mv</code> — Moves an item in the state, for example, this is useful when you need to tell Terraform that an item has been renamed, e.g. <code class="gs od oe of og b">terraform state mv vm1.oldname vm1.newname</code>
<code class="gs od oe of og b">terraform state pull &gt; state.tfstate</code> — Gets the current state and outputs it to a local file.
<code class="gs od oe of og b">terraform state push</code> — Update remote state from the local state file.
<code class="gs od oe of og b">terraform state replace-provider hashicorp/azurerm customproviderregistry/azurerm</code> — Replace a provider, useful when switching to using a custom provider registry.
<code class="gs od oe of og b">terraform state rm</code> — Remove the specified instance from the state file. Useful when a resource has been manually deleted outside of Terraform.
<code class="gs od oe of og b">terraform state show &lt;resourcename&gt;</code> — Show the specified resource in the state file.

<code class="gs od oe of og b">terraform import vm1.name -i id123</code> — Import a VM with id123 into the configuration defined in the configuration files under vm1.name.
<code class="gs od oe of og b">terraform import vm1.name -i id123 -allow-missing-config</code> — Import and allow if the configuration block does not exist.
See our <a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform" target="_blank" rel="noopener">terraform import tutorial</a> for more details.

<code class="gs od oe of og b">terraform providers</code> — Displays a tree of providers used in the configuration files and their requirements.

<code class="gs od oe of og b">terraform workspace</code> — One of the following subcommands must be used with the workspace command. Workspaces can be useful when an engineer wants to test a slightly different version of the code. It is not recommended to use Workspaces to isolate or separate the same infrastructure between different development stages, e.g. Dev / UAT / Production, or different internal teams.
<code class="gs od oe of og b">terraform workspace show</code> — Show the name of the current workspace.
<code class="gs od oe of og b">terraform workspace list</code> — List your workspaces.
<code class="gs od oe of og b">terraform workspace select &lt;workspace name&gt;</code> — Select a specified workspace.
<code class="gs od oe of og b">terraform workspace new &lt;workspace name&gt;</code> — Create a new workspace with a specified name.
<code class="gs od oe of og b">terraform workspace delete &lt;workspace name&gt;</code> — Delete a specified workspace.

<code class="gs od oe of og b">terraform output</code> — Lists all the <a href="https://spacelift.io/blog/terraform-output" target="_blank" rel="noopener">outputs</a> currently held in your state file. These are displayed by default at the end of a <code class="gs od oe of og b">terraform apply</code>, this command can be useful if you want to view them independently.
<code class="gs od oe of og b">terraform output -state=&lt;path to state file&gt;</code> — Lists the outputs held in the specified state file.
<code class="gs od oe of og b">terraform output -json</code> — Lists the outputs held in your state file in JSON format to make them machine-readable.
<code class="gs od oe of og b">terraform output vm1_public_ip</code> — List a specific output held in your state file.

<code class="gs od oe of og b">terraform force-unlock &lt;lock_id&gt;</code> — Remove the lock with the specified lock ID from your workspace. Useful when a lock has become ‘stuck’, usually after an incomplete Terraform run.

<code class="gs od oe of og b">terraform login</code> — Grabs an API token for Terraform cloud (app.terraform.io) using your browser.
<code class="gs od oe of og b">terraform login &lt;hostname&gt;</code> — Log in to a specified host.
<code class="gs od oe of og b">terraform logout</code> — Removes the credentials that are stored locally after logging in, by default for Terraform Cloud (app.terraform.io).
<code class="gs od oe of og b">terraform logout &lt;hostname&gt;</code> — Removes the credentials that are stored locally after logging in for the specified hostname.

<code class="gs od oe of og b">terraform graph</code> — Produces a graph in DOT language showing the dependencies between objects in the state file. This can then be rendered by a program called Graphwiz (amongst others).
<code class="gs od oe of og b">terraform graph -plan=tfplan</code> — Produces a dependency graph using a specified plan file (generated using <code class="gs od oe of og b">terraform plan -out=tfplan</code>).
<code class="gs od oe of og b">terraform graph -type=plan</code> — Specifies the type of graph to output, either <code class="gs od oe of og b">plan, plan-refresh-only, plan-destroy,</code> or <code class="gs od oe of og b">apply</code>.

<code class="gs od oe of og b">terraform console</code> — Allows testing and exploration of expressions on the interactive console using the command line. e.g. 1+2 🙂

This guide should help you get straight to the command you need when using the Terraform CLI!

Build more complex workflows based on Terraform using policy as code, programmatic configuration, context sharing, drift detection, resource visualization and many more.

What are Terraform Templates? Basics, Use Cases, Examples

Terraform Functions, Expressions, Loops (Examples)

This Terraform Cheat Sheet guide will help you get straight to the commands you need when using the Terraform CLI!

69-terraform_cheat_sheet

Terraform Cheat Sheet

This blog post will deep dive into how Terraform handles output and how we can leverage and use output values efficiently across our Terraform projects. Output values allow us to share data between modules and workspaces while also providing us the flexibility to pass values to external systems for automation purposes.
You have come to the right place if you are new to Terraform! Spacelift has curated a ton of valuable material, tutorials, and <a href="https://spacelift.io/blog/terraform" target="_blank" rel="noopener">blog posts around Terraform</a> and how industry experts use it on its Spacelift blog.

Input variables permit us to customize Terraform configurations without hardcoding any values. This way, we can reuse <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform modules</a> while assigning custom values based on our needs. Usually, we refer to them as just variables in the context of Terraform.
To define input variables, we must declare them using a variable block:

The variable&#8217;s name is the label we set following the variable keyword. For every variable, we have the option to set some arguments such as default, type, description, validation, sensitive, and nullable. Check the official documentation about these arguments and how to set them in detail <a href="https://www.terraform.io/language/values/variables#arguments" target="_blank" rel="nofollow noopener">here</a>. 
After declaring our input variables, we can utilize them in modules by referencing them like this var.&lt;variable_name&gt; where &lt;variable_name&gt; matches the label following the variable keyword. For example, to reference the variable ec2_instance_type that we defined above:

On the other hand, output values empower us to export helpful information from our Terraform projects that we have defined and provisioned with Terraform. In the context of Terraform, we refer to output values as just outputs for simplicity. 
Combining input and output variables, we get the flexibility to customize, automate, reuse and share our Terraform code easily. Input variables are similar to function arguments in traditional programming, while output variables work similarly to the return values of a function. Both are equally important to make our Terraform projects functional and facilitate data&#8217;s incoming and outgoing flow.

More specifically, output values are quite helpful in certain use cases:
<ul>
<li style="font-weight: 400;" aria-level="1">We can expose information from child modules to a parent module using outputs.</li>
<li style="font-weight: 400;" aria-level="1">Even more, from a root module, we can print outputs in the command line or pass these output values to external systems for automation purposes. </li>
</ul>
When we use a remote state, we can access the root module outputs by other configurations using the <a href="https://www.terraform.io/language/state/remote-state-data" target="_blank" rel="nofollow noopener">terraform_remote_state</a> data source. Output values from child modules aren&#8217;t accessible.

In order to define an output value, we have to use the output block:

In the above example, we define an output value with the name instance_public_ip. This way, we can pass the value to the parent module or display it to the end-user if it’s an output of the root module.
The value argument, which is the returned output value, takes an expression referencing other resources or module attributes. Terraform only renders and displays outputs when executing terraform apply and not when executing terraform plan. 
To use outputs of nested modules from parent modules, we have to reference them as: 
module.&lt;module_name&gt;.&lt;output_value_name&gt;
For example, to reference the output value instance_public_ip that we have declared above in a module named aws_web_server_instance from its parent module, we have to use:

Let’s examine how we can use all this in a real-world example. In <a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/tree/master/terraform-output" target="_blank" rel="nofollow noopener">this GitHub repository</a>, we define the Terraform configuration for this example’s infrastructure. To follow along, you will need to <a href="https://spacelift.io/blog/how-to-install-terraform" target="_blank" rel="noopener">install Terraform</a>, have an <a href="https://aws.amazon.com/console/" target="_blank" rel="nofollow noopener">AWS account</a> ready, and <a href="https://registry.terraform.io/providers/hashicorp/aws/latest/docs" target="_blank" rel="nofollow noopener">authenticate with your AWS keys</a> via the command line. Note that you might be charged a few dollars in your AWS account if you follow along.
In this example, we create the necessary infrastructure for a webserver. For the needs of this demo, we split our Terraform configuration into three modules, the root one and two child modules responsible for handling VPC-related resources and EC2 instance-related resources. 

The project structure looks like this:

image6-5

The project structure

For each module, we define a main.tf file that handles the main functionality of the module. 
Variable’s declarations and default values are populated in variables.tf files, while for the root module, we also use a terraform.tfvars file to set some variable values.
A good practice is to define our outputs in separate outputs.tf files, as you can see in the above example project structure. By declaring output values in an outputs.tf file per module, we improve the clarity of our modules as it’s easier for users to understand what outputs to expect from them quickly. 
The root module utilizes and configures the aws provider and then just simply calls two child modules aws_web_server_vpc and aws_web_server_instance in main.tf of the top directory. 
root module main.tf

We notice that when calling the module aws_web_server_instance, we are passing two expressions using output values from the aws_web_server_vpc module with the notation module.&lt;module_name&gt;.&lt;output_value_name&gt; we have seen earlier. 
root module outputs.tf

We define three output values for our root module, and we expect to see them at the command line after our infrastructure is provisioned. Checking the value parameter of each block, we notice that all of them are coming from output values of the two child modules, and by declaring them as output values of the root module, we are able to pass them through to the command line.
root module variables.tf

root module terraform.tfvars

Let’s examine next our two child modules and how we use output values to pass parameters between them.
aws-web-server-vpc module main.tf

In the above module, we define some resources necessary for the networking layer of our infrastructure.
aws-web-server-vpc module variables.tf

aws-web-server-vpc module outputs.tf

The two outputs we export here from this module are passed to the aws-web-server-instance module as parameters in order to create the EC2 instance inside the vpc and subnet that we have just created. We saw how this was handled in the main.tf file of the root module. The output value vpc_id is passed along as an output of the root module and should be printed in the command line after we apply the plan.
Finally, the Terraform configuration for the aws-web-server-instance module uses the passed info from the aws-web-server-vpc module. It creates and configures the web server instance accordingly.  
aws-web-server-instance module main.tf

aws-web-server-instance module variables.tf

The two output values that we pass through the root module are also defined in this module’s outputs.tf file.

Time to wrap up everything and execute the plan to provision our demo infrastructure.

image8-6

plan to provision the demo infrastructure

Our terraform plan shows 7 new resources to be added and displays the changes to our three output values declared in the root module. Let’s go ahead and apply the plan.

image3-13

Apply the plan

As expected, the three outputs declared in the root module are displayed at the command line, sweet! 
We could use these values to automate other parts of our systems and process, but for now, we can get the value from instance_public_ip and head to http://&lt;instance_public_ip&gt;, and we should see our demo web server up and running.

image7-6

demo web server

Great! Everything works as expected.

Output values are stored in the state Terraform file. Since we have successfully applied our plan, we can now access these output values at will. We can leverage the terraform output command for this purpose.

image2-15

Terraform output command

Additionally, we can query individual output values by name like this
terraform output &lt;output_value_name&gt;

image5-10

individual output values

To get the raw value without quotes, use the -raw flag.
terraform output -raw &lt;output_value_name&gt; 
To get the JSON-formatted output, we can use the -json flag.

image1-15

the -json flag

This is quite useful when we want to pass the outputs to other tools for automation since JSON is way easier to handle programmatically. Note that Terraform does not protect sensitive output values when using the -json flag.
When we are done, let’s go ahead and delete all these resources to avoid paying for them. 
From the top of our repository, execute:
<code><a href="https://spacelift.io/blog/how-to-destroy-terraform-resources" target="_blank" rel="noopener">terraform destroy</a></code>

When defining output values, we have a couple of options that might help us better define and organize them. 
The argument description is optional, but it is always considered good practice to include it in our output declarations to document their purpose. This argument should briefly explain each output&#8217;s intent and should be used as a helper description for the users of the module. We have already seen examples like this since we defined the description argument in all our output block declarations in our previous demo.
In cases where we want to handle sensitive values and suppress them in command line output, we can declare an output value as sensitive. Terraform will redact the values of sensitive outputs when planning, applying, destroying, or querying outputs to avoid printing them to the console. In practice, this is a good use case when we would like to pass values to other Terraform modules or automation tools without exposing them to the intermediate users.

Note that Terraform won’t redact sensitive output values when you query a specific output by name. After we apply a plan with an output declared as sensitive, the console displays a message with the value redacted.

image4-12

Outputs

These values are still recorded in the state files, so anyone who can access them can also access any sensitive values of our Terraform configuration. 
The depends_on argument on output declarations is used to define dependencies explicitly when this is necessary. Most of the time, Terraform handles this automatically, but there are some rare uses cases where you might find this option handy when it’s not the case. Consider including a comment when you use this option to explain why this is necessary.

Occasionally, we might need to share data between different Terraform configurations with separate states. This is where the terraform_remote_state data sources come into play. We can retrieve the root module outputs from another Terraform configuration using this data source. This built-in data source is available without any extra configuration needed. 
Following up on our previous example, let’s say that we would like to create a new subnet in the vpc of our aws-web-server-vpc module. This time, the new subnet needs to be defined in a completely separate Terraform configuration that has its own state. We can leverage the terraform_remote_state to get the value of the vpc_id defined as an output of our previous example’s root module. In this case, we use the local backend to reach the state of another configuration in the local machine. The backend could be any remote backend that points to a Terraform state in a real-world scenario.

Note that only the output values of the root module are accessible from the remote state. If we want to pass values from nested modules, we have to configure a passthrough output value declaration as we defined earlier in the root module of our previous example. 
Although this option is handy for some use cases, it also has some caveats. To use this data source, the user must have access to the entire state snapshot, which could potentially expose sensitive data. Check out the official docs to find <a href="https://www.terraform.io/language/state/remote-state-data#alternative-ways-to-share-data-between-configurations" target="_blank" rel="nofollow noopener">alternative ways to share data between configurations</a>.

We have seen how Terraform handles and exports output values between modules and the different options for outputs configuration. Even more, we compared input and output variables and examined multiple use cases where the use of outputs is helpful. Finally, we went through a complete example of using output values in our Terraform configuration between different modules and printing them to the console. 
Thank you for reading, and I hope you enjoyed this “Terraform Outputs” blog post as much as I did.

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

What are Terraform outputs? See how Terraform handles and exports output values between modules and the different options for outputs configuration.

66-terraform_output

Terraform Outputs

In this post, I will explain what the <code class="jz ka kb kc kd b">terraform init</code> command is used for, what it does, and when to run it. I will explore the options available and give an example of when to use it in automation using Azure DevOps.

After writing your <a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a> code or cloning your existing Terraform code from source control, the <code class="jz ka kb kc kd b">terraform init</code> command is the first command you should use to initialize the working directory.

What does terraform init command do? See examples and quick usages. Learn how to init your infrastructure with Terraform.

When to Run Terraform Apply – Quick Usage Examples

Get the newsletter

Recent posts

Terraform .tfvars files: Variables Management with Examples

12 Terraform Best Practices to Improve your TF workflow

Terraform Cheat Sheet: Commands Reference & Useful Examples

Terraform Output Values : Complete Guide & Examples

Terraform Init – Command Overview with Quick Usage Examples

Terraform vs. AWS CloudFormation : The Ultimate Comparison

What are Terraform Templates? Basics, Use Cases, Examples

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

Terraform Locals: What Are They, How to Use Them [Examples]

How to Manage AWS Lambda Functions with Terraform: Tutorial

How to Debug & Troubleshoot Terraform Projects: Tutorial

How to Download & Install Terraform on Windows, Linux, Mac