ARM Templates and Bicep

Azure Resource Manager (ARM) templates are JSON files that define the infrastructure and configuration of Azure resources. They are declarative: you specify what you want the end state to be, and ARM orchestrates the creation, update, or deletion of resources to achieve that state. Bicep is a domain-specific language (DSL) that simplifies writing ARM templates. Bicep files are transpiled into ARM JSON templates before deployment. Both are used for Infrastructure as Code (IaC), enabling repeatable, version-controlled deployments.

An ARM template has the following top-level elements:

Example minimal ARM template:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {},
  "variables": {},
  "resources": [],
  "outputs": {}
}

Bicep has a simpler, more concise syntax. The equivalent of the above ARM template in Bicep is:

// Just a comment, no required boilerplate

Bicep files do not require a schema declaration. Resources are declared using a readable syntax. For example, a storage account in Bicep:

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-09-01' = {
  name: 'mystorageaccount'
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

When deploying templates, you can use two modes:

ARM determines the order of resource creation by analyzing dependencies. There are two ways to define dependencies:

Example in ARM:

{
  "type": "Microsoft.Network/networkInterfaces",
  "name": "myNic",
  "dependsOn": [
    "[resourceId('Microsoft.Network/virtualNetworks', 'myVnet')]"
  ]
}

In Bicep:

resource myNic 'Microsoft.Network/networkInterfaces@2022-01-01' = {
  name: 'myNic'
  dependsOn: [
    myVnet
  ]
}

Parameters allow you to pass values into templates at deployment time. They can have default values, allowed values, and constraints (min/max length, allowed values, etc.). Variables are computed within the template and are not input by the user.

Example parameter in ARM:

"parameters": {
  "storageName": {
    "type": "string",
    "minLength": 3,
    "maxLength": 24,
    "metadata": {
      "description": "Name of the storage account"
    }
  }
}

In Bicep:

@minLength(3)
@maxLength(24)
@description('Name of the storage account')
param storageName string

ARM templates support template functions that can be used in expressions. Common functions include:

In Bicep, you can call ARM functions using the az namespace or built-in functions like resourceGroup().location.

Bicep modules allow you to encapsulate a set of resources into a reusable file. A module is a Bicep file that can be referenced from another Bicep file. Modules can have their own parameters and outputs.

Example module reference:

module myModule './modules/storageAccount.bicep' = {
  name: 'storageDeploy'
  params: {
    storageName: 'myuniquestorage'
    location: resourceGroup().location
  }
}

Deploy using Azure CLI:

az deployment group create --resource-group myRG --template-file template.json --parameters parameters.json

For Bicep:

az deployment group create --resource-group myRG --template-file main.bicep --parameters parameters.json

Or use PowerShell:

New-AzResourceGroupDeployment -ResourceGroupName myRG -TemplateFile template.json -TemplateParameterFile parameters.json

The what-if operation shows what changes will happen without actually making them. It is useful for review before a complete mode deployment.

az deployment group what-if --resource-group myRG --template-file template.json

Bicep offers several advantages:

However, ARM JSON is the underlying language, and Bicep transpiles to it. You can mix both in a deployment by using templateLink to reference a JSON template from a Bicep file.

The exam often tests the difference between incremental and complete modes. Remember:

A common question: 'You want to ensure that only resources defined in the template exist in the resource group after deployment. Which deployment mode should you use?' Answer: Complete.

If a resource depends on another but the dependency is not implicit, you must use dependsOn. The exam might present a scenario where a VM depends on a NIC, which depends on a VNet. Since the NIC references the VNet, the VNet dependency is implicit, but the VM depends on the NIC explicitly because the VM references the NIC ID.

You can use a separate parameters file to pass values. The format is:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageName": {
      "value": "myuniquestorage"
    }
  }
}

Bicep files are transpiled to ARM JSON using the Bicep compiler. You can run bicep build main.bicep to generate the JSON. The exam may ask about the relationship: Bicep is a DSL that compiles to ARM JSON, not a replacement for ARM.

ARM templates and Bicep are essential for automated, repeatable Azure deployments. Understanding their structure, deployment modes, dependencies, and best practices is crucial for the AZ-104 exam. Focus on parameterization, modularization, and the what-if operation.

A company deploys a three-tier web application (frontend, backend, database) across multiple environments (dev, test, prod). Using Bicep, they create a main template that calls modules for each tier. Parameters for environment-specific values (e.g., VM sizes, database SKU) are passed via parameters files. The template includes a load balancer, two VMs in an availability set, a SQL database, and a storage account for diagnostics. Dependencies are implicit: the load balancer references the backend pool, which references the NICs. This setup allows the team to deploy a consistent environment in under 10 minutes, reducing manual errors. In production, they use complete deployment mode to ensure no stray resources remain. The what-if operation is run in CI/CD pipelines to review changes before approval.

An enterprise must ensure all deployed resources comply with internal policies (e.g., only certain VM sizes, mandatory tags). They embed Azure Policy definitions as part of the deployment using ARM templates. The template includes a policy assignment resource that applies a built-in policy to the resource group. Bicep modules are used to encapsulate policy definitions. During deployment, if a resource violates policy, the deployment fails. This enforces compliance at deployment time rather than relying on audits. The team also uses deployment stacks to manage the lifecycle of the entire solution, including policy assignments.

A financial services firm replicates its on-premises infrastructure to Azure for disaster recovery. They use ARM templates to deploy the recovery site resources: virtual networks, storage accounts, and a recovery services vault. The template includes parameters for source environment details and uses conditions to deploy only specific resources based on the recovery plan. The what-if operation is crucial to ensure no accidental deletion of existing recovery resources. The template is version-controlled and deployed via Azure DevOps. In a real disaster, the template is used to quickly spin up the recovery environment, and outputs provide connection strings for failover scripts.