What are variables in Terraform? -

In the world of Infrastructure as Code (IaC), Terraform has emerged as the de facto standard for defining, provisioning, and managing cloud resources across multiple providers. When working with Microsoft Azure, Terraform enables developers and operations teams to create reproducible, version-controlled infrastructure deployments. At the heart of every maintainable and scalable Terraform configuration lies a well-designed variable strategy.

Variables in Terraform are much more than simple placeholders for values—they are the fundamental building blocks that enable parameterization, reuse, security, and collaboration across infrastructure code. Whether you’re deploying a simple virtual network or a complex multi-region Kubernetes cluster on Azure, understanding how to effectively use variables will transform your Terraform practice from basic scripting to professional-grade infrastructure engineering.

This comprehensive guide will take you through every aspect of Terraform variables specifically in the context of Azure cloud deployments. We’ll explore not just the syntax but the architecture, security implications, and best practices that separate novice configurations from enterprise-ready infrastructure code.

Table of Contents

Understanding the Role of Variables in Terraform

What Are Terraform Variables?

Terraform variables are named parameters that allow you to customize your infrastructure configurations without modifying the core code. Think of them as the configuration settings for your infrastructure deployment. They serve several critical purposes:

Parameterization: Allow the same configuration to be deployed with different values
Reusability: Enable configurations to be shared across teams and projects
Security: Protect sensitive information like passwords and API keys
Maintainability: Separate configuration from implementation logic
Collaboration: Provide clear interfaces between different modules and teams

Variables vs. Other Terraform Concepts

It’s important to distinguish variables from other Terraform constructs:

Variables (Inputs): Parameters passed into configurations
Outputs: Values returned from configurations or modules
Locals: Intermediate values computed within configurations
Data Sources: Information fetched from existing infrastructure

While outputs expose information from your configuration, variables bring information into your configuration. Locals help with internal computation but aren’t exposed to users.

Deep Dive into Variable Types and Syntax

Basic Variable Declaration

At its simplest, a variable declaration in Terraform consists of a variable block:

hcl

variable "resource_group_name" {
  description = "The name of the Azure Resource Group"
  type        = string
  default     = "my-resource-group"
}

This declaration creates a variable named resource_group_name that expects a string value and has a default value if none is provided.

Type System in Terraform Variables

Terraform’s type system is rich and expressive, allowing you to enforce structure on your variables:

Primitive Types

hcl

# String
variable "location" {
  type    = string
  default = "eastus"
}

# Number
variable "vm_count" {
  type    = number
  default = 2
}

# Boolean
variable "enable_monitoring" {
  type    = bool
  default = true
}

Complex Types

hcl

# List
variable "subnet_prefixes" {
  type    = list(string)
  default = ["10.0.1.0/24", "10.0.2.0/24"]
}

# Map
variable "common_tags" {
  type = map(string)
  default = {
    Environment = "dev"
    Project     = "azure-terraform"
    CostCenter  = "12345"
  }
}

# Set
variable "security_groups" {
  type    = set(string)
  default = ["sg-web", "sg-database"]
}

Structural Types

hcl

# Object
variable "network_config" {
  type = object({
    vnet_name     = string
    address_space = string
    subnets       = list(object({
      name           = string
      address_prefix = string
    }))
  })
}

# Tuple
variable "ip_configuration" {
  type = tuple([string, number, bool])
}

Advanced Variable Features

Validation Rules

Terraform allows you to define validation rules for your variables:

hcl

variable "vm_size" {
  description = "Azure VM size"
  type        = string
  default     = "Standard_B1s"

  validation {
    condition     = can(regex("^(Standard|Basic)_[A-Za-z0-9]+$", var.vm_size))
    error_message = "The VM size must be a valid Azure VM size starting with Standard_ or Basic_."
  }
}

variable "instance_count" {
  description = "Number of VM instances"
  type        = number
  default     = 1

  validation {
    condition     = var.instance_count >= 1 && var.instance_count <= 10
    error_message = "Instance count must be between 1 and 10."
  }
}

Sensitive Variables

For security-sensitive values, mark variables as sensitive:

hcl

variable "admin_password" {
  description = "Administrator password for the VM"
  type        = string
  sensitive   = true
}

variable "service_principal" {
  type = object({
    client_id     = string
    client_secret = string
    tenant_id     = string
  })
  sensitive = true
}

Sensitive variables are redacted from Terraform’s output, helping to protect secrets from being exposed in logs or UI.

Nullable Variables

Control whether a variable can be set to null:

hcl

variable "custom_dns_servers" {
  type     = list(string)
  default  = null
  nullable = true
}

Azure-Specific Variable Patterns

Common Azure Configuration Variables

When working with Azure, certain variables appear in almost every configuration:

hcl

