This chapter covers Azure Bicep, a domain-specific language for deploying Azure resources using a declarative syntax. Bicep simplifies infrastructure as code (IaC) by providing a cleaner, more readable alternative to ARM templates. On the AZ-900 exam, this topic falls under Domain 3: Azure Management and Governance, Objective 3.4: Describe infrastructure as code and its benefits, with Bicep being a key example. Expect 5-10% of questions related to IaC concepts, including Bicep's role and advantages.
Jump to a section
Imagine you are a construction manager tasked with building a skyscraper. You could write out every detail in a massive, convoluted document that is hard to read and easy to make mistakes in—that is like using ARM templates with JSON. Now, imagine instead you have a clean, simple blueprint that uses plain language to describe each room, wall, and window. That blueprint is Bicep. It is a domain-specific language (DSL) that simplifies the way you define Azure resources. Just as a blueprint uses familiar symbols and concise notation, Bicep uses a declarative syntax that is easier to write and understand. Behind the scenes, Bicep is transpiled into the same ARM template JSON that Azure understands, so you get all the power of infrastructure as code without the complexity. This means fewer errors, faster development, and easier collaboration, much like how a clear blueprint helps a construction team build efficiently and correctly.
What is Azure Bicep and Why Does It Exist?
Azure Bicep is a domain-specific language (DSL) that simplifies the authoring of Azure Resource Manager (ARM) templates. ARM templates are JSON files that define the infrastructure and configuration for Azure resources. While powerful, JSON can be verbose, error-prone, and difficult to read, especially for complex deployments. Bicep addresses these challenges by providing a declarative syntax that is more concise and human-readable.
Business Problem: Organizations need to manage cloud infrastructure consistently, repeatably, and at scale. ARM templates work but are hard to write and maintain. Bicep reduces the learning curve and development time, enabling faster adoption of IaC.
How Bicep Works: Step-by-Step Mechanism
1. Authoring: You write a .bicep file using a simplified syntax. For example, to create a storage account, you write:
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-09-01' = {
name: 'mystorageaccount'
location: resourceGroup().location
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
}This is much cleaner than the equivalent ARM JSON.
2. Transpilation: The Bicep file is transpiled (compiled) into an ARM template JSON. You can do this using the Bicep CLI or Azure CLI:
az bicep build --file main.bicepThis produces a JSON file that can be deployed as a standard ARM template.
3. Deployment: You deploy the resulting ARM template (or directly deploy the .bicep file) using Azure CLI, PowerShell, or Azure DevOps:
az deployment group create --resource-group myResourceGroup --template-file main.bicepAzure Resource Manager processes the template and creates/modifies resources.
Key Components and Features
Declarative Syntax: You declare what you want, not how to do it. Azure handles the orchestration.
Modules: Bicep supports modularization, allowing you to break down complex deployments into reusable modules.
Parameters and Variables: Like ARM templates, Bicep supports parameters for input and variables for reuse.
Resource References: Use symbolic names to reference other resources, making dependencies clear.
Functions: Bicep includes built-in functions for string manipulation, arithmetic, etc.
File Structure: A typical project has a main.bicep file and optional module files (.bicep).
Pricing Model
Bicep itself is free and open-source. There are no additional costs for using Bicep. You only pay for the Azure resources you deploy.
Comparison to On-Premises Equivalent
In on-premises environments, infrastructure is typically managed manually or with scripting tools like PowerShell or Bash. Bicep provides a declarative approach that is cloud-native, ensuring consistency across deployments. There is no direct on-premises equivalent because Bicep is tied to Azure Resource Manager.
Azure Portal and CLI Touchpoints
Azure Portal: You can export ARM templates from the portal, but you cannot directly edit Bicep in the portal. However, you can use the Bicep playground (online) or local tools.
Azure CLI: The az bicep command group allows you to build, decompile, and install Bicep.
Visual Studio Code: The Bicep extension provides intellisense, syntax highlighting, and validation.
Business Scenario Example
A retail company needs to deploy a multi-tier application with web servers, databases, and networking. Using Bicep, they define the entire infrastructure in a few hundred lines of code, version-controlled, and deploy it consistently across dev, test, and production environments. This reduces deployment errors and speeds up releases.
Install Bicep CLI
First, ensure you have the Azure CLI installed (version 2.20.0 or later). Then install Bicep by running `az bicep install`. This adds the Bicep CLI to your environment. The CLI is responsible for transpiling .bicep files into ARM templates. Azure CLI includes Bicep support by default from version 2.20.0 onward. After installation, verify with `az bicep version`.
Create a Bicep File
Create a new file with a .bicep extension, e.g., main.bicep. Write your infrastructure definition using Bicep syntax. Start with a simple resource like a storage account. Use `resource` keyword followed by a symbolic name and the resource type. The syntax is `resource <symbolic-name> '<resource-type>@<api-version>' = { ... }`. This is more intuitive than JSON.
Build the Bicep File
Run `az bicep build --file main.bicep` to transpile the Bicep file into an ARM template JSON. This step validates the syntax and generates a JSON file (main.json) that can be deployed. Behind the scenes, the Bicep compiler checks for errors and produces a valid ARM template. You can inspect the JSON to understand how Bicep maps to ARM.
Deploy the Bicep File
Use `az deployment group create --resource-group myResourceGroup --template-file main.bicep` to deploy directly from the .bicep file. Azure CLI automatically transpiles the file before deployment. This is the preferred method for simplicity. You can also deploy the generated JSON. Ensure you have the necessary permissions (Contributor role) on the resource group.
Manage and Update Resources
To update resources, modify the .bicep file and redeploy. Azure Resource Manager handles incremental updates, adding, modifying, or removing resources as needed. Use parameters to make deployments flexible. For example, define a parameter for the storage account name to reuse the template. Bicep supports conditional deployments and loops for advanced scenarios.
Scenario 1: Consistent Development Environments
A software company has multiple developers who need isolated Azure environments for testing. Using Bicep, the DevOps team creates a main.bicep file that defines a resource group, virtual network, virtual machine, and database. Each developer can deploy their own instance by passing a unique parameter (e.g., environment name). This ensures all environments are identical, reducing "it works on my machine" issues. The team uses Azure DevOps pipelines to automate deployment on code commits. Cost is managed by using deployIfNotExists policies to enforce tags and shutdown schedules. If Bicep is not used, developers might manually create resources, leading to configuration drift and higher costs from orphaned resources.
Scenario 2: Disaster Recovery Infrastructure
A financial services firm needs a secondary Azure region for disaster recovery. They write a Bicep module that defines the entire production infrastructure, parameterized by region. When a failover is required, they deploy the same module to the secondary region with different parameter values (e.g., smaller VM sizes for cost savings). Bicep ensures the secondary environment mirrors the primary exactly, including networking, security groups, and load balancers. Without Bicep, manually recreating the infrastructure would be error-prone and slow. The firm also uses Bicep to deploy monitoring and alerting resources alongside the main infrastructure.
Scenario 3: Multi-Tier Application Deployment
A SaaS company regularly deploys updates to their application stack, which includes App Service, SQL Database, Redis Cache, and CDN. They use Bicep modules for each tier, allowing independent versioning and reuse across different products. The CI/CD pipeline builds the Bicep files, validates them with az bicep build, and deploys to staging and production. This modular approach enables teams to work on different components simultaneously. Common mistakes include not using parameters for environment-specific values (e.g., SKU sizes) leading to over-provisioning in dev, or forgetting to set dependsOn correctly causing deployment order issues.
Objective 3.4: Describe infrastructure as code and its benefits – AZ-900 tests your understanding of what IaC is and how Bicep fits in. Questions are conceptual, not hands-on. You will not be asked to write Bicep code, but you must know its advantages over ARM templates.
Common Wrong Answers: 1. "Bicep is a replacement for Azure PowerShell." – Wrong. Bicep is declarative, PowerShell is imperative. They serve different purposes. 2. "Bicep can only be used with Azure DevOps." – Wrong. Bicep can be used with any CI/CD tool or directly via Azure CLI. 3. "Bicep is a Microsoft-owned proprietary language that costs extra." – Wrong. Bicep is open-source and free. 4. "Bicep templates are deployed directly without conversion." – Wrong. Bicep is transpiled to ARM JSON; Azure Resource Manager does not natively understand Bicep.
Specific Terms and Values: - "Declarative syntax" – the key phrase describing Bicep. - "Domain-specific language (DSL)" – how Bicep is categorized. - "Transpilation" – the process of converting Bicep to ARM JSON. - "Open-source" – Bicep is open-source on GitHub. - "Azure CLI version 2.20.0 or later" – required for Bicep support.
Edge Cases: - The exam might ask about Bicep vs. Terraform. Know that Bicep is Azure-native and integrates deeply with ARM, while Terraform is multi-cloud. Both are IaC tools. - Questions about "idempotent deployments" – Bicep ensures the same result every time you deploy.
Memory Trick: Remember "Bicep = Better ARM templates" – Bicep makes ARM easier. If a question asks about a simpler way to write ARM templates, the answer is Bicep.
Azure Bicep is a domain-specific language (DSL) for deploying Azure resources declaratively.
Bicep simplifies ARM templates by reducing verbosity and improving readability.
Bicep is transpiled into ARM template JSON before deployment.
Bicep is open-source and free; no additional licensing costs.
You can deploy .bicep files directly using Azure CLI (version 2.20.0+).
Bicep supports modules, parameters, variables, and functions for modular and reusable deployments.
Bicep ensures idempotent deployments – the same template always produces the same result.
On AZ-900, focus on Bicep's benefits over ARM templates, not syntax details.
These come up on the exam all the time. Here's how to tell them apart.
Azure Bicep
Declarative syntax, easier to read and write
Less verbose: shorter code
Open-source and free
Supports modules for reusability
Azure CLI built-in support from version 2.20.0
ARM Templates (JSON)
JSON format, more verbose
Harder to read for complex deployments
Also free, but more error-prone
Can use linked templates but more complex
Supported by all Azure CLI versions
Mistake
Bicep is a scripting language like PowerShell.
Correct
Bicep is a declarative language, not imperative. You define what resources should exist, not the steps to create them.
Mistake
Bicep can only be used to create new resources, not update existing ones.
Correct
Bicep supports incremental deployments that can update, add, or remove resources. It is fully idempotent.
Mistake
Bicep is a paid Azure service.
Correct
Bicep is completely free and open-source. You only pay for the Azure resources you deploy.
Mistake
You must convert Bicep to JSON before deployment.
Correct
You can deploy .bicep files directly using Azure CLI; the transpilation happens automatically. Manual conversion is optional.
Mistake
Bicep replaces the need for ARM templates entirely.
Correct
Bicep compiles into ARM templates. ARM templates are still the underlying format that Azure Resource Manager understands.
The main advantage is simplicity. Bicep uses a declarative syntax that is much easier to read and write than JSON-based ARM templates. It reduces the amount of code needed and minimizes syntax errors. For example, a storage account definition in Bicep is about 10 lines, while the equivalent ARM JSON is 20+ lines. Bicep also supports modularization and has built-in functions for common tasks. For the exam, remember that Bicep is designed to simplify ARM template authoring.
Yes, you need the Azure CLI version 2.20.0 or later, which includes Bicep support. You can also install the Bicep CLI separately. For the best authoring experience, install the Bicep extension for Visual Studio Code. The extension provides syntax highlighting, intellisense, and validation. For the exam, know that Bicep is integrated with Azure CLI.
Yes, Bicep is specific to Azure. It is designed to work with Azure Resource Manager. Unlike Terraform, which is multi-cloud, Bicep is Azure-native. This tight integration allows Bicep to take advantage of ARM features like idempotent deployments and resource dependencies. For the exam, understand that Bicep is an Azure-specific IaC tool.
Yes, you can use Bicep with Azure DevOps pipelines. The AzureCLI task can run `az deployment group create` with a .bicep file. There are also community tasks for Bicep. Bicep fits into any CI/CD workflow that supports Azure CLI. The exam may test that Bicep can be used in DevOps pipelines.
The Bicep compiler will catch syntax errors during the build or deployment process. If you use `az bicep build`, errors are reported with line numbers. If you deploy directly, the Azure CLI transpiles first and reports errors. This helps catch mistakes early. For the exam, know that Bicep provides validation before deployment.
Yes, you can decompile ARM templates to Bicep using `az bicep decompile --file template.json`. This generates a .bicep file that approximates the original. However, the decompiled code may need manual adjustments, especially for complex templates. This is a useful migration path. The exam might mention this capability.
Bicep automatically manages dependencies by analyzing resource references. When you reference a resource by its symbolic name, Bicep adds an implicit dependency. You can also explicitly set dependencies using the `dependsOn` property. This ensures resources are created in the correct order. For the exam, understand that Bicep simplifies dependency management.
You've just covered Azure Bicep Language — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?