Bicep and ARM Template Advanced Patterns

Azure Resource Manager (ARM) templates are JSON files that define the infrastructure and configuration for your Azure solution declaratively. They specify resources, their properties, and dependencies. Bicep is a domain-specific language (DSL) that provides a more concise, readable syntax and compiles to ARM templates. The exam expects you to know both, but you'll typically work with Bicep in practice.

When you deploy an ARM template, Azure Resource Manager evaluates the template and makes REST API calls to create or update resources. The deployment goes through these phases:

An ARM template has the following structure:

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

Bicep reduces boilerplate. For example, an ARM template resource like:

{
  "type": "Microsoft.Storage/storageAccounts",
  "apiVersion": "2021-09-01",
  "name": "[parameters('storageName')]",
  "location": "[resourceGroup().location]",
  "sku": {
    "name": "Standard_LRS"
  },
  "kind": "StorageV2"
}

Becomes in Bicep:

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

Bicep uses symbolic names (e.g., storageAccount) that are not the Azure resource name. The actual name is set via the name property.

Bicep modules allow you to reuse template snippets. A module is a separate Bicep file that can be deployed as a nested deployment. For example:

module networkingModule './networking.bicep' = {
  name: 'networkingDeployment'
  params: {
    vnetName: vnetName
    addressPrefix: addressPrefix
  }
}

The module file networking.bicep contains its own parameters and resources. The parent template passes parameters. Modules are compiled into a single ARM template with nested deployments.

Loops: Use for to create multiple resources. In ARM templates, you use copy loops. In Bicep:

resource storageAccounts 'Microsoft.Storage/storageAccounts@2021-09-01' = [for i in range(1, 3): {
  name: 'storage${i}'
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}]

Conditions: Use if to conditionally deploy a resource.

resource publicIP 'Microsoft.Network/publicIPAddresses@2020-06-01' = if (deployPublicIP) {
  name: publicIPName
  location: resourceGroup().location
  properties: {
    publicIPAllocationMethod: 'Dynamic'
  }
}

ARM templates automatically determine dependencies based on resource references. For example, if a subnet references a virtual network via properties.addressPrefix, ARM knows the VNet must exist first. However, sometimes you need explicit dependsOn for non-obvious dependencies. In Bicep, you can use the dependsOn property or rely on symbolic references.

ARM template functions are used to retrieve values dynamically. Common functions: - resourceGroup().location – location of the resource group. - subscription().subscriptionId – current subscription ID. - concat(), format() – string manipulation. - uniqueString() – creates a unique hash based on inputs. - parameters() – retrieves parameter values.

In Bicep, these functions are available directly (e.g., resourceGroup().location).

Parameter files separate environment-specific values from the template. They are JSON files with the same structure as the parameters section. You can reference them during deployment:

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

For complex tasks that cannot be expressed declaratively, you can use deployment scripts (PowerShell or CLI) within ARM templates. These run in a container and can perform custom actions. The exam may ask about this as a way to extend templates.

Bicep is transpiled to ARM templates using the Bicep compiler. The command bicep build main.bicep produces main.json. You can also use az bicep build. The generated ARM template is fully functional. You can even decompile ARM templates to Bicep using bicep decompile main.json.

The what-if operation shows what resources will be created, modified, or deleted without making actual changes. It's crucial for validating templates, especially with Complete mode. Run:

az deployment group what-if --resource-group myRG --template-file main.bicep

Common errors: - Missing dependencies: Resource required by another is not defined or not deployed yet. - Invalid properties: Wrong API version or property name. - Quota limits: Exceeding subscription quotas. - Name conflicts: Resource names must be globally unique (e.g., storage accounts).

ARM templates and Bicep can be integrated into CI/CD pipelines. The exam may ask about using AzureResourceManagerTemplateDeployment task in Azure Pipelines. The task can deploy templates with parameters and override parameters.

A large enterprise manages development, staging, and production environments. They use a single Bicep template for a web application (App Service, SQL Database, Redis Cache). Each environment has different values: SKUs, instance counts, and connection strings. They maintain separate parameter files (dev.parameters.json, staging.parameters.json, prod.parameters.json). In CI/CD pipelines (Azure DevOps), they run bicep build and then deploy with the appropriate parameter file. The key challenge is managing secrets (like SQL passwords) — they use Azure Key Vault references in the parameter file: {"reference": {"keyVault": {"id": "/subscriptions/.../resourceGroups/.../providers/Microsoft.KeyVault/vaults/myVault"}, "secretName": "sqlPassword"}}. This avoids storing secrets in source control.

A cloud team builds a landing zone for new projects. They create reusable Bicep modules: networking.bicep (VNet, subnets, NSGs), security.bicep (Key Vault, RBAC), compute.bicep (VM scale sets). Each module is versioned and stored in a container registry (Azure Container Registry for modules). The landing zone template references these modules from the registry: module networking 'br:myregistry.azurecr.io/bicep/modules/networking:v1' = {...}. This promotes consistency and reduces duplication. The deployment order is critical: networking must be deployed before compute. They use dependsOn in the parent template to ensure correct ordering.