In this blog post, you will learn about how the Azure Resource Manager consumes Azure Bicep templates to become an Azure resource. This blog outlines the stages of the deployment process, explaining what happens at each stage and providing a detailed explanation of each one.
Overview
In the image below, I have described the stages involved in the process of orchestrating a Bicep template into an Azure resource. Each stage will be explained in this blog. In short, the stages are:
- Stage 1: Orchestration
- Stage 2: Compile-time
- Stage 3: Runtime
- Stage 4: Resource output
Stage 1: Orchestration
This is the starting point of the deployment process. In this stage, the user creates the Azure Bicep template(s) and initiates the deployment from their local computer for testing purposes or uses Azure Pipelines or GitHub Actions for streamlined infrastructure automation to deploy to an Azure environment. The last is the preferred method of deployment.
Azure Bicep templates are orchestrated via deployment commands such as az deployment, New-AzDeployment, or through Azure DevOps/GitHub orchestration tasks.
Stage 2: Compile-time
Compile-time in Azure Bicep refers to the compilation of the Azure Bicep template. In this stage, the template is compiled from a Bicep template into an Azure ARM template. The compilation happens after the Bicep template has been orchestrated.
Compilation
In this stage, the Bicep template is compiled from a Bicep file to a JSON file. This means that a Bicep file, for example, deploy.bicep, is converted to an Azure Resource Manager (ARM) template, deploy.json. Which is in JSON format. This JSON will be used in a later stage.
Compilation is done under the hood during the orchestration of the Bicep template, so you do not have to run this command yourself. The command that runs is az bicep build. If your Bicep template contains syntax or lint errors, it will fail at this stage.
Running compile-time functions
The compile-time stage does more than just convert Bicep templates to ARM JSON. Some Bicep functions are executed during compilation. For example, the readEnvironmentVariable() function, which reads environment variables from the orchestration system (such as an Azure DevOps self-hosted agent), is triggered during the compile-time stage.
External module compilation
In addition to the execution of Bicep functions, if your Bicep template contains external module references to container registries such as Azure Verified Modules (AVM), these modules are automatically restored and stored in the local cache after the az bicep build command runs.
Finally, in regulated environments, network traffic might be limited, especially when using private Azure DevOps or GitHub build agents. Make sure to add external module URLs—such as mcr.microsoft.com, where AVM is pulled from—to the allowlist of your Azure Firewall; otherwise, the compilation step will fail your deployment.
Stage 3: Runtime
Runtime in Azure Bicep refers to the stage where the resources specified in the compiled ARM template file are actually deployed and configured in Azure. The compiled ARM template file from stage 2 is sent to the Azure Resource Manager for deployment. Before running the actual template file, the engine validates the ARM JSON template to ensure it is correct and then proceeds to deploy the file.
Azure Resource Manager
The Azure Resource Manager (ARM) is the heart of Azure. This engine manages deployment and management in Azure. It is the entry point for every call you make to Azure, not limited to Azure Bicep deployments but also including Azure PowerShell, Azure CLI, and REST API calls.
The engine also handles dependency management (deploying in a specific order) and concurrency management (blocking two or more operations on a resource).
To learn more in-depth about the Azure Resource Manager, Microsoft has great documentation on this: What is Azure Resource Manager?
Dependency management
At this stage, dependency management is handled by the Azure Resource Manager. It does not matter if you use explicit or implicit dependency management. The sequence in which Azure resources or Azure Entra ID objects are deployed or configured depends on how the resources are defined, either with dependsOn (explicit) or as shown in the example below (implicit):
| resource exampleDnsZone 'Microsoft.Network/dnszones@2018-05-01' = { | |
| name: 'myZone' | |
| location: 'global' | |
| } | |
| resource otherResource 'Microsoft.Example/examples@2023-05-01' = { | |
| name: 'exampleResource' | |
| properties: { | |
| nameServers: exampleDnsZone.properties.nameServers | |
| } | |
| } |
If there are no dependencies configured between resources, then the deployment of two or more resources will occur in parallel.
Returning Data
After the resources have been successfully deployed and configured, Azure Resource Manager (ARM) collects the specified outputs and returns them to the user or Azure Pipeline / GitHub Action output log. This returned data can be used for various purposes, including:
• Automation Scripts: automation scripts or tools can use this data to perform additional configurations or operations.
• Integration: The outputs can integrate with other systems, applications, or services that depend on the newly deployed resources.
• Validation: The deployment can be validated by examining the outputs to ensure resources are deployed correctly and configurations are as expected.
Stage 4: Azure Resource output
The final stage in the orchestration of a Bicep template to an Azure resource is the actual output of the Azure resource or Azure Entra ID object.
Conclusion
These are the stages involved when an Azure Bicep template is orchestrated to Azure. Having this knowledge can be beneficial for understanding what your Bicep template goes through, optimising infrastructure deployments, and troubleshooting purposes..
Azure Cloud | John Lokerse 
Hi John,
This is another excellent blog that showcases a wealth of insight and experience on this topic. Thanks a lot for taking the time.
LikeLiked by 1 person