Terraform on Azure

Multi-cloud IaC, state, plan/apply.

Intermediate30 min · lesson 8 of 15

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.

Terraform with a secured remote backend
# 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.

IaC through a pipeline
1write IaC
Bicep (Azure) or Terraform (multi-cloud)
2plan on PR
review proposed changes + scan
3approve for prod
gated apply
4apply + detect drift
automated, auditable changes
Bicep for Azure-native, Terraform for multi-cloud. Run IaC through a pipeline — plan, scan, approve, apply — and watch for drift.
Terraform state is sensitive — never commit it to git
The Terraform state file maps config to real resources and can contain secrets in plaintext. Committing it to a repository leaks those secrets and invites conflicts. Store state in a secured remote backend (Azure Storage with locking and access control), and keep it out of version control entirely.