# Provider configuration
variable "subscription_id" {
  description = "Azure subscription ID"
  type        = string
}

variable "tenant_id" {
  description = "Azure tenant ID"
  type        = string
}

# Resource naming and organization
variable "resource_group_name" {
  description = "Name of the Azure resource group"
  type        = string
}

variable "location" {
  description = "Azure region for resources"
  type        = string
  default     = "eastus"
}

# Networking
variable "vnet_address_space" {
  description = "Address space for the virtual network"
  type        = list(string)
  default     = ["10.0.0.0/16"]
}

# Tags
variable "tags" {
  description = "Tags to apply to all resources"
  type        = map(string)
  default     = {}
}

Complex Azure Configuration Objects

For more complex deployments, structured variables are essential:

hcl

variable "virtual_machine_config" {
  description = "Configuration for Azure Virtual Machines"
  type = object({
    name                 = string
    size                 = string
    admin_username       = string
    storage_account_type = string
    os_disk = object({
      caching              = string
      storage_account_type = string
    })
    source_image_reference = object({
      publisher = string
      offer     = string
      sku       = string
      version   = string
    })
    network_interface_ids = list(string)
  })
}

variable "aks_config" {
  description = "Azure Kubernetes Service configuration"
  type = object({
    name                = string
    kubernetes_version  = string
    node_count          = number
    vm_size             = string
    os_disk_size_gb     = number
    network_plugin      = string
    service_cidr        = string
    dns_service_ip      = string
    docker_bridge_cidr  = string
  })
}

Variable Files and Precedence

Organizing Variable Files

Terraform supports multiple ways to provide variable values:

terraform.tfvars – Automatically loaded if present
terraform.tfvars.json – JSON format version
.auto.tfvars – Automatically loaded files
Command-line flags – Using -var or -var-file
Environment variables – Prefixed with TF_VAR_

A typical file structure might look like:

text

📁 infrastructure/
├── 📁 modules/
│   └── 📁 network/
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf
├── 📁 environments/
│   ├── 📁 dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── dev.tfvars
│   ├── 📁 prod/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── prod.tfvars
├── versions.tf
└── provider.tf

Example Variable Files

terraform.tfvars:

hcl

location            = "eastus"
environment         = "dev"
vm_count            = 2
enable_accelerated_networking = true

tags = {
  Environment = "development"
  Team        = "platform-engineering"
  CostCenter  = "12345"
}

environments/prod/prod.tfvars:

hcl

location            = "westus2"
environment         = "prod"
vm_count            = 5
enable_accelerated_networking = true

tags = {
  Environment = "production"
  Team        = "platform-engineering"
  CostCenter  = "67890"
  SLA         = "99.95%"
}

Variable Precedence

Terraform loads variables in a specific order, with later sources taking precedence:

Environment variables
terraform.tfvars
terraform.tfvars.json
*.auto.tfvars or *.auto.tfvars.json
-var and -var-file command line options

This allows you to set sensible defaults while still overriding them for specific environments.

Working with Variables in Azure Configurations

Using Variables in Resource Definitions

Here’s how variables integrate with Azure resource definitions:

hcl

# Configure the Azure provider
provider "azurerm" {
  features {}
  subscription_id = var.subscription_id
  tenant_id       = var.tenant_id
}

# Create resource group
resource "azurerm_resource_group" "main" {
  name     = var.resource_group_name
  location = var.location
  tags     = var.tags
}

# Create virtual network
resource "azurerm_virtual_network" "main" {
  name                = "vnet-${var.environment}-${var.location}"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  address_space       = var.vnet_address_space
  tags                = var.tags
}

# Create subnets using complex variable
resource "azurerm_subnet" "subnets" {
  for_each = { for idx, subnet in var.subnet_configs : subnet.name => subnet }

  name                 = each.value.name
  resource_group_name  = azurerm_resource_group.main.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = [each.value.address_prefix]
}

Dynamic Configurations with Variables

Variables enable dynamic infrastructure patterns:

hcl

# Conditionally create resources
resource "azurerm_network_security_group" "main" {
  count = var.create_network_security_group ? 1 : 0

  name                = "nsg-${var.environment}"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  tags                = var.tags

  dynamic "security_rule" {
    for_each = var.network_security_rules
    content {
      name                       = security_rule.value.name
      priority                   = security_rule.value.priority
      direction                  = security_rule.value.direction
      access                     = security_rule.value.access
      protocol                   = security_rule.value.protocol
      source_port_range          = security_rule.value.source_port_range
      destination_port_range     = security_rule.value.destination_port_range
      source_address_prefix      = security_rule.value.source_address_prefix
      destination_address_prefix = security_rule.value.destination_address_prefix
    }
  }
}

Advanced Variable Techniques

Variable Transformations with Locals

While variables bring data in, locals help transform that data:

