Terraform Basics Week 3: Managing Variables with tfvars Files

Table of Contents

1. Recap of Week 2

2. What is a tfvars file, how do I create one and why should i use it ?

3. Handling Sensitive Values Safely

4. Variable Precedence in Terraform

5. Using .tfvars files instead of environment variables

6. Deploy to Azure – Testing the configuration using tfvars values

7. Wrap-Up

GitHub Link for this week's files

1. Recap of Week 2

Last week we introduced variables in Terraform and saw how they make our configuration more reusable. Instead of hard-coding values directly in resource blocks, we created a variables.tf file and referenced values using var.variable_name.
We also explored how to assign values via defaults and environment variables (for example TF_VAR_location).

By the end of Week 2 our project structure was cleaner and more scalable, but managing a growing number of values purely through environment variables can become cumbersome. That’s where .tfvars files come in ready to simplify things.

In case you missed last week's post, you can read the full Week 2 post here.

2. What is a tfvars file, how do i create one and why should i use it ?

A tfvars file is where you define the values for your variables, separate from your Terraform code. Instead of setting them through environment variables or typing them out every time you run a command, you can store everything in one place and let Terraform pick it up automatically.

Terraform looks for two files by default:

terraform.tfvars and any file ending with .auto.tfvars (more on this in upcoming weeks). If either of those exist in your working directory, Terraform automatically loads them when you run plan or apply.

So let's go back to our Week 2 setup and explain this with our example:

In order to utilize tfvars file instead of Environment Variables, you would have a variables.tf file, such as the one we had last week:

Then, you would create a file called terraform.tfvars under your project folder, like so :

As shown in the example, this is how you define values for the variables you created in your variables.tf file using the terraform.tfvars file.
Any value you set in terraform.tfvars overrides the variable’s default value if one is defined. The default value is only used when no other value is provided through a tfvars file, the CLI, or environment variables.

So why use it this way? Why not just set the values directly in the variable’s default attribute or continue using environment variables?

Because tfvars files offer much better flexibility and management at scale. Imagine having to create environment variables for a hundred different variables. Now imagine doing that across multiple Terraform environments where those values differ each time. Would you manually update or remove environment variables whenever you switch between environments?

The same challenge applies if you rely on default values. tfvars files solve this by letting you keep multiple versions for different purposes or environments. You can see all variable values for a given project in one place and manage them easily without touching your Terraform code.

3. Handling Sensitive Values Safely

When using tfvars files, you’ll often define values like usernames, passwords, or API keys. These are considered sensitive values, and Terraform provides a way to protect them from being displayed in your CLI output.

To do that, mark the variable as sensitive in your variables.tf file:

This prevents Terraform from printing the value in your plan or apply output. You’ll still see that a change is being made, but the actual value will be hidden.

It’s worth noting that Terraform still stores these values in the state file, but we'll go over how to secure those in upcoming weeks.

Marking sensitive variables like this helps keep your terminal output, logs, and collaboration history clean while still allowing Terraform to use the values during deployment.

4. Variable Precedence in Terraform

When Terraform runs, it can receive variable values from several places. If a variable is defined in more than one location, Terraform follows a specific order to decide which value to use. Understanding this order helps you predict how your configuration will behave and avoid confusion when values overlap.

From lowest to highest precedence:

1. Default values set inside the variable block

2. Values from terraform.tfvars or any *.auto.tfvars file

3. Values passed with the -var or -var-file flag

4. Environment variables that start with TF_VAR_

If a variable is defined in multiple places, Terraform always uses the one that appears later in this list.

For example, if your terraform.tfvars file contains:

but you have an environment variable defined as:

Terraform will use West Europe, because environment variables override tfvars files.

Knowing this order is especially helpful when troubleshooting unexpected values or testing changes without modifying your main configuration.

5. Using terraform.tfvars files instead of environment variables

We covered most of what needs to be done for this section in the previous sections actually. To start using terraform.tfvars for assigning values to your variables, create a terraform.tfvars file as described in section 2 and define the values you would like to use for each.

We also mentioned in variable precedence section that Environment Variables do override tfvars variables. So with that information, if you have Environment Variables defined from the previous weeks, make sure those no longer exist, in order to have your tfvars variables apply on your deployment.

I had these defined from previous weeks which I now deleted :

6. Deploy to Azure – Testing the configuration using tfvars values

1. As always - we start with terraform init :

1. Next we use terraform plan command. I'd like to highlight a few things on the plan output:

You can see that because we used sensitive = true attribute for admin_password variable, the value is not shown in the plan output. You can also see resource_group_name value is now rg-prod-002, which is what I had in my terraform.tfvars file and it's overwriting the default attribute that was defined for that variable in variables.tf file. Perfect, just as we expected.

1. Now that everything looks good - we go ahead and issue the terraform apply command.

After apply command ran for 1 minutes and 30 seconds, I could see in my Azure Tenant the VM is created with the appropriate values that we defined in terraform.tfvars :

1. Finally, don't forget to issue terraform destroy command so you don't generate unnecessary costs.

7. Wrap-Up

This week we replaced environment variables with a terraform.tfvars file and saw how much simpler it is to manage variable values this way. We learned how Terraform automatically reads that file, how its values override defaults, and how to handle sensitive variables safely.

With this setup, our configuration is cleaner, easier to maintain, and ready to scale. We no longer need to rely on environment variables every time we run a plan or apply.

Next week, we’ll build on this by improving the security of our deployment. We’ll add a Network Security Group to control access to the VM and use dynamic blocks to make our configuration more flexible.

I hope this was helpful to you and hope to see you next week for more Terraform fun!