ARM, Azure, Bicep, Professional, Terraform

Many Flavors of Azure IaC


What is Infrastructure as Code? How do I decide what IaC to us? What are the limitations of each? Do they all work across cloud providers? Do all IaC languages offer the same feature support?

These are just some of the questions one might have when deciding on how to deploy/maintain/scale an Azure environment. One is quick to find out there are many flavors of Azure IaC (Infrastructure as Code). There is no right or wrong answer to this question and can leave one overwhelmed.

I’ve argued deciding on what IaC tooling is similar to choosing an ice cream flavor. Everyone has their own personal preference. Some like chocolate, some vanilla, and some even pizza flavored. Additionally there can be dietary restrictions limiting what flavors of ice cream one can have (think organization constraints).

This post will provide an introduction to a repository I created, Azure_IaC_Flavors, which can be leveraged for anyone looking to learn IaC or is interested in learning how the same IaC code could look across multiple languages.


This is a resource I created as my experience across various IaC tooling is pretty deep; however, I struggled to find a resource that was adequate enough to explicitly compare what one resource would look like across the different IaC tooling. Usually community articles or interactions with those in the field lead to one sided conversations. I struggled finding a true educated and unbiased conversation on the topic.

Perhaps the best community example I saw was the Bicep Playground. This interactive playground displayed ARM and Bicep template side by side. Instantly guiding those who are familiar with ARM what the same template would look like in Bicep.

Screenshot of Bicep Community Playground showing a storage account written in Bicep on the left and ARM on the right
Bicep Playground Screenshot

This type of configuration inspired me to try and learn the Bicep language to the point I started contributing the official Bicep repo. In fact at one point I was a top 10 contributor as I was submitting my examples back to the community for others to learn.

What’s Included

So taking this thought and combining it with my knowledge on Terraform I figured wouldn’t it be great if there was a place to show IaC languages side by side? That’s where Azure_IaC_Flavors was born.

I’ve taken the same IaC template for Azure resources and have written it in Bicep, Terraform, ARM, and Pulumi. Each language templates have the same constructs down to variable and parameter names, input validation, dependency tracking. IT’S ALL THE SAME.

This part is key. By constructing these examples in such a way it is a true apples to apples comparison for anyone who may know Terraform and want to learn Bicep or vice versa. These examples aren’t Hello World ones either. They leverage best practices including module usage where appropriate.

There is one caveat/shortcut I must admit to taking. The ARM templates in the repository were created by executing a bicep build and taking the outputted ARM template.

Anything Else Besides Code?

YES! I have included links and markdowns on each language providing a general overview whose intent is for 101 learning. Additionally this resource was used at the Heartland Developer’s Conference 2022…so there’s even a PowerPoint presentation you can walk through!

What About Configuring My Machine?

You don’t have to! That’s right! I experimented on this on using Codespaces and Local Containerized Development. Please read the post for more details; however, in a nutshell one can launch this repo with all the required tooling via a Codespace in GitHub. This is even more important with GitHub’s Announcement of 60 hours of free Codespaces.

Alternatively the repo can be downloaded and ran inside a dev container.


There are many flavors of Azure IaC, the Azure_IaC_Flavors is a great launching pad for anyone looking to learn more.

If you are already versed in IaC or interested in going deeper on a specific one check out some of my other more focused blog posts: