ARM templates vs Bicep vs Terraform

ARM templates, Bicep and Terraform are all declarative infrastructure as code: you describe the end state and the tool works out the steps. ARM templates are the JSON format Azure Resource Manager reads, Bicep is a shorter language that compiles to that same JSON, and Terraform is a separate multi-cloud tool with its own state file. The decision rule: if the scenario is Azure only and says nothing about other clouds or Terraform, the answer is Bicep; if it mentions several clouds, an existing Terraform codebase or a provider for a non-Azure service, the answer is Terraform; ARM JSON is the answer only when the question is about the template format itself.

The same storage account three times

The relationship is easiest to see in code. This Bicep file declares one storage account:

param location string = resourceGroup().location

resource sa 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'stexamdemo001'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

Microsoft Learn shows the equivalent ARM template as a JSON document with $schema, contentVersion, parameters and a resources array, the location written as the bracketed expression [parameters('location')]. The Bicep CLI converts the first form into the second at deployment time. In Terraform the same resource is an azurerm_storage_account block, deployed through a different engine entirely.

That last point is the key to the exam answers: Bicep and ARM are two spellings of one thing, while Terraform is a different thing.

Side-by-side decision table

Sources for the table: Microsoft Learn on Bicep and on Terraform for Azure (links below). Two rows decide most questions. State: Bicep and ARM have no state file, because Azure itself is the record of what exists. Terraform keeps its own state and compares it with the real world, which is why teams put it in remote storage and lock it. New features: Bicep supports preview and GA resource types the moment a resource provider publishes them; Terraform’s AzureRM provider covers stable functionality, and the AzAPI provider exists to reach new Azure features through the Resource Manager APIs without waiting for a provider release.

Deployment mode: the trap hidden in ARM and Bicep

ARM and Bicep deployments run in one of two modes. Incremental is the default: resources in the template are added or updated, and resources already in the resource group but not in the template are left alone. Complete deletes anything in the resource group that the template does not mention. Microsoft now labels complete mode as not recommended, says it will be gradually deprecated, and points to deployment stacks when you need deletion to follow the template. Complete mode is also unavailable in the portal, for linked or nested templates and for subscription-level deployments.

Worked example: a resource group holds a storage account, a VM and a key vault. A template that declares only the storage account is deployed.

• Incremental: all three resources remain; the storage account is updated if properties differ.
• Complete: the VM and the key vault are deleted.

Also in incremental mode, properties you leave out of a redeployed resource are reset to defaults rather than kept, because the template always represents the final state of that resource. Run what-if first; it lists what will be created, deleted or changed.

Which one to pick in practice

• A team that works only in Azure, wants no state to manage and needs day-one support for new services: Bicep.
• A team already running Terraform for AWS or Kubernetes and wanting one workflow: Terraform with AzureRM, plus AzAPI for gaps.
• Exporting a template from the portal or converting old assets: ARM JSON, then decompile to Bicep with az bicep decompile.
• Configuring software inside a machine rather than provisioning the machine: none of these; see Ansible vs Terraform and declarative vs imperative IaC.

Which exams test this

Only the Microsoft outlines name ARM templates or Bicep, and none of them names Terraform; the two Cisco outlines name Terraform as a general automation tool, not as an Azure deployment option. Check the current skills outline for your exam, since wording changes between versions.

How questions are built

The trap is mixing up the engine and the syntax. “Which tool requires no state file?” is Bicep or ARM; “which tool supports multiple clouds?” is Terraform. Words that decide the answer:

• “Idempotent”, “desired state”, “declarative”: true of all three, so they never separate the options alone.
• “Delete resources not in the template”: complete mode, or better, deployment stacks.
• “Preview the changes”: what-if for ARM and Bicep, plan for Terraform.
• “Multi-cloud”, “existing HCL”: Terraform.
• “Reduce JSON complexity”, “modules”, “transparent abstraction”: Bicep.
• “Latest preview resource type immediately”: Bicep, or Terraform AzAPI.

Pipelines that run these deployments are covered in YAML pipeline basics and CI/CD explained.

Practice questions

Go deeper

• What is Bicep? (Microsoft Learn)
• ARM template deployment modes (Microsoft Learn)
• Terraform on Azure overview (Microsoft Learn)
• Next on this site: Ansible vs Terraform, declarative vs imperative IaC, and the AZ-400 study plan.