Microsoft Azure — Terraform on Azure

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers terraform on azure with production-ready configurations, best practices, and hands-on examples.

Why Terraform on Azure?

Terraform is the de facto standard for infrastructure as code (IaC) on Azure. Unlike ARM templates or Bicep, Terraform provides a cloud-agnostic workflow, state management, and a mature module ecosystem. For teams managing multi-cloud or hybrid environments, Terraform reduces cognitive overhead by using a single language (HCL) across providers. Azure's native tools are powerful but lock you into Microsoft's ecosystem. Terraform gives you portability without sacrificing depth—AzureRM provider supports virtually every Azure resource. Production teams choose Terraform for its plan/apply cycle, drift detection, and integration with CI/CD pipelines. If you're already using Terraform for AWS or GCP, adding Azure is straightforward. If you're Azure-only, Terraform still wins on flexibility and community modules.

terraform {
  required_version = ">= 1.5"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">= 3.0"
    }
  }
}

provider "azurerm" {
  features {}
}

Setting Up Authentication for Azure

Terraform needs to authenticate to Azure. The recommended approach for production is service principal authentication with a client secret or certificate. Avoid using interactive login or managed identities for local development—they don't work well in CI/CD. Create a service principal with az ad sp create-for-rbac and assign it Contributor or custom role at the subscription or resource group scope. Store secrets in a vault (Azure Key Vault, HashiCorp Vault, or CI/CD secrets). For local dev, use environment variables: ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_SUBSCRIPTION_ID, ARM_TENANT_ID. Never hardcode secrets in files. Use az login only for quick tests; it's not repeatable.

az ad sp create-for-rbac --name "terraform-sp" --role Contributor --scopes /subscriptions/$(az account show --query id -o tsv)
# Output:
# {
#   "appId": "00000000-0000-0000-0000-000000000000",
#   "displayName": "terraform-sp",
#   "password": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
#   "tenant": "00000000-0000-0000-0000-000000000000"
# }

export ARM_CLIENT_ID="<appId>"
export ARM_CLIENT_SECRET="<password>"
export ARM_SUBSCRIPTION_ID="<subscriptionId>"
export ARM_TENANT_ID="<tenant>"

Structuring Terraform Configurations for Azure

A well-structured Terraform project is essential for maintainability. Use a modular approach: separate root modules for environments (dev, staging, prod) and reusable child modules for resources (networking, compute, databases). Each module should have clear inputs and outputs. For Azure, group resources by lifecycle and dependency. For example, a networking module creates VNet, subnets, NSGs, and route tables. A compute module depends on networking outputs. Use terraform.tfvars files per environment to override defaults. Avoid hardcoding resource names; use naming conventions with var.environment and var.project. Keep state files in a remote backend (Azure Storage) with locking enabled.

resource "azurerm_resource_group" "rg" {
  name     = "rg-${var.project}-${var.environment}-net"
  location = var.location
}

resource "azurerm_virtual_network" "vnet" {
  name                = "vnet-${var.project}-${var.environment}"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  address_space       = var.vnet_address_space
}

output "vnet_id" {
  value = azurerm_virtual_network.vnet.id
}

output "subnet_ids" {
  value = azurerm_subnet.subnets[*].id
}

Managing State with Azure Storage Backend

State files contain sensitive information and must be stored securely. Azure Storage Account with blob containers is the recommended backend. Enable blob soft delete and versioning to recover from accidental deletion. Use a dedicated storage account per environment with network restrictions (firewall, private endpoint). Enable azurerm_backend with key per state file (e.g., prod.terraform.tfstate). Use terraform init -backend-config to inject backend settings without hardcoding. For teams, enable state locking via Azure Blob Storage lease. This prevents concurrent modifications. Never store state locally in production.

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-terraform-state"
    storage_account_name = "stterraformstate"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
  }
}

# Initialize with:
# terraform init -backend-config="access_key=..."

Deploying a Multi-Tier Application on Azure

Let's deploy a typical three-tier app: web, API, and database. Use Azure App Service for web and API, and Azure SQL Database. Create a resource group, App Service Plan, two App Services, and a SQL Server with database. Use azurerm_app_service_plan with S1 SKU for production. Configure connection strings as app settings. Use azurerm_sql_database with S1 tier. For networking, enable VNet integration for App Services to connect to SQL via private endpoint. This example shows a complete, runnable configuration.

resource "azurerm_resource_group" "rg" {
  name     = "rg-myapp-prod"
  location = "eastus"
}

resource "azurerm_app_service_plan" "plan" {
  name                = "plan-myapp-prod"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  kind                = "Linux"
  reserved            = true
  sku {
    tier = "Standard"
    size = "S1"
  }
}

resource "azurerm_app_service" "web" {
  name                = "app-myapp-web-prod"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  app_service_plan_id = azurerm_app_service_plan.plan.id
  site_config {
    linux_fx_version = "NODE|14-lts"
  }
  app_settings = {
    "SQL_CONNECTION_STRING" = azurerm_sql_database.db.connection_string
  }
}

resource "azurerm_sql_server" "sql" {
  name                         = "sql-myapp-prod"
  resource_group_name          = azurerm_resource_group.rg.name
  location                     = azurerm_resource_group.rg.location
  version                      = "12.0"
  administrator_login          = "sqladmin"
  administrator_login_password = "P@ssw0rd1234!"
}

resource "azurerm_sql_database" "db" {
  name                = "db-myapp-prod"
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  server_name         = azurerm_sql_server.sql.name
  sku_name            = "S1"
}

Networking: VNets, Subnets, and NSGs

Networking is critical for security and performance. Create a VNet with subnets for each tier: web, app, data, and management. Use Network Security Groups (NSGs) to restrict traffic. For production, use azurerm_network_security_group with explicit allow rules. Avoid using * as source; specify IP ranges or service tags. Use azurerm_subnet_network_security_group_association to attach NSGs. For App Services, use VNet Integration (regional) to route traffic through the VNet. For databases, use Private Endpoints to keep traffic within Azure backbone.

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

resource "azurerm_subnet" "web" {
  name                 = "snet-web"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = ["10.0.1.0/24"]
  delegation {
    name = "delegation"
    service_delegation {
      name = "Microsoft.Web/serverFarms"
    }
  }
}

resource "azurerm_network_security_group" "web_nsg" {
  name                = "nsg-web"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  security_rule {
    name                       = "AllowHTTP"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "80"
    source_address_prefix      = "Internet"
    destination_address_prefix = "*"
  }
}

resource "azurerm_subnet_network_security_group_association" "web" {
  subnet_id                 = azurerm_subnet.web.id
  network_security_group_id = azurerm_network_security_group.web_nsg.id
}

Using Terraform Workspaces for Environment Isolation

Workspaces allow you to manage multiple environments with the same configuration. Create workspaces for dev, staging, prod. Each workspace has its own state file. Use terraform.workspace in configurations to differentiate resources. For example, name = "app-${terraform.workspace}". Workspaces are simple but have limitations: they share the same backend and variable values. For complex environments, use separate directories or Terragrunt. Workspaces work well for small teams with similar environments. Avoid using workspaces for completely different configurations (e.g., different regions).

# Create workspaces
terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

# List workspaces
terraform workspace list

# Select workspace
terraform workspace select prod

# Apply with workspace-specific variables
export TF_VAR_environment=$(terraform workspace show)
terraform apply -auto-approve

CI/CD Pipeline for Terraform on Azure

Automate Terraform with Azure DevOps or GitHub Actions. The pipeline should: validate formatting, run terraform init, terraform validate, terraform plan, and manual approval before terraform apply. Store backend config and secrets as pipeline variables. Use terraform plan -out=tfplan to capture the plan, then terraform apply tfplan for consistency. For Azure DevOps, use the Terraform task or bash scripts. For GitHub Actions, use the hashicorp/setup-terraform action. Always run terraform fmt -check to enforce style. Fail the pipeline on validation errors.

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  - group: terraform-variables

steps:
- task: TerraformInstaller@0
  inputs:
    terraformVersion: '1.5.0'

- script: |
    terraform init -backend-config="storage_account_name=$(STORAGE_ACCOUNT)" -backend-config="container_name=$(CONTAINER)" -backend-config="key=$(TF_STATE_KEY)" -backend-config="access_key=$(ARM_ACCESS_KEY)"
  displayName: 'Terraform Init'

- script: |
    terraform validate
  displayName: 'Terraform Validate'

- script: |
    terraform plan -out=tfplan
  displayName: 'Terraform Plan'
  env:
    ARM_CLIENT_ID: $(ARM_CLIENT_ID)
    ARM_CLIENT_SECRET: $(ARM_CLIENT_SECRET)
    ARM_SUBSCRIPTION_ID: $(ARM_SUBSCRIPTION_ID)
    ARM_TENANT_ID: $(ARM_TENANT_ID)

- task: ManualValidation@0
  timeoutInMinutes: 60
  inputs:
    notifyUsers: |
      user@example.com
    instructions: 'Approve the Terraform plan to apply changes.'

