Why I Use Both Bicep and Terraform (And Maybe You Should Too)

Happy New Year and welcome to my first real blog post of 2026!

I wanted to kick off the year by writing about a topic that I both see being discussed a fair amount, but also one I’ve had several discussions about across a variety of different contexts.

Should you use Microsoft’s own Bicep or go third-party and use HashiCorp’s Terraform when deploying infrastructure to Azure?

Let’s start by briefly going over both of them

Language Basics

Bicep

Bicep is Microsoft’s first-party, Azure only, Infrastructure as Code (IaC) tool for deploying and configuring resources. The language is essentially a more user-friendly abstraction layer on top of the older ARM templates written in JSON.

Unlike Terraform, Bicep does not require any additional setup due to its stateless nature and instead relies on Azure’s ARM engine as the source of truth for the deployed resources.

Terraform

Terraform is a widely used IaC tool developed by HashiCorp. Unlike Bicep, Terraform is capable of managing infrastructure across multiple cloud providers, including Azure, AWS, Google Cloud, and many others, as long as there is a provider for it.

It’s important to note that both of the Azure-related providers are being actively developed and maintained by a collaboration between HashiCorp and Microsoft.

Besides the vendor-agnostic nature of Terraform, another key thing to take note of is the stateful nature of Terraform.

So, Bicep or Terraform?

So now that we have the basics in place of both Bicep and Terraform, the question remains: Which one should you choose for your Azure infrastructure deployments?

In my view, both of these tools have their places and use-cases. I frequently find myself using both of them depending on the specific requirements of a project or what the goal is.

Bicep has a strength in its simplicity to get started. There is no need to configure additional resources such as a backend. Besides using an identity with sufficient permissions to deploy resources to Azure, you can get started right away.

Terraform on the other hand requires a bit more initial setup, especially when it comes to configuring a backend for state management. But once that is in place, Terraform’s stateful nature and multi-cloud capabilities can be a huge advantage in many scenarios.

Let’s take an example scenario where Bicep would be a great fit:

You are in a position where you are the cloud engineer who semi-frequently gets the task of setting up new Azure subscriptions with a set of standardized resources and configurations. This can be things such as virtual networks, log analytics workspaces, monitoring configurations and so on.

We will assume that once the task is completed, this subscription will be handed over to a different team to work on their own applications and services with their own cloud engineers. Therefore there will not be any continuous maintenance or updates to the infrastructure after the initial deployment from your side.

With Bicep you can easily create a reusable template that defines all the standardized resources and configurations needed for the subscription. You can parameterize the template to allow for customization such as naming conventions, region selection and other variables that may differ between deployments.

Combine such a Bicep deployment with a GitHub Actions definition or an Azure DevOps pipeline and this task has now been boiled down to a simple button press and providing a few parameters.

• No prior setup needed. Automate the deployment via some CI/CD tooling, run it directly via Az CLI or throw it into the Azure Portal. Your choice.
• Extremely easy to author and maintain due to excellent VSCode extension support with intellisense and validation.

This would be a prime example of a scenario where Bicep would be a great fit. There is no need for complex state management or multi-cloud support, just a simple and repeatable way to deploy standardized infrastructure.

Now let’s take a look at a scenario where Terraform would shine:

Say your trusty cloud engineer has delivered you a ready Azure subscription with the standardized resources using Bicep as described in the previous Bicep scenario and you are now responsible for maintaining and deploying the resources for your shiny new application.

Given that the scope of the deployments now is an evolving application that can go through multiple iterations and environments (dev, test, prod etc), the infrastructure requirements are likely to change over time.

• Enabled auto scaling in the prod environment? Add that lifecycle property to ignore the instance count after the initial deployment and enjoy your IaC being up to date.
• Added a new feature that requires a new database? Simply add the new database resource to your terraform code and apply the changes.
• Unsure of what changes will be made before applying them? Run terraform plan to get a detailed overview of what changes will be made before actually applying them.

In such a scenario Terraform would be a better fit due to its stateful nature. With Terraform you can easily manage and track changes to your infrastructure over time. With this stateful nature Terraform is an excellent choice that can be managed directly alongside your application code in the same repository, enabling a true “Infrastructure as Code” approach.

So what’s the final verdict?

Based on the scenarios described above, you might have guessed that I am a fan of both tools and see their strengths in different contexts.

Of course you would be able to pick the opposite tool for each of them, but in my experience these would be examples where each tool shines the most.

Both of them of course also do have weaknesses but usually there’s ways to mitigate them, some by supporting scripts or something like Azure’s Deployment Stacks, but that’s a topic for another day.

To sum up, I hope you can walk away from this post with these 3 pointers which I think capture the essence of what I’ve tried to convey here:

• Bicep is designed with templating in mind.
• Terraform is designed for continuous infrastructure management.
• Select the right tool for the job at hand, and remember that this might change for each project.

I genuinely think both tools are great in their own right, having experience with both of them in your toolbox will make you a more versatile cloud engineer. As you gain more and more experience with both of them, it will become easier to identify when to use each one. Luckily both tools share a lot of similar concepts and ideas, so picking up the other tool once you are familiar with one of them should not be too difficult.

I hope you have found some of these insights useful and maybe even contributed to your decision-making process when choosing an IaC tool for your next Azure project!