Bicep Templates for Developers

Bicep is an open-source, domain-specific language (DSL) developed by Microsoft for deploying Azure resources declaratively. It is a transparent abstraction over Azure Resource Manager (ARM) templates—every Bicep file compiles to a standard ARM JSON template. Bicep was created to address the pain points of writing raw JSON ARM templates: verbose syntax, lack of modularity, manual dependency management, and poor readability. Bicep provides a cleaner, more concise syntax with features like symbolic resource names, automatic dependency detection, module composition, and native support for parameter files. For AZ-204, you must understand that Bicep is not a separate tool; it is a language that produces ARM templates, which are then deployed by ARM.

When you write a .bicep file, you are writing in a declarative language. The Bicep compiler (bicep build or az bicep build) transpiles the .bicep file into a standard ARM template JSON file. This JSON file is the artifact that gets deployed. The compilation process involves:

The generated JSON is then deployed using standard Azure deployment methods: New-AzResourceGroupDeployment (PowerShell), az deployment group create (CLI), or REST API. Bicep itself does not handle deployment; it only generates the template.

#### Parameters - Declared with param keyword. - Supported types: string, int, bool, object, array, and secureString, secureObject. - Default values can be specified: param location string = resourceGroup().location. - Decorators: @secure(), @minLength(), @maxLength(), @allowed(), @description(), @metadata(). - Example:

@secure()
  param adminPassword string
  
  @allowed([
    'Standard_LRS'
    'Standard_GRS'
  ])
  param storageSKU string = 'Standard_LRS'

#### Variables - Declared with var keyword. - Can hold complex expressions, including function calls. - Evaluated at compile time (not runtime). - Example:

var uniqueName = 'storage${uniqueString(resourceGroup().id)}'

#### Resources - Declared with resource keyword followed by a symbolic name. - Syntax: resource <symbolicName> '<type>@<apiVersion>' = { ... } - The symbolic name is used to reference the resource elsewhere (e.g., myStorage.name). - Properties are defined in the body. - Example:

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
    name: 'mystorage${uniqueString(resourceGroup().id)}'
    location: resourceGroup().location
    sku: {
      name: 'Standard_LRS'
    }
    kind: 'StorageV2'
  }

#### Modules - Modules allow you to compose deployments from separate Bicep files. - Declared with module keyword. - Syntax: module <symbolicName> '<path-to-file>' = { ... } - Modules can pass parameters and receive outputs. - Example:

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

#### Outputs - Declared with output keyword. - Used to return values from the deployment, e.g., resource IDs or endpoints. - Example:

output storageEndpoint string = storageAccount.properties.primaryEndpoints.blob

#### Functions - Bicep supports built-in functions similar to ARM template functions. - Examples: resourceGroup(), subscription(), uniqueString(), concat(), format(), reference(). - Functions are evaluated at deployment time (except uniqueString which is deterministic based on input).

#### Decorators - Decorators are metadata annotations that modify behavior. - Common decorators: @secure(), @description(), @allowed(), @minLength(), @maxLength(), @minValue(), @maxValue(), @metadata(). - Example:

@description('The Azure region for resources.')
  param location string = resourceGroup().location

#### Install Bicep CLI - Via Azure CLI: az bicep install - Via manual download from GitHub releases. - Check version: az bicep version

#### Build Bicep to JSON - az bicep build --file main.bicep - Outputs main.json in the same directory. - To specify output: --outfile deploy.json

#### Deploy Bicep Directly (az deployment group create) - az deployment group create --resource-group myRG --template-file main.bicep - Azure CLI automatically builds the Bicep file before deployment (requires Bicep CLI installed).

#### Decompile ARM JSON to Bicep - az bicep decompile --file template.json - Produces a .bicep file. Note: decompilation may not be perfect and often requires manual adjustments.

#### Validate Bicep - az deployment group validate --resource-group myRG --template-file main.bicep

#### What-if Deployment - az deployment group what-if --resource-group myRG --template-file main.bicep - Shows preview of changes without applying them.

Bicep is tightly integrated with Azure DevOps and GitHub Actions. You can use the AzureResourceManagerTemplateDeployment@3 task in Azure Pipelines with a main.bicep file. The task automatically builds the Bicep file if the Bicep CLI is present on the agent. Similarly, GitHub Actions can use the azure/arm-deploy@v1 action with a Bicep file.

Bicep also integrates with Azure Policy: you can deploy policy definitions using Bicep modules. For secrets, use Azure Key Vault references in parameter files, not hardcoded values. Bicep supports getSecret function when referencing key vault.

Bicep does not replace Terraform; both can manage Azure resources. However, Bicep is Azure-native, while Terraform is multi-cloud. For AZ-204, focus on Bicep and ARM templates.

1. Create a Bicep file storage.bicep:

param storageName string
   param location string = resourceGroup().location
   
   resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
     name: storageName
     location: location
     sku: {
       name: 'Standard_LRS'
     }
     kind: 'StorageV2'
   }
   
   output storageEndpoint string = storageAccount.properties.primaryEndpoints.blob

2. Create a parameter file storage.parameters.json:

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

3. Build the Bicep file (optional, for inspection):

az bicep build --file storage.bicep

4. Deploy the Bicep file:

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

5. Verify deployment:

az storage account show --name mystorage12345 --resource-group myRG --query primaryEndpoints.blob

This process demonstrates the typical workflow: author Bicep, parameterize, deploy, verify.

A financial services company deploys a three-tier web application (frontend, API, database) across multiple environments. They use Bicep modules to separate concerns: one module for networking (VNet, subnets, NSGs), one for compute (VMSS or App Service), and one for data (SQL Database, Cosmos DB). Each module has its own parameters and outputs. The main main.bicep file orchestrates these modules, passing outputs from networking (e.g., subnet ID) to compute and data modules. This modular approach allows different teams to own different parts of the infrastructure. In production, they deploy using Azure Pipelines with the AzureResourceManagerTemplateDeployment@3 task, which builds and deploys the Bicep. Common issues include module path resolution (use relative paths from the main file) and circular dependencies between modules (avoid by careful design). They run what-if deployments in pull request pipelines to catch unintended changes.

A large enterprise enforces tagging and location restrictions across all subscriptions. They create a Bicep module that deploys Azure Policy initiatives (e.g., require tag 'CostCenter' and restrict locations to 'eastus' and 'westus'). This module is deployed to a management group. All application deployments include a reference to this policy module to ensure compliance. The Bicep module uses resource declarations for policy definitions and assignments. A common pitfall is forgetting to assign the policy at the correct scope; Bicep modules can accept a scope parameter. They also use @description decorators to document the purpose of each policy.

A SaaS provider uses blue-green deployment for zero-downtime updates. They maintain two identical environments (blue and green) in separate resource groups. Bicep templates are parameterized with an environment suffix (e.g., '-blue' or '-green'). The deployment pipeline runs Bicep to update the inactive environment, then swaps the traffic manager endpoint. Bicep's output is used to capture the new endpoint URL. The challenge is managing state between environments; they store deployment outputs in a key vault or a configuration database. Misconfiguration often occurs when the parameter file for the wrong environment is used, leading to accidental updates of the live environment. They mitigate this by using separate parameter files and pipeline variables.