- script: |
    terraform apply tfplan
  displayName: 'Terraform Apply'
  env:
    ARM_CLIENT_ID: $(ARM_CLIENT_ID)
    ARM_CLIENT_SECRET: $(ARM_CLIENT_SECRET)
    ARM_SUBSCRIPTION_ID: $(ARM_SUBSCRIPTION_ID)
    ARM_TENANT_ID: $(ARM_TENANT_ID)

Handling Secrets and Sensitive Data

Never store secrets in Terraform state or configuration files. Use Azure Key Vault to store secrets and reference them in Terraform with data.azurerm_key_vault_secret. For provider authentication, use environment variables or managed identities. For application secrets (e.g., DB passwords), use Key Vault references in App Settings. Terraform can create Key Vault and secrets, but avoid putting secret values in .tf files. Use sensitive = true in outputs to prevent state exposure. For CI/CD, use pipeline secret variables.

data "azurerm_key_vault" "kv" {
  name                = "kv-myapp-prod"
  resource_group_name = "rg-myapp-prod"
}

data "azurerm_key_vault_secret" "db_password" {
  name         = "db-password"
  key_vault_id = data.azurerm_key_vault.kv.id
}

resource "azurerm_app_service" "web" {
  app_settings = {
    "SQL_CONNECTION_STRING" = "Server=tcp:${azurerm_sql_server.sql.fully_qualified_domain_name};Database=${azurerm_sql_database.db.name};User ID=${azurerm_sql_server.sql.administrator_login};Password=${data.azurerm_key_vault_secret.db_password.value};Trusted_Connection=False;Encrypt=True;"
  }
}

output "db_password" {
  value     = data.azurerm_key_vault_secret.db_password.value
  sensitive = true
}

Testing Terraform Configurations with Terratest

Testing infrastructure code prevents regressions. Use Terratest (Go library) to write integration tests that deploy real resources and verify behavior. Write tests for: resource creation, network connectivity, and idempotency. Run tests in isolated environments (e.g., ephemeral resource groups). Terratest handles setup and teardown. Example: test that an App Service returns HTTP 200. This catches misconfigurations before production. Combine with terraform plan checks in CI. Testing is not common but is a hallmark of mature teams.

package test

import (
	"testing"
	"github.com/gruntwork-io/terratest/modules/terraform"
	"github.com/stretchr/testify/assert"
)

func TestAppServiceDeployment(t *testing.T) {
	terraformOptions := &terraform.Options{
		TerraformDir: "../examples/app-service",
		Vars: map[string]interface{}{
			"environment": "test",
		},
	}

	defer terraform.Destroy(t, terraformOptions)
	terraform.InitAndApply(t, terraformOptions)

	appServiceName := terraform.Output(t, terraformOptions, "app_service_name")
	assert.NotEmpty(t, appServiceName)

	// Additional checks: HTTP status, etc.
}

Drift Detection and Remediation

Azure resources can be modified outside Terraform (manual changes, auto-scaling, etc.). This creates drift. Use terraform plan regularly to detect drift. Automate drift detection with scheduled CI/CD jobs. For critical resources, use terraform apply to remediate, but be careful—it may revert desired changes. Use terraform refresh to update state without changes. For Azure, enable Azure Policy to enforce compliance and alert on drift. Consider using azurerm_resource_group_template_deployment for resources that must stay in sync. Drift is inevitable; plan for it.

# Schedule this in CI (e.g., daily)
terraform init -backend-config="..."
terraform plan -detailed-exitcode
# Exit code 2 means changes detected
if [ $? -eq 2 ]; then
  echo "Drift detected!"
  # Send alert
  # Optionally auto-remediate with approval
fi

Advanced: Using Azure Policy with Terraform

Azure Policy enforces organizational rules. Terraform can create policy assignments and definitions. Use azurerm_policy_definition and azurerm_policy_assignment to apply policies like 'allowed locations' or 'require encryption'. This ensures resources created by Terraform (or manually) comply. Combine with azurerm_policy_set_definition for initiatives. Policies can also auto-remediate non-compliant resources. Use azurerm_management_group to scope policies. This is advanced but critical for large organizations.

resource "azurerm_policy_definition" "allowed_locations" {
  name         = "allowed-locations"
  policy_type  = "Custom"
  mode         = "All"
  display_name = "Allowed locations"

  policy_rule = <<POLICY_RULE
{
  "if": {
    "not": {
      "field": "location",
      "in": ["eastus", "westus"]
    }
  },
  "then": {
    "effect": "deny"
  }
}
POLICY_RULE
}

resource "azurerm_policy_assignment" "assignment" {
  name                 = "allowed-locations-assignment"
  scope                = azurerm_resource_group.rg.id
  policy_definition_id = azurerm_policy_definition.allowed_locations.id
  description          = "Enforce allowed locations"
}

