DEV Community: Yency Christopher

Understanding Terraform Variables the Right Way published: true description: A beginner-friendly guide

Yency Christopher — Fri, 12 Dec 2025 01:31:38 +0000

variables.tf vs terraform.tfvars - What's the Difference?

If you're new to Terraform, you've probably seen both** variables.tf** and terraform.tfvars files and wondered: "Aren't they doing the same thing?"

Spoiler alert: They're not! Let me break it down in the simplest way possible.

The Quick Answer:

variables.tf = The template (declares WHAT variables exist)
terraform.tfvars = The configuration (provides the ACTUAL values)

Think of it this way:

variables.tf asks the questions
terraform.tfvars gives the answers

Real-World Analogy

Imagine you're ordering a custom pizza:
variables.tf (The Order Form)

variable "size" {
  description = "Pizza size"
  type        = string
  validation {
    condition     = contains(["small", "medium", "large"], var.size)
    error_message = "Size must be small, medium, or large"
  }
}

variable "toppings" {
  description = "Pizza toppings"
  type        = list(string)
  default     = ["cheese"]
}

variable "delivery_address" {
  description = "Where to deliver"
  type        = string
  # No default - this is required!
}

variable "phone" {
  description = "Contact number"
  type        = string
  default     = null  # Optional
}

terraform.tfvars (Your Filled Order)

size             = "large"
toppings         = ["pepperoni", "mushrooms", "olives"]
delivery_address = "123 Main Street, Apt 4B"
phone            = "555-1234"

The restaurant keeps the same order form (variables.tf) for everyone, but YOUR specific order (terraform.tfvars) is unique to you!

Deep Dive: variables.tf
Purpose: Declares the structure and rules for variables

variable "subscription_id" {
  description = "Azure Subscription ID"
  type        = string
  sensitive   = true  # Won't show in logs
}

variable "vm_name" {
  description = "Name of the Virtual Machine"
  type        = string
  default     = "ubuntu-vm"  # Optional default value
}

variable "vm_size" {
  description = "VM size"
  type        = string
  default     = "Standard_B2s"

  validation {
    condition     = can(regex("^Standard_", var.vm_size))
    error_message = "VM size must start with 'Standard_'"
  }
}

variable "allowed_ips" {
  description = "Allowed IP addresses"
  type        = list(string)
  default     = []
}

What it contains:

Variable name
Type (string, number, bool, list, map, object)
Description (documentation)
Default value (optional)
Validation rules (optional)
Sensitive flag (optional)

Think of it as: The schema, the blueprint, the contract

Deep Dive: terraform.tfvars
Purpose: Provides actual values for your infrastructure

subscription_id = "12345678-1234-1234-1234-123456789abc"
vm_name         = "production-web-server"
vm_size         = "Standard_D4s_v3"
allowed_ips     = ["203.0.113.0/24", "198.51.100.0/24"]

What it contains:

Just the values!
No types, no descriptions, no validation
Your specific configuration

Think of it as: The actual data, your answers, the configuration

Why This Separation?
1. Reusability Across Environments
Keep the same variables.tf, but use different values files:
my-terraform-project/
├── variables.tf # Same for all environments
├── main.tf # Same for all environments
├── dev.tfvars # Dev-specific values
├── staging.tfvars # Staging-specific values
└── prod.tfvars # Production-specific values

Deploy to different environments:
terraform apply -var-file="dev.tfvars" # Deploy to dev
terraform apply -var-file="staging.tfvars" # Deploy to staging
terraform apply -var-file="prod.tfvars" # Deploy to production

2. Security & Git Management
**.gitignore
**terraform.tfvars # Contains secrets - DON'T COMMIT
*.auto.tfvars # Contains secrets - DON'T COMMIT

Safe to commit
variables.tf # Just the template
terraform.tfvars.example # Example with fake values

Example file to commit:
terraform.tfvars.example
subscription_id = "YOUR_SUBSCRIPTION_ID_HERE"
vm_name = "your-vm-name-here"
vm_size = "Standard_B2s"

3. Type Safety & Validation
variables.tf enforces rules:

variable "environment" {
  type = string
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod"
  }
}

variable "vm_count" {
  type = number
  validation {
    condition     = var.vm_count >= 1 && var.vm_count <= 10
    error_message = "VM count must be between 1 and 10"
  }
}

If you try to pass invalid values in terraform.tfvars, Terraform will catch it!

The Complete Flow

Image description

Alternative Ways to Provide Values
You don't HAVE to use terraform.tfvars. Here are your options:

Option 1: terraform.tfvars (Recommended ✅)

terraform apply
# Automatically reads terraform.tfvars

Option 2: Custom .tfvars file

terraform apply -var-file="production.tfvars"

Option 3: Command-line flags

terraform apply -var="vm_name=my-vm" -var="location=East US"
# Gets tedious with many variables!

Option 4: Environment variables

export TF_VAR_vm_name="my-vm"
export TF_VAR_location="East US"
terraform apply

Option 5: Interactive prompts

terraform apply
# Terraform prompts you:
# var.vm_name
#   Enter a value: _

Best Practices

**
✅ DO:

Always create variables.tf - it's your documentation
Use terraform.tfvars for local development
Create terraform.tfvars.example with dummy values to commit
Use separate .tfvars files per environment
Add terraform.tfvars to*.gitignore*
Use descriptive variable names and descriptions
Set reasonable defaults where appropriate
Use validation rules for critical variables

❌ DON'T:

Commit terraform.tfvars with real secrets to Git
Put actual values in variables.tf (except defaults)
Use the same values across all environments
Skip variable descriptions
Forget to document required variables

Image description

Practical Example

💻
Let's say you're deploying Azure VMs with Terraform:
variables.tf

variable "subscription_id" {
  description = "Azure Subscription ID"
  type        = string
  sensitive   = true
}

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

variable "location" {
  description = "Azure region"
  type        = string
  default     = "East US"
}

variable "vm_size" {
  description = "Size of the VM"
  type        = string
  default     = "Standard_B2s"
}

variable "environment" {
  description = "Environment (dev/staging/prod)"
  type        = string

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Must be dev, staging, or prod"
  }
}

dev.tfvars

subscription_id     = "dev-subscription-id-here"
resource_group_name = "rg-myapp-dev"
location            = "East US"
vm_size             = "Standard_B2s"  # Smaller for dev
environment         = "dev"

prod.tfvars

subscription_id     = "prod-subscription-id-here"
resource_group_name = "rg-myapp-prod"
location            = "East US"
vm_size             = "Standard_D4s_v3"  # Larger for prod
environment         = "prod"

Deploy:

terraform apply -var-file="dev.tfvars"   # For development
terraform apply -var-file="prod.tfvars"  # For production

Conclusion

🎓
Remember the golden rule:

variables.tf = The questions (template/schema)
terraform.tfvars = The answers (your specific values)

This separation gives you:

✅ Reusable code across environments
✅ Better security (secrets not in code)
✅ Type safety and validation
✅ Clear documentation
✅ Team collaboration

Now go forth and Terraform with confidence! 🚀

Found this helpful? Give it a ❤️ and follow me for more DevOps and Cloud content!
Questions? Drop them in the comments below! 👇

https://www.codegenes.net/blog/best-practices-when-using-terraform-is-there-any-official-guide-to-it/

Building Azure Infrastructure with Terraform: A Complete Guide

Yency Christopher — Tue, 09 Dec 2025 15:49:34 +0000

Introduction
Terraform lets you write configuration files that create cloud resources. Instead of clicking through Azure's portal, you define what you want in code, and Terraform builds it.
This guide walks through deploying a Linux VM on Azure with proper networking and security. We'll start with basic resources, then reorganize everything into reusable modules that work across different projects.

What We'll Build
The Terraform code creates these Azure resources:
Resource Group - Container for organizing resources
Virtual Network (VNet) + Subnet - Private network for your resources
Network Security Group (NSG) - Firewall rules
Public IP Address - So you can connect from the internet
Network Interface (NIC) - Connects the VM to the network
Linux Virtual Machine - Ubuntu server with SSH access

Understanding the Variables
These variables let you customize the deployment without changing the main code:

Important: Setting my_ip_cidr to 0.0.0.0/0 lets anyone try to SSH in. Always use your specific IP with /32.

The Infrastructure Code Explained

Resource Group

resource "azurerm_resource_group" "rg" {
  name     = "rg-terraform-demo"
  location = var.location
}

The Resource Group is a container for all your Azure resources. Using var.location instead of hardcoding the region means you can deploy to different locations without editing the code.
Tip: Use naming like rg-${var.project}-${var.env} to separate dev, staging, and prod environments.

