Infrastructure as Code: ARM vs Bicep vs Terraform

Why Infrastructure as Code?

The Three IaC Tools for Azure

ARM Templates

Azure Resource Manager (ARM) templates are the native Azure IaC format — JSON files that define resources declaratively. Every Azure resource supports ARM because ARM is the underlying deployment engine.

// Simplified example — not complete
"resources": [
  {
    "type": "Microsoft.Web/sites",
    "apiVersion": "2022-09-01",
    "name": "claims-api",
    "location": "[resourceGroup().location]",
    "properties": {
      "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', 'claims-plan')]"
    }
  }
]

ARM templates are verbose but universally supported. Every Azure resource type is available on day one because ARM is the deployment layer itself.

Bicep

Bicep is a domain-specific language (DSL) that compiles to ARM JSON. It provides a cleaner, more readable syntax while producing the same ARM deployment.

resource appService 'Microsoft.Web/sites@2022-09-01' = {
  name: 'claims-api'
  location: resourceGroup().location
  properties: {
    serverFarmId: plan.id
  }
}

Bicep is not a separate deployment engine — it transpiles to ARM. This means every ARM feature is available in Bicep, and Bicep inherits ARM’s same-day resource support.

Terraform (with AzureRM Provider)

Terraform by HashiCorp is a multi-cloud IaC tool. The AzureRM provider enables Azure resource management using HCL (HashiCorp Configuration Language).

resource "azurerm_linux_web_app" "claims" {
  name                = "claims-api"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  service_plan_id     = azurerm_service_plan.main.id
}

Terraform manages state in a state file that maps declared resources to real Azure resources. This state file is critical — lose it and Terraform cannot manage your existing infrastructure.

ARM vs Bicep vs Terraform

Bicep is recommended for new Azure-only projects. Terraform when multi-cloud is a requirement.

Capability	ARM Templates	Bicep	Terraform
Language	JSON	Bicep DSL (compiles to ARM JSON)	HCL (HashiCorp Configuration Language)
Cloud support	Azure only	Azure only	Multi-cloud (Azure, AWS, GCP, 3000+ providers)
State management	Azure handles state (no state file)	Azure handles state (no state file)	External state file required (local, Azure Blob, Terraform Cloud)
New resource support	Day-one for all Azure resources	Day-one (compiles to ARM)	Depends on provider update cycle (can lag days to weeks)
Readability	Low — verbose JSON, repetitive	High — clean syntax, type safety	High — declarative HCL, familiar to multi-cloud teams
Modularity	Linked/nested templates (complex)	Modules with typed parameters	Modules with input/output variables
What-if / Plan	az deployment what-if	az deployment what-if (same as ARM)	terraform plan (detailed diff output)
Secret handling	secureString parameter type	Decorated with @secure()	sensitive = true hides from CLI output; values still stored in state file — encrypt and restrict access
Tooling	VS Code ARM extension	VS Code Bicep extension (IntelliSense, linting)	VS Code Terraform extension, TFLint, Checkov
Learning curve	Steep (JSON verbosity, expression syntax)	Gentle (if you know ARM concepts)	Moderate (new language, state concepts)
Destroy support	Complete deployment mode (dangerous)	Complete deployment mode (dangerous)	terraform destroy (shows plan first, supports -target)
Best for	Legacy templates, maximum compatibility	Azure-only teams wanting clean syntax	Multi-cloud or teams already invested in Terraform

Question

Why does Bicep have day-one support for new Azure resources but Terraform sometimes lags?

Click or press Enter to reveal answer

Answer

Bicep compiles to ARM JSON — it IS the ARM deployment engine with friendlier syntax. Any resource ARM supports, Bicep supports immediately. Terraform uses a separate AzureRM provider maintained by HashiCorp and Microsoft. New resource types require a provider update, which can lag by days or weeks after ARM adds support.

Click to flip back

Question

What happens if you lose the Terraform state file?

Click or press Enter to reveal answer

Answer

Terraform cannot determine which real Azure resources correspond to your HCL declarations. It may attempt to create duplicate resources or fail entirely. To recover, you must import existing resources into a new state file one by one (terraform import). Best practice: store state remotely in Azure Blob Storage with locking (via lease) and enable versioning for state recovery.

Click to flip back

Terraform State Management

Terraform state is the most critical operational concern when using Terraform:

• Remote backend — store state in Azure Blob Storage (encrypted at rest, versioning for recovery)
• State locking — use blob lease locking to prevent concurrent modifications
• State encryption — Azure Blob Storage encrypts at rest; for additional security, use customer-managed keys
• State file contents — contains resource IDs, attributes, and potentially sensitive outputs. Treat it as confidential.

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

💡 Scenario: Jordan selects the right IaC tool

☁️ Jordan at Cloudstream Media faces a common decision. The company runs:

• Core platform — Azure-only (App Services, SQL, Redis, Storage)
• CDN and edge — Cloudflare (not Azure)
• Video processing — some AWS Lambda functions (legacy)

