3 Common Mistakes with Terraform Variables (and How to Avoid Them)

Introduction

Terraform variables are powerful tools that make your infrastructure code dynamic, reusable, and easier to manage. However, they can also lead to confusion and errors if handled improperly. In this blog, we’ll look at three common mistakes people make when working with Terraform variables — and how to avoid them.

Mistake 1: Forgetting to Validate Inputs

Variables in Terraform allow you to accept different inputs, but what happens if someone passes an invalid value? Forgetting to validate inputs can lead to runtime errors or even misconfigured infrastructure.

variable "instance_type" {
  type = string
}
# Someone might pass an unsupported instance type:
# terraform apply -var="instance_type=t2.micro-large"

This error could have been caught early with validation.

The Fix: Use the validation block to enforce constraints on your variables.

variable "instance_type" {
  type    = string
  default = "t2.micro"

  validation {
    condition     = contains(["t2.micro", "t2.small", "t2.medium"], var.instance_type)
    error_message = "Invalid instance type. Allowed values are: t2.micro, t2.small, t2.medium."
  }
}

This ensures that only valid instance types are passed, reducing potential errors.

Mistake 2: Using Sensitive Variables Without Proper Security

Sensitive variables, such as API keys or database passwords, often contain secrets. If not handled carefully, these secrets can accidentally be exposed in logs or output.

Example:

variable "db_password" {
  type = string
}

output "password" {
  value = var.db_password
}

If you forget to mark the variable as sensitive, the password may appear in Terraform’s plan or log files, compromising security.

The Fix: Use the sensitive argument to protect sensitive variables.

variable "db_password" {
  type      = string
  sensitive = true
}

output "password" {
  value       = var.db_password
  sensitive   = true
}

This ensures sensitive values are hidden from logs and output, keeping them secure.

Mistake 3: Hardcoding Values Instead of Using Variables

Hardcoding values directly into your configuration defeats the purpose of using Terraform variables. It makes your code less reusable and harder to manage across environments.

Example:

resource "aws_instance" "example" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"
}

If you need to deploy this configuration in a different environment, you’ll have to manually edit these values every time.

The Fix: Use variables to make your code dynamic and reusable.

variable "ami" {
  type = string
}

variable "instance_type" {
  type    = string
  default = "t2.micro"
}

resource "aws_instance" "example" {
  ami           = var.ami
  instance_type = var.instance_type
}

Now, you can provide different values for ami and instance_type through .tfvars files or the CLI without modifying the code.

Conclusion

Terraform variables are an essential part of writing clean and reusable infrastructure code, but it’s easy to make mistakes if you’re not careful. By validating inputs, securing sensitive variables, and avoiding hardcoded values, you can create configurations that are both robust and maintainable.