ARM Templates and Bicep: AZ-104 Deployment Guide

Infrastructure as code means describing the Azure resources you want in a text file and letting Azure Resource Manager create them for you, rather than building each resource by hand in the portal. The file is declarative: you state the desired end result — a storage account here, a virtual network there — and Azure Resource Manager works out the order and the API calls needed to reach it. You do not write step-by-step commands.

There are two authoring formats you must know. An ARM template is a JSON file that Azure Resource Manager has understood for years. A Bicep file is a newer, purpose-built language that is much easier to read and write; when you deploy it, the Bicep tooling transpiles (compiles) it into an ordinary ARM template behind the scenes, so Azure Resource Manager still receives JSON. Bicep is a full replacement authoring experience, not a separate engine.

Both formats are idempotent: deploying the same file twice produces the same result, because Azure Resource Manager compares your declared state to what already exists and only changes what is different. This is why templates are safe to run repeatedly in a pipeline. On the exam, remember that Bicep and ARM JSON are two ways to describe the same deployment, and that a declarative template describes the end state, not the steps to get there.

Every ARM template is a JSON object with a small set of top-level sections, and the exam expects you to recognise each one by its job. The two required elements are $schema (which version of the template language this file uses) and contentVersion (your own version stamp). After those come the working sections:

• parameters — values the person deploying supplies at deployment time, such as a VM name, admin username, or environment. Parameters make one template reusable across dev, test, and production.
• variables — values you compute or reuse inside the template, such as a naming convention built from a parameter. Variables keep the resource definitions tidy and avoid repetition.
• resources — the heart of the template: the actual Azure resources to create or update, each with a type, apiVersion, name, location, and properties.
• outputs — values returned after deployment, such as a public IP address or a connection string, so a pipeline or a later template can use them.

A template can also declare functions and use built-in expressions such as resourceGroup().location or parameters('vmName') to keep values dynamic. When you read an ARM template on the exam, trace a value from a parameter, through a variable, into a resource property, and finally to an output — that flow is exactly what the questions test.

A Bicep file describes the same resources as an ARM template but with far less noise. Where JSON needs nested braces, quotation marks, and long function calls, Bicep uses a clean, declarative syntax that reads almost like a list of statements. You declare a parameter with param adminUsername string, a variable with var storageName = ..., and a resource with a resource keyword followed by a symbolic name and its type.

The biggest day-to-day win is symbolic references. In Bicep you refer to another resource by the name you gave it — for example nic.id to get a network interface's resource ID — and Bicep works out the dependency order for you automatically. In raw ARM JSON you often have to add explicit dependsOn arrays by hand. Bicep also gives you type checking and IntelliSense in the editor, so mistakes surface before you deploy, and modules that let you break a large deployment into reusable files.

Crucially, Bicep is not a different deployment engine. When you deploy, the tooling transpiles your .bicep file into an ARM template and hands that JSON to Azure Resource Manager. So a Bicep file and its generated ARM template produce an identical deployment. On the exam, if a scenario wants cleaner, more maintainable authoring with automatic dependency management, the answer is Bicep, not hand-written JSON.

Both formats deploy the same resources through Azure Resource Manager, so the choice is about authoring experience, not capability. The table below summarises the differences you should recognise on the exam.

The key point is that anything you can express in an ARM template you can express in Bicep, because Bicep compiles down to the same JSON. Microsoft positions Bicep as the recommended language for new Azure deployments, while ARM JSON remains fully supported for existing templates. You can also move between them freely — a two-way conversion covered later — so teams with a library of JSON templates are not locked out of Bicep. When a question stresses maintainability, modules, or automatic dependency handling, lean Bicep; when it references an existing JSON template or an exported template, that is ARM.

Most real work is not writing a template from scratch but modifying an existing one, and the exam tests two everyday edits: adding a resource and changing a parameter.

To change a parameter, you either edit the parameter's defaultValue in the template or, more commonly, supply a new value at deployment time — through a separate parameters file (azuredeploy.parameters.json), a --parameters flag on the CLI, or the portal's parameter form. Changing a parameter such as VM size or environment name lets one template serve many deployments without editing the resource definitions themselves.

To add a resource, you insert a new entry into the resources array in ARM JSON, or add a new resource block in Bicep. In ARM JSON you must give it a type, apiVersion, name, location, and properties, and add a dependsOn if it relies on another resource. In Bicep you simply reference the other resource symbolically and the dependency is handled for you. For example, adding a data disk to an existing VM template means adding a disk resource and referencing it from the VM's storageProfile.

Because templates are idempotent, you can redeploy the edited file over the existing deployment: Azure Resource Manager adds the new resource and leaves the untouched ones alone — provided you use the default Incremental mode, which the next section explains.

When you deploy a template you choose a deployment mode, and this is the single most tested — and most dangerous — concept in the topic. The mode decides what happens to resources that already exist in the target resource group.

Incremental mode is the default. Azure Resource Manager adds or updates the resources in your template and leaves any other resources in the resource group untouched. Nothing is deleted just because it is missing from the template. This is the safe, everyday choice.

Complete mode makes the resource group match the template exactly. Azure Resource Manager deploys what is in the template and then deletes any resource in the resource group that is not defined in the template. This guarantees the group contains only what you declared, but it removes anything you forgot to include.

Scenario: a resource group holds a web app and a separate storage account created earlier by a colleague. You redeploy your template — which defines only the web app — in Complete mode. Because the storage account is not in the template, Complete mode deletes it. Had you used Incremental mode, the storage account would have survived. On the exam, the trigger phrase "deletes resources not in the template" always means Complete deployment mode.

You can deploy a template three ways, and the exam may reference any of them. In the portal, use "Deploy a custom template" to paste or load a file. With the Azure CLI, run az deployment group create --resource-group rg --template-file main.bicep, adding --mode Complete to change the mode. With Azure PowerShell, run New-AzResourceGroupDeployment. Deployments target a scope — most often a resource group, but also a subscription, management group, or tenant. You can also package a template as a template spec, a resource stored in Azure so a team can share and version a template centrally.

Two operations help you work with existing infrastructure. Exporting a template generates a template from resources you built by hand: use "Export template" on a resource group, or export from the deployment history of a past deployment. Exported templates often need cleanup before reuse, but they are a fast starting point.

Converting moves between the two formats. Run az bicep decompile --file template.json to convert an ARM template to a Bicep file — remember decompile means JSON to Bicep. The reverse, az bicep build --file main.bicep, compiles a Bicep file to ARM JSON. Together, export plus decompile let you turn a hand-built resource group into a clean, reusable Bicep file.