Terraform on Azure
Multi-cloud IaC, state, plan/apply.
While Bicep is Azure-native, many organizations use Terraform for infrastructure as code because it works across clouds. A DevOps engineer should understand Terraform’s model, especially state, and how it compares to Bicep.
Terraform and state
Terraform is a multi-cloud IaC tool using the declarative HCL language and the azurerm provider for Azure. Its defining concept is state: Terraform records the resources it manages in a state file that maps your declared configuration to real infrastructure, and it uses this to compute what to change (the plan) before applying. State is critical and sensitive — it can contain secrets, so it must be stored in a secured remote backend (an Azure Storage account with locking), never committed to git, and access-controlled. The plan-then-apply workflow is a safety feature: you review exactly what will change before it happens, which fits naturally into a pull-request review process.
# main.tf — multi-cloud IaC; state tracks managed resources.terraform {backend "azurerm" { # REMOTE, secured state (not in git)resource_group_name = "tfstate-rg"storage_account_name = "contosotfstate"container_name = "state"key = "prod.tfstate"}}resource "azurerm_storage_account" "sa" {name = "contosodata"; resource_group_name = "app-rg"location = "westeurope"; account_tier = "Standard"; account_replication_type = "ZRS"}# Workflow: terraform plan (review) → terraform apply (execute)
Choosing and running IaC
Bicep versus Terraform is a real choice: Bicep is the best fit if you are Azure-only and want the native, always-up-to-date option with no state to manage; Terraform fits multi-cloud estates or teams standardizing one IaC tool across providers, at the cost of managing state. Either way, run IaC through a pipeline: plan on pull request so reviewers see the proposed changes, apply on merge with approvals for production, and scan the code (Checkov, tfsec) to catch misconfigurations before deploy. Detect drift so out-of-band changes are caught. This pipeline-driven IaC — reviewed, scanned, approved, applied automatically — is how infrastructure changes become as safe, auditable, and repeatable as application changes, which is the whole point of infrastructure as code in a DevOps practice.