We close the chapter on environment management by looking in detail at how values are passed to Terraform: .tfvars files and environment variables. We’ve already mentioned them in passing; now you’ll fully understand how to separate configuration (the values that change) from code (the logic that stays the same). This separation is key to managing environments cleanly.

Remember the variables from Chapter 10. A variable is a “placeholder” in your code that gets filled with a value from outside:

The code uses var.tipo_instancia, but does not set the value. Where does that value come from? There are several ways to provide it, and we’ll see them here.

A .tfvars file is a file where you assign values to variables. It’s the most common and organized way to configure an environment. For example:

Notice the key idea: the code is the same, but each .tfvars file gives it different values. This is exactly what allows you to use the same logic for multiple environments (subchapter 19.2).

You tell Terraform which values file to use with the -var-file option:

Special case — terraform.tfvars: if you name a file exactly terraform.tfvars, Terraform loads it automatically without you having to specify it. That’s why, in the directory strategy (subchapter 19.2), each environment folder usually has its own terraform.tfvars that is applied automatically.

Analogy: Terraform code is like a letter template with blanks (“Dear ___, your order ___ is ready”). The .tfvars files are the data that fill in the blanks for each recipient. One template, many personalized letters. You change the data, not the template.

Another way to provide values to variables is through operating system environment variables, using the TF_VAR_ prefix:

Terraform automatically reads any environment variable that starts with TF_VAR_ and assigns it to the corresponding variable (here, tipo_instancia).

When is this used? Mainly in two cases:

• In automation (CI/CD, Chapter 22): automated systems often pass values as environment variables, without files.
• For sensitive data (secrets): as we’ll see shortly, passwords and keys should not go in .tfvars files that are pushed to Git; environment variables are a way to pass them without writing them in any repository file.

Since there are several ways to provide values, Terraform follows an order of precedence if the same value is defined in multiple places (from lowest to highest priority, roughly):

You don’t need to memorize it, but remember: if you define a value in several places, the most specific/direct one wins. If in doubt, what you put on the command line overrides everything else.

This is critical. Your .tfvars files with normal configuration (sizes, names) can be safely stored in Git. But you should NEVER put sensitive data —database passwords, API keys, tokens— in .tfvars files that you push to the repository. If you do, those secrets are exposed in the Git history to anyone who accesses it.

The correct ways to handle secrets:

• Environment variables (TF_VAR_password), which are not stored in any repo file.
• Secrets managers like AWS Secrets Manager or Parameter Store (which we’ll see in Chapter 23): Terraform reads them at runtime, so the secret is never written in the code.
• Add .tfvars files with secrets to .gitignore so they are never pushed.

Also remember (from Chapter 11) that the state itself can contain sensitive data, so the remote backend must be encrypted and access-restricted. Secret management is a serious topic that we’ll revisit in depth in Chapter 23.

• Variables leave “blanks” in the code; values are provided from outside, separating configuration from code (the same logic works for multiple environments).
• .tfvars files are the main way to assign values; you use -var-file="environment.tfvars", and a file named terraform.tfvars is loaded automatically.
• Environment variables with the TF_VAR_ prefix are another way to pass values, useful in CI/CD and for secrets.
• There is an order of precedence when a value is defined in multiple places: the most direct wins (command line > environment > files > default).
• ⚠️ Critical security: never put secrets (passwords, keys) in .tfvars files versioned in Git. Use environment variables, secrets managers (Secrets Manager, Chapter 23), and .gitignore.

You’ve finished Chapter 19! You now know how to manage multiple environments cleanly and securely. In Chapter 20 we’ll dive deeper into one of the most important topics for teamwork: remote backends and state locking.