Jordan recommends a split strategy:

• Bicep for all Azure-only infrastructure (App Services, databases, networking) — cleaner syntax, day-one support, no state file to manage
• Terraform for the cross-cloud pieces (Cloudflare DNS, AWS Lambda) — multi-provider support in a single tool

For the exam, remember: if the scenario is Azure-only, recommend Bicep. If multi-cloud is involved, recommend Terraform. If maintaining legacy templates, ARM is acceptable but suggest migrating to Bicep.

IaC Strategy: Source Control, Testing, and Deployment

Source Control for IaC

• Store IaC templates in the same repository as application code (monorepo) or a dedicated infrastructure repository (if infra team is separate)
• Use pull requests for all IaC changes — peer review catches resource misconfigurations before deployment
• Branch protection — require at least one reviewer and passing CI checks before merging
• Tag releases for infrastructure versions (e.g., infra-v2.4.0)

Testing IaC

Test Type	What It Validates	Tool
Linting	Syntax, style, best practices	Bicep linter, TFLint, ARM-TTK
Static analysis	Security and compliance rules	Checkov, tfsec, PSRule for Azure
What-If / Plan	Preview changes before applying	az deployment what-if, terraform plan
Policy validation	Azure Policy compliance	Azure Policy (deny effect), OPA/Conftest
Integration testing	Deploy to ephemeral environment, validate, destroy	Terratest (Go), Pester (PowerShell)

Pipeline Deployment Pattern

Lint → Static Analysis → What-If/Plan → Manual Approval → Deploy → Smoke Test

For Bicep:

- task: AzureCLI@2
  inputs:
    azureSubscription: 'MyAzureConnection'
    scriptType: 'bash'
    inlineScript: |
      az deployment group what-if \
        --resource-group myRG \
        --template-file main.bicep \
        --parameters @params.json

For Terraform:

- script: |
    terraform init
    terraform plan -out=tfplan
  displayName: 'Terraform Plan'
- script: terraform apply tfplan
  displayName: 'Terraform Apply'

Question

What is the purpose of az deployment what-if for Bicep/ARM?

Click or press Enter to reveal answer

Answer

what-if previews the changes a deployment would make WITHOUT actually deploying. It shows resources that would be created, modified, deleted, or left unchanged. This is the Bicep/ARM equivalent of terraform plan. Use it in pipelines as a validation step before manual approval and actual deployment.

Click to flip back

Question

What is Checkov and why is it important for IaC pipelines?

Click or press Enter to reveal answer

Answer

Checkov is an open-source static analysis tool that scans Terraform, Bicep, ARM, and CloudFormation templates for security misconfigurations (e.g., storage account without HTTPS enforcement, database without encryption, public IP on a VM). It runs in CI/CD pipelines as a quality gate — failing the build if security policies are violated. Over 1,000 built-in policies.

Click to flip back

💡 Exam tip: When to recommend which IaC tool

The exam presents scenarios and expects you to select the right tool:

Scenario	Recommend
Azure-only, new project, clean start	Bicep
Multi-cloud (Azure + AWS or GCP)	Terraform
Existing ARM templates, no migration budget	ARM Templates (suggest Bicep migration roadmap)
Team already uses Terraform for other clouds	Terraform (consistency across clouds)
Need day-one support for preview Azure resources	Bicep (Terraform provider may lag)
Want to avoid managing state files	Bicep (ARM handles state)
Government/regulated requiring strict version control of infra state	Terraform (explicit state enables drift detection)
Configuration management of OS-level settings	Neither — use Azure Machine Configuration or Automation DSC (covered in Module 18)

Knowledge Check

Jordan's team manages infrastructure across Azure and AWS. They want a single IaC tool with consistent workflow across both clouds. Which tool should Jordan recommend?

ABicep — it has the cleanest syntax for Azure resourcesBARM templates — they are the most mature Azure IaC formatCTerraform — it supports multi-cloud with a unified workflowDAzure CLI scripts — they can call both Azure and AWS CLIs

Check Answer

Knowledge Check

A team using Terraform accidentally deletes the state file from their local machine. They have real Azure resources running in production. What is the impact and recovery path?

ANo impact — Terraform reads the current state from Azure on each runBTerraform loses track of managed resources. Recovery requires importing each resource into a new state file.CAll Azure resources managed by Terraform are automatically deletedDTerraform recreates all resources from scratch on the next apply

Check Answer

Knowledge Check

Which IaC testing approach validates that a Bicep template will not create resources that violate organisational security policies (e.g., storage accounts must enforce HTTPS)?

ABicep linterBaz deployment what-ifCStatic analysis with Checkov or PSRuleDIntegration testing with Pester

Check Answer

🎬 Video coming soon

ARM vs Bicep vs Terraform

Next up: IaC in Practice: Desired State and Deployment Environments