hcl

# Variables
variable "environment" {
  type    = string
  default = "dev"
}

variable "project_name" {
  type    = string
  default = "myapp"
}

variable "instance_number" {
  type    = number
  default = 1
}

# Locals for transformed values
locals {
  # Standardized naming convention
  resource_name_prefix = "${var.project_name}-${var.environment}"
  
  # Environment-specific configurations
  environment_settings = {
    dev = {
      vm_size      = "Standard_B1s"
      node_count   = 1
      auto_shutdown = true
    }
    prod = {
      vm_size      = "Standard_D2s_v3"
      node_count   = 3
      auto_shutdown = false
    }
  }
  
  # Merge common tags with environment-specific tags
  merged_tags = merge(
    var.common_tags,
    {
      Environment = var.environment
      Deployment  = formatdate("YYYY-MM-DD hh:mm:ss", timestamp())
    }
  )
  
  # Current settings based on environment
  current_env_settings = local.environment_settings[var.environment]
}

# Using locals in resources
resource "azurerm_virtual_machine" "main" {
  name                  = "${local.resource_name_prefix}-vm-${var.instance_number}"
  location              = azurerm_resource_group.main.location
  resource_group_name   = azurerm_resource_group.main.name
  vm_size               = local.current_env_settings.vm_size
  tags                  = local.merged_tags
  
  # ... other configuration
}

Variable Dependency Management

Variables can reference other variables, but with limitations:

hcl

# This won't work - variables can't reference other variables
variable "vnet_name" {
  default = "vnet-${var.environment}" # Error!
}

# Instead, use locals
variable "environment" {
  default = "dev"
}

locals {
  vnet_name = "vnet-${var.environment}" # This works
}

Security Considerations for Azure Variables

Managing Secrets in Azure Deployments

When working with Azure, you’ll often need to handle sensitive information:

hcl

# Option 1: Mark as sensitive (basic protection)
variable "admin_password" {
  type      = string
  sensitive = true
}

# Option 2: Use Azure Key Vault with Terraform
data "azurerm_key_vault" "main" {
  name                = var.key_vault_name
  resource_group_name = var.resource_group_name
}

data "azurerm_key_vault_secret" "admin_password" {
  name         = "vm-admin-password"
  key_vault_id = data.azurerm_key_vault.main.id
}

# Then reference in configuration
resource "azurerm_virtual_machine" "main" {
  # ...
  os_profile {
    computer_name  = "hostname"
    admin_username = "adminuser"
    admin_password = data.azurerm_key_vault_secret.admin_password.value
  }
}

Service Principal Authentication

For automation, use Azure Service Principals with variables:

hcl

variable "arm_client_id" {
  description = "Azure Service Principal Client ID"
  type        = string
}

variable "arm_client_secret" {
  description = "Azure Service Principal Client Secret"
  type        = string
  sensitive   = true
}

variable "arm_tenant_id" {
  description = "Azure Tenant ID"
  type        = string
}

variable "arm_subscription_id" {
  description = "Azure Subscription ID"
  type        = string
}

# Configure Azure provider with variables
provider "azurerm" {
  features {}
  
  client_id       = var.arm_client_id
  client_secret   = var.arm_client_secret
  tenant_id       = var.arm_tenant_id
  subscription_id = var.arm_subscription_id
}

Testing and Validation Strategies

Pre-apply Validation

Use variable validation to catch errors early:

hcl

variable "sql_server_version" {
  description = "Azure SQL Server version"
  type        = string
  default     = "12.0"

  validation {
    condition     = can(regex("^(12.0|13.0)$", var.sql_server_version))
    error_message = "The SQL Server version must be either 12.0 or 13.0."
  }
}

variable "storage_account_tier" {
  description = "Azure Storage Account tier"
  type        = string
  default     = "Standard"

  validation {
    condition     = contains(["Standard", "Premium"], var.storage_account_tier)
    error_message = "The storage account tier must be either Standard or Premium."
  }
}

Custom Validation Functions

For complex validation, use custom conditions:

hcl

variable "ip_address" {
  description = "IP address for NSG rule"
  type        = string
  default     = "192.168.1.1"

  validation {
    condition     = can(cidrhost("${var.ip_address}/32", 0))
    error_message = "Must be a valid IPv4 address."
  }
}

variable "cidr_block" {
  description = "CIDR block for subnet"
  type        = string
  default     = "10.0.1.0/24"

  validation {
    condition     = can(regex("^([0-9]{1,3}\\.){3}[0-9]{1,3}/([0-9]|[1-2][0-9]|3[0-2])$", var.cidr_block))
    error_message = "Must be a valid CIDR block notation."
  }
}

Module Variables and Interface Design

Creating Reusable Azure Modules

Well-designed variables are key to creating reusable modules:

modules/network/variables.tf:

hcl

variable "vnet_name" {
  description = "Name of the virtual network"
  type        = string
}

variable "resource_group_name" {
  description = "Name of the resource group"
  type        = string
}

variable "location" {
  description = "Azure region"
  type        = string
}

variable "address_space" {
  description = "The address space that is used by the virtual network"
  type        = list(string)
  default     = ["10.0.0.0/16"]
}

variable "subnets" {
  description = "List of subnets to create"
  type = list(object({
    name           = string
    address_prefix = string
    service_endpoints = list(string)
  }))
  default = []
}

variable "tags" {
  description = "Tags to apply to all resources"
  type        = map(string)
  default     = {}
}

modules/network/main.tf:

hcl

resource "azurerm_virtual_network" "this" {
  name                = var.vnet_name
  resource_group_name = var.resource_group_name
  location            = var.location
  address_space       = var.address_space
  tags                = var.tags
}

resource "azurerm_subnet" "this" {
  for_each = { for subnet in var.subnets : subnet.name => subnet }

  name                 = each.value.name
  resource_group_name  = var.resource_group_name
  virtual_network_name = azurerm_virtual_network.this.name
  address_prefixes     = [each.value.address_prefix]
  service_endpoints    = each.value.service_endpoints
}

Calling Modules with Variables

main.tf:

hcl

module "network" {
  source = "./modules/network"

  vnet_name           = "vnet-${var.environment}"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  address_space       = var.vnet_address_space

  subnets = [
    {
      name           = "subnet1"
      address_prefix = "10.0.1.0/24"
      service_endpoints = ["Microsoft.Storage", "Microsoft.Sql"]
    },
    {
      name           = "subnet2"
      address_prefix = "10.0.2.0/24"
      service_endpoints = ["Microsoft.Storage"]
    }
  ]

  tags = merge(var.tags, {
    Module = "network"
  })
}

Troubleshooting Variable Issues

Common Problems and Solutions

Type Mismatch ErrorstextError: Incorrect attribute value typeSolution: Ensure variable values match the declared type
Validation FailurestextError: Invalid value for variableSolution: Check validation conditions and provide compliant values
Undefined VariablestextError: No value for required variableSolution: Provide a value through .tfvars files, environment variables, or CLI flags
Sensitive Variable Exposuretext[sensitive value] in plan outputSolution: This is expected behavior—sensitive values are redacted

Debugging Techniques

Use Terraform’s debugging capabilities:

bash

# See all variables that would be used
terraform plan -var-file="dev.tfvars"

# Debug variable loading
export TF_LOG=DEBUG
terraform plan

# Output specific variable values (non-sensitive)
output "debug_vnet_config" {
  value = var.vnet_config
}

Conclusion: Building Mature Azure Infrastructure with Terraform Variables

Mastering Terraform variables is essential for building professional-grade infrastructure on Azure. Variables transform static configurations into dynamic, reusable, and collaborative codebases. By implementing the patterns and best practices covered in this guide, you can:

Create reusable configurations that work across environments
Enforce compliance and standards through validation rules
Protect sensitive information with proper security measures
Build modular architectures with clear interfaces
Enable team collaboration through well-documented variables

Remember that variable design is an iterative process. Start with simple variables and gradually introduce more complex types and validation as your infrastructure needs evolve. The investment in proper variable design pays dividends in maintainability, security, and team productivity.

As you continue your Terraform journey on Azure, keep exploring advanced patterns like dynamic variable generation, variable transformation pipelines, and integration with Azure DevOps services. The combination of Terraform’s powerful variable system with Azure’s comprehensive cloud services creates a robust foundation for managing infrastructure at any scale.

Devraj Sarkar

Cybersecurity Architect | Cloud-Native Defense | AI/ML Security | DevSecOps

With over 23 years of experience in cybersecurity, I specialize in building resilient, zero-trust digital ecosystems across multi-cloud (AWS, Azure, GCP) and Kubernetes (EKS, AKS, GKE) environments. My journey began in network security—firewalls, IDS/IPS—and expanded into Linux/Windows hardening, IAM, and DevSecOps automation using Terraform, GitLab CI/CD, and policy-as-code tools like OPA and Checkov.

Today, my focus is on securing AI/ML adoption through MLSecOps, protecting models from adversarial attacks with tools like Robust Intelligence and Microsoft Counterfit. I integrate AISecOps for threat detection (Darktrace, Microsoft Security Copilot) and automate incident response with forensics-driven workflows (Elastic SIEM, TheHive).

Whether it’s hardening cloud-native stacks, embedding security into CI/CD pipelines, or safeguarding AI systems, I bridge the gap between security and innovation—ensuring defense scales with speed.

Let’s connect and discuss the future of secure, intelligent infrastructure.