ARM Templates vs. Bicep: Understanding the IaC Relationship

Introduction

This lesson introduces a core concept for modern cloud development: Infrastructure as Code (IaC). As a developer, you're used to managing application code in source control. IaC applies the same discipline to your infrastructure, allowing you to define, deploy, and update your cloud environment in a repeatable and reliable way.

Our goal is to address the learning outcome: Describe the relationship between ARM templates and Bicep for Infrastructure as Code (IaC). We will explore:

• The foundational role of Azure Resource Manager (ARM) templates as the native IaC language for Azure.
• The key limitations of authoring ARM templates directly.
• How Bicep, a modern domain-specific language, was created to solve these limitations by acting as an abstraction over ARM templates.

By the end of this lesson, you will understand that Bicep is not a replacement for the Azure Resource Manager engine, but rather a more powerful and developer-friendly way to author the templates that the engine consumes.

Part 1: The Foundation - Azure Resource Manager (ARM) Templates

At the heart of Azure's management layer is the Azure Resource Manager (ARM). Every request you make, whether through the portal or the CLI, is ultimately an API call to ARM. To automate deployments declaratively, we use ARM templates.

An ARM template is a JSON file that defines the resources you want to deploy, their properties, and their dependencies. This declarative syntax allows you to define what you want, and ARM handles how to create or update the resources to match that desired state.

While ARM templates are powerful, they have a significant drawback: the JSON syntax is notoriously verbose and complex for human authoring. As your infrastructure grows, managing brackets, commas, and complex functions like concat() becomes difficult and error-prone.

Part 2: The Evolution - Bicep as a Transparent Abstraction

To address the authoring challenges of ARM JSON, Microsoft created Bicep.

The relationship between Bicep and ARM templates is analogous to how a C# compiler translates your code into Intermediate Language (IL), which is then executed by the .NET runtime. Bicep provides a clean, high-level syntax that is translated (or "transpiled") into a standard ARM template JSON file. The Azure Resource Manager engine then deploys this generated JSON file.

This means Bicep isn't a new, separate deployment engine; it's a "better language" for producing the code that the existing ARM engine understands. You get a superior authoring experience without losing any of the underlying power of ARM.

This diagram perfectly illustrates the process:

Now, let's see how much cleaner the storage account definition from the previous article looks in Bicep.

Part 3: Understanding the Relationship in Practice

To really grasp this relationship, it's best to see it in action. The following video provides a clear explanation and demonstration.

As the video explains, Bicep code is converted into an ARM template before deployment. Originally, this was a manual step (bicep build), but modern tooling (like Azure CLI) does this for you automatically in memory.

Let's watch a second, more focused video that demonstrates this transpilation process.

Key authoring improvements Bicep offers over raw JSON include:

• Cleaner Syntax: No more counting brackets and commas.
• Modules: Reusable Bicep files, similar to functions or methods in C#.
• String Interpolation: Easily combine strings and variables, e.g., name: 'storage-${environmentName}'.
• Intelligent Tooling: Rich IntelliSense and validation within VS Code.
• Implicit Dependencies: Bicep automatically detects dependencies between resources, so you rarely need to manually declare dependsOn.

Part 4: A Note on Bicep vs. Terraform

You may have heard of other IaC tools like Terraform. While a deep dive is beyond today's scope, it's useful to know the fundamental difference.

• Terraform is a multi-cloud tool from HashiCorp. It uses its own deployment engine and maintains a "state file" to keep track of the resources it manages.
• Bicep is Azure-native. It is a direct abstraction over ARM and uses Azure itself as the source of truth, so it doesn't need a separate state file.

For developers focused solely on Azure, Bicep offers the most seamless integration and day-zero support for new Azure features.

The comparison table and decision tree in the "Terraform vs Bicep vs ARM" blog post provide a good summary of when to choose which tool.

Conclusion

In this lesson, we demystified the relationship between ARM templates and Bicep. You now understand how Azure's approach to Infrastructure as Code has evolved to prioritize developer experience without sacrificing platform capability.

Key Takeaways:

• Infrastructure as Code (IaC) is the practice of managing infrastructure declaratively through version-controlled code.
• ARM Templates (JSON) are the native, foundational IaC language for the Azure Resource Manager engine. They are powerful but verbose and difficult for humans to write and maintain.
• Bicep is a modern, domain-specific language that acts as a "transparent abstraction" over ARM. It offers a much cleaner syntax and better tooling.
• Bicep files are transpiled into ARM JSON before deployment. This means you get a better authoring experience while retaining all the power, features, and reliability of the underlying ARM engine.
• For Azure-native development, Bicep is the recommended IaC language.

Next Steps

Now that you understand the "what" and the "why" of Bicep, you're ready to get hands-on. In our next lesson, you will author a simple Bicep file to define an Azure Storage Account and deploy it to Azure using the CLI, putting this powerful concept into practice.