2. Virtual Network (VNet)

resource "azurerm_virtual_network" "vnet" {
  name                = "vnet-demo"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

The VNet defines your private IP address space. The 10.0.0.0/16 range gives you 65,536 IP addresses.

When you reference azurerm_resource_group.rg.location, Terraform knows it needs to create the Resource Group first. You don't have to specify the order—Terraform figures it out.

Tip: Pick an address space that won't overlap with other VNets you might connect to later. Use variables for address spaces when building reusable modules.

3. Subnet

resource "azurerm_subnet" "subnet" {
  name                 = "subnet-demo"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = ["10.0.1.0/24"]
}

Subnets divide your VNet into smaller segments. The 10.0.1.0/24 prefix gives you 256 IP addresses.
Note: We're attaching the NSG to the NIC in this guide, but you can also attach NSGs at the subnet level to protect all resources in that subnet at once.

4. Network Security Group (NSG)

resource "azurerm_network_security_group" "nsg" {
  name                = "nsg-demo"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

The NSG acts as a firewall. By itself, it's just a container the actual rules come next.

5. NSG Rule: SSH Access

resource "azurerm_network_security_rule" "ssh" {
  name                        = "Allow-SSH"
  priority                    = 1001
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = "22"
  source_address_prefix       = var.my_ip_cidr
  destination_address_prefix  = "*"
  resource_group_name         = azurerm_resource_group.rg.name
  network_security_group_name = azurerm_network_security_group.nsg.name
}

This rule allows SSH traffic (port 22) from your IP address.
What the fields mean:

priority (1001): Rules run from lowest to highest number (100-4096). Lower numbers go first.
direction: Inbound controls incoming traffic; Outbound controls outgoing.
source_address_prefix: var.my_ip_cidr restricts SSH to only your IP.

For production: Don't expose SSH publicly. Use Azure Bastion or a jumpbox instead.

6. Public IP Address

resource "azurerm_public_ip" "pip" {
  name                = "pip-demo"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  allocation_method   = "Dynamic"
}

The Public IP lets you connect to your VM from the internet. Dynamic allocation assigns an IP when the resource starts; Static reserves a fixed IP.
Production note: Avoid public IPs in production. Use private IPs with VPN, ExpressRoute, or Azure Bastion. If you need a fixed IP for DNS or firewall rules, use allocation_method = "Static".

7. Network Interface (NIC)

resource "azurerm_network_interface" "nic" {
  name                = "nic-demo"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  ip_configuration {
    name                          = "ipconfig"
    subnet_id                     = azurerm_subnet.subnet.id
    private_ip_address_allocation = "Dynamic"
    public_ip_address_id          = azurerm_public_ip.pip.id
  }

  network_security_group_id = azurerm_network_security_group.nsg.id
}

The NIC connects your VM to the network. This config:

Attaches to the subnet with subnet_id
Associates the public IP with public_ip_address_id
Applies NSG rules with network_security_group_id

The .id attribute returns the unique Azure resource identifier. Terraform uses these to figure out what order to create things.

8. Linux Virtual Machine

resource "azurerm_linux_virtual_machine" "vm" {
  name                = "vm-demo"
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  size                = var.vm_size
  admin_username      = var.admin_username
  network_interface_ids = [azurerm_network_interface.nic.id]

  admin_ssh_key {
    username   = var.admin_username
    public_key = file(var.ssh_public_key_path)
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "UbuntuServer"
    sku       = "22_04-lts"
    version   = "latest"
  }
}

Key parts:

admin_ssh_key: The file() function reads your SSH public key and sets up authentication. Use the absolute path like /home/you/.ssh/id_rsa.pub—Terraform doesn't expand ~.
os_disk: Standard_LRS is locally redundant storage. For better performance, use Premium_LRS or StandardSSD_LRS.
source_image_reference: This pulls Ubuntu 22.04 LTS from Canonical. version = "latest" always grabs the newest image.

Production tip: Pin the image version to a specific build or use managed images so you get the same version every time.

How Terraform Manages Dependencies

Terraform builds a dependency graph based on references in your code. When you reference azurerm_resource_group.rg.name or .id, Terraform knows that the resource needs to exist first.

Order of creation:
Resource Group → VNet → Subnet → Public IP & NSG → NIC → VM
You don't need to manually specify the order Terraform figures it out.

Configuration Files
variables.tf

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

variable "my_ip_cidr" {
  description = "Your public IP or CIDR to allow SSH (e.g. 203.0.113.4/32)"
  type        = string
  default     = "0.0.0.0/0"
}

variable "vm_size" {
  description = "Size of the VM"
  type        = string
  default     = "Standard_B1s"
}

variable "admin_username" {
  description = "Username for admin user"
  type        = string
  default     = "azureuser"
}

variable "ssh_public_key_path" {
  description = "Absolute path to SSH public key file"
  type        = string
  default     = "/home/you/.ssh/id_rsa.pub"
}

terraform.tfvars (Example)

location = "eastus"
my_ip_cidr = "203.0.113.4/32"
vm_size = "Standard_B1s"
admin_username = "azureuser"
ssh_public_key_path = "/home/you/.ssh/id_rsa.pub"

Security Warning: Never commit terraform.tfvars with real secrets to version control. Add it to .gitignore immediately.

Running Your Terraform Code
Execute these commands in your project directory:

# Initialize Terraform (downloads provider plugins)
terraform init

# Validate syntax and configuration
terraform validate

# Preview changes before applying
terraform plan -out=tfplan

# Apply the changes
terraform apply tfplan

# Or apply directly with auto-approval
terraform apply --auto-approve

Cleanup:

terraform destroy --auto-approve

Best Practices & Security
Security

1.Lock Down SSH Access: Set my_ip_cidr to** /32*. Run curl ifconfig.me* to find your public IP.

2.Use Azure Bastion: For production, use Azure Bastion instead of public IPs for secure, browser-based access.

3.Never Commit Secrets: Add terraform.tfvars and *.tfstate to .gitignore. Use remote state storage for teams.

Code Quality

4.Use Variables: Parameterize locations, sizes, names, and tags so you can reuse code.
5.Tag Everything: Add tags for cost tracking:

tags = {
     owner       = "you"
     environment = var.env
     project     = "demo"
   }

Format and Validate: Run terraform fmt and terraform validate before committing. Set up pre-commit hooks.

Team Collaboration

Remote State: Use Azure Storage backend with state locking to avoid conflicts.
Least-Privilege Service Principals: For CI/CD, only grant necessary permissions (e.g., Resource Group Contributor, not Subscription Owner). 9.Use Modules: Split code into reusable modules (modules/network, modules/compute).

Operations

10.Avoid Provisioners: Use cloud-init or Ansible instead of Terraform's provisioner blocks.
11.Pin Provider Versions: Lock provider versions in your terraform block to prevent breaking changes.
12.Monitor Resources: Enable Azure Monitor and diagnostics for production workloads.

Next Steps: Building Production-Ready Modules

**
Here's how to reorganize this into a scalable setup.
Project Structure

Why Use This Structure

Reusability: Use modules across dev, staging, and production
Separation: Network and compute teams can work independently
Testing: Test modules separately before combining them
Versioning: Version and publish stable modules to a registry

VS Code Integration
With VS Code tasks, you can run Terraform commands with one click:
1.Open Command Palette (Ctrl+Shift+P)
2.Select "Tasks: Run Task"
3.Choose: Init, Validate, Plan, Apply, or Destroy

No more typing the same commands over and over.

Advanced Improvements

Once you're comfortable with the basics:
1.Add Outputs: Export public IPs and resource IDs for other modules or documentation.
2.Use Azure Key Vault: Store secrets securely and access them with managed identities.
3.Enable Monitoring: Deploy Azure Monitor agents and set up Log Analytics.
4.Multiple Environments: Use Terraform workspaces or separate tfvars files for dev/staging/prod.
5.Set Up CI/CD: Run terraform plan on pull requests and terraform apply after approval.
6.Implement Azure Bastion: Remove all public IPs and direct SSH access.

Conclusion

You now have the basics for managing Azure infrastructure with Terraform. This guide covered networking, security, and compute resources, organized into a maintainable structure.
Key takeaways:

Use variables to make code reusable
Lock down security by restricting IP access
Use modules for better organization
Never commit secrets to version control
Use remote state for teams

The modular setup will scale as you add more resources and environments. Start simple, automate early, and improve as you go.
Ready to deploy? Update terraform.tfvars with your values and run terraform apply.