Pre-Commit Hooks and Linting: Guardrails for Terraform Quality

Catch issues before they reach your repository using pre-commit hooks with antonbabenko/pre-commit-terraform. This framework runs checks on every commit: terraform fmt -check for formatting, terraform validate for syntax, tflint for provider-specific best practices, tfsec or checkov for security scanning (hardcoded keys, open security groups), and terrascan for compliance. Install with pip install pre-commit and a .pre-commit-config.yaml file. For production, configure hooks to run on all staged .tf files. Use terraform_docs to auto-generate documentation from variable and output descriptions. Use infracost to estimate cost changes on every PR. Integrate these checks into CI/CD as well — run the same hooks in your pipeline to catch anything developers might skip locally. For the Azure provider specifically, tflint catches common mistakes like missing features {} block or incorrect API versions. Set up pre-commit to run in CI with --all-files to ensure the entire codebase is checked. Block commits that introduce security issues by configuring hooks with severity thresholds.

repos:
  - repo: https://github.com/antonbabenko/pre-commit-terraform
    rev: v1.88.0
    hooks:
      - id: terraform_fmt
      - id: terraform_validate
      - id: tflint
        args:
          - --args=--config=__GIT_WORKING_DIR__/.tflint.hcl
      - id: terraform_tfsec
        args:
          - --args=--config-file=__GIT_WORKING_DIR__/.tfsec/config.yml
      - id: terraform_docs
        args:
          - --args=--output-mode=inject --output-file=README.md

State Migration and Recovery: Handling State File Disasters

State files are the source of truth for Terraform — losing or corrupting them can be catastrophic. Enable blob versioning on your Azure Storage backend to retain state file history. Set lifecycle rules to clean up versions older than 90 days. For recovery, download a previous version of the state blob, run terraform init, and import resources if needed. To migrate state between backends (e.g., local to Azure Storage), use terraform init -migrate-state. Terraform detects the existing state and prompts for migration. Use -force-copy for automation. For state recovery from scratch, use terraform import for each resource — automate this with terraform state list from a known-good state or a script that queries Azure resources. For state corruption, restore from the last good version and run terraform plan to verify. Prevent corruption by using state locking (automatic with Azure Storage backend). Never edit state files manually — use terraform state mv, terraform state rm, and terraform state replace-provider for safe modifications. For team safety, restrict state write access to CI/CD pipelines only — developers should run terraform plan against the remote state without write access.

#!/bin/bash
# Enable blob versioning on the state storage account
az storage account blob-service-properties update \
  --account-name stterraformstate \
  --resource-group rg-terraform-state \
  --enable-versioning true

# List versions of a state blob
az storage blob list \
  --account-name stterraformstate \
  --container-name tfstate \
  --include v \
  --query "[?name=='prod.terraform.tfstate'].{Name:name, Version:versionId}" \
  --output table

# Download a specific version
az storage blob download \
  --account-name stterraformstate \
  --container-name tfstate \
  --name prod.terraform.tfstate \
  --version-id "2026-07-10T10:00:00.0000000Z" \
  --file prod.terraform.tfstate.recovered

# Migrate state from local to Azure Storage (first time)
terraform init -migrate-state -force-copy

Terraform Cloud and Enterprise: Remote Operations and Policy as Code

Terraform Cloud (TFC) and Terraform Enterprise (TFE) provide remote state storage, remote operations, cost estimation, and Sentinel policy-as-code for Azure deployments. Connect your Azure backend to TFC by configuring the cloud block in your Terraform configuration. Use TFC workspaces per environment (dev, staging, prod) with Azure service principal credentials stored as workspace variables. Enable remote execution so plans and applies run on TFC's infrastructure — this eliminates the need for a dedicated CI/CD runner and provides audit logs. Use Sentinel policies to enforce Azure-specific rules: require tags on all resources, restrict VM SKUs, enforce geo-location constraints, and mandate encryption. For cost control, use TFC cost estimation to see the projected cost of every plan before applying. For team workflows, use TFC's run triggers to chain workspaces (e.g., apply networking before compute). For Azure DevOps integration, use the Terraform Cloud extension for Pipelines or the TFC API. For self-hosted TFE in air-gapped environments, configure the AzureRM provider with managed identity authentication. Always pin Terraform and provider versions in TFC/TFE to ensure reproducible runs.

terraform {
  cloud {
    organization = "my-org"
    hostname     = "app.terraform.io" # TFC; use internal URL for TFE

    workspaces {
      tags = ["azure", "production"]
    }
  }

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "azurerm" {
  features {}
  # Credentials come from TFC workspace variables:
  # ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_SUBSCRIPTION_ID, ARM_TENANT_ID
}