Azure Bicep - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Your Azure setup lives in your memory and that's a problem. You clicked it into place once on screens you'll never find again and nothing was ever written down. Azure bicep exists to change that. Welcome to the M365 FM podcast where we explore the people, ideas, and technologies shaping the future of work. Bicep turns your setup into a file you can read, save and share, and it doesn't ask you to be a developer. By the end of this one, that file will stop looking like code and start looking like a recipe. What bicep actually is? Azure bicep is Microsoft's own language for writing down the Azure resources you want. It reads more like a short set of instructions than dense machine code.

0:40 You describe what should exist, and Azure builds it. That idea has a name. Infrastructure as code, and the name makes it sound heavier than it really is. All it means is that your setup lives in a file instead of a pile of clicks. Think about how most of us start in Azure. We open the portal, we click through a dozen screens, and we create a storage account or spin up a virtual network. It works and it feels fine. The first time the trouble shows up the second time you need the same thing because now you're trying to repeat a series of clicks you never wrote down. The portal isn't the problem here. It's a good place to look at what you already have. It's a poor place to keep the definition of what you have, because that definition is a memory and memories fade. Bicep moves that definition into something you can open, read and hand to a teammate.

1:21 The other word worth learning is declarative. In plain terms, you describe the destination, not the route. You don't tell Azure to click here, then there, then somewhere else, and you don't have to guess the right order of steps. You write down the end state you want, and Azure works out the order of operations on its own. That's the whole promise of bicep in a single line. And everything else we cover is just detail stacked on top of it. There's a practical payoff hiding in that idea. Once your setup is a file, you can keep it in version control review changes before they go live and undo a bad day with a single revert. You also get a record of who changed what and when, which is the kind of thing that saves a team hours when something breaks at the wrong moment. Why not just use arm Json or the portal? Azure had a way to describe infrastructure long before bicep arrived, and it's called an ARM template.

2:04 ARM stands for Azure Resource Manager, and those templates are written in Jason. Jason is a data format built for computers to read. So the first thing you notice when you open one is how little it looks like a sentence. An arm template spells out every detail. Inside a rigid structure, you get long property names, nested quotation marks, and bracketed expressions that look like a puzzle. A single missing comma or a stray bracket can stop the whole file from deploying, and the error message often points you somewhere unhelpful. People end up hunting for a misplaced character. Instead of thinking about the infrastructure they actually want to build, Microsoft built bicep to fix that authoring experience, not to change what Azure can do. Every resource type, every setting, and every option you can use in an ARM template is still available in bicep.

2:47 The difference is how you write it. A storage account that takes a screen of nested Json and arm collapses into a handful of readable lines. In bicep, you can see the shape of the resource at a glance. Put the same storage account side by side, once in arm Json and once in bicep, and the gap shows up fast. The ARM version runs more than twice the line count of the bicep version for the exact same result, with brackets and quotation marks carrying most of the weight. The bicep version reads like a description of what you want, and the arm version reads like paperwork. So the honest answer to why you shouldn't just use arm Json is that you can and Azure will happily deploy it. You'd simply be writing the same instructions the wrong way, and you'd spend your time debugging punctuation instead of designing your setup. How bicep works under the hood.

3:27 Bicep doesn't replace ARM at all, and that's the detail that changes how you think about it. When you deploy a tool called the bicep, CLI translates your bicep file into an arm Json template, and then Azure Resource Manager does the real work of building your resources. Bicep is the language and ARM is the engine underneath it. That matters because you aren't choosing between something new and something old. You're choosing a cleaner way to write the exact same instructions. So nothing about the deployment changes. Just because the file you typed was easier to read. The bicep file is a transparent layer over the template. Azure already understood. The next thing to know is that deployments are idempotent, which is a fancy word for repeatable. You can deploy the same bicep file again and again, and you'll get the same resources in the same state.

4:07 If nothing has changed, nothing gets rebuilt. And that's a quiet but enormous difference from clicking. We're running the same setup twice can create duplicates. You didn't mean to make. Azure Resource Manager also handles the ordering for you. If one resource depends on another, Azure figures out what to build first, and it runs the independent pieces in parallel where it can. So a deployment finishes faster than a strict line by line sequence would. One more thing sets bicep. Apart from running a string of commands by hand, you deploy the whole file as a single operation, and Azure treats it as one coordinated change. If part of it fails, you get a clear deployment record to inspect. Instead of a half finished setup, you have to untangle from memory. There's also no state file to babysit. Some infrastructure tools keep their own record of everything they created, and that record can drift out of sync with reality.

4:51 Bicep skips the whole problem because Azure itself is the source of truth, and it always has the latest picture of what exists. Reading a bicep file in plain words, this is the part where that file stops looking like code and starts looking like a recipe. A bicep file is a short set of declarations and the order doesn't matter at all. Bicep reads the whole thing and works out how the pieces connect on its own. The first kind of declaration is a parameter which holds a value that can change between deployments. If your storage account needs a name, you make the name a parameter and you can pass in a different one for testing and for production. Parameters can carry defaults too, so you don't have to fill in everything every single time you deploy parameters. Also, where small labels called decorators and each one adds a bit of guardrail, one decorator attaches a plain description so the next person understands what a value is for, another restricts a parameter to a short list of allowed choices, which stops a typo from turning into a failed deployment.

5:43 The one worth remembering is the secure decorator, which tells Azure to treat a value like a secret and keep it out of deployment history and logs. Variables are the second kind of declaration, and they're just shorthand. If you need to build a long name out of several pieces, you work it out once in a variable and reuse it everywhere. It keeps the file clean and saves you from repeating the same expression five times. Then come resources, which are the main event. Each resource is one thing you want in Azure, like a storage account or a network, you give it a symbolic name, which is a short label you'll use to refer to it later, and you point it at a resource type with a version. Everything below that line is just the settings for that one resource picture the smallest useful file you could write it names one storage account, sets its location and picks a basic tier.

6:24 And that's about it. You'd have a resource declaration, a couple of settings, and maybe a parameter for the name. That tiny file is a complete deployable piece of infrastructure, and it's a fair place to start. Those symbolic names do more than label things. When one resource mentions another by its symbolic name, bicep notices the connection and builds the dependency for you. Older templates forced you to write dependencies by hand, and getting them wrong caused some of the most confusing failures people ran into. Bicep mostly takes that job off your plate. Two more pieces round out the file. Outputs are values you hand back after a deployment, like the web address of something you just created. So another part of your setup can use it. Conditions and loops. Let one file do more than one thing. So you can say only build this in production or build ten of these from a list without any copy and paste Based modules.

7:08 Your reusable building blocks. Once your setup grows, a single file gets crowded, and that's where modules come in. A module is simply a bicep file that another bicep file calls the same way you'd break a long document into chapters. You write your networking once as a module, and every project that needs a network just calls it. Instead of rebuilding the same lines, modules talk to each other through outputs. When one module finishes and produces a value like the ID of a subnet, the calling file can pass that value into the next module. That hand off is the contract between your pieces, and it keeps each module focused on a single job. Instead of trying to do everything, bicep also lets you choose where a deployment lands. You can target a resource group, a whole subscription, a management group, or the tenant itself, and each level has its own command.

7:50 The rule to remember is that the level written in your file has to match the command you run, or the resources end up somewhere you didn't expect. You don't need to build every module from scratch either. Microsoft publishes a set of official reviewed modules called Azure verified modules that cover common building blocks like networks, storage, and monitoring. There are trusted starting point. Kept up to date with recommended practice. So your first module doesn't have to begin as a blank page. That's the real value for someone starting out. You don't need to invent a perfect structure. On day one, you borrow a proven building block, change the handful of settings that matter to you, and get on with the part of the work you actually care about. The other benefit is consistency. When ten teams all call the same module, they all get the same network layout, the same naming, and the same guardrails.

8:31 Fix a problem once in the module, redeploy and every project picks up the fix instead of each team patching their own copy, deploying and the what if safety net writing the file is only half of the job, the other half is getting it into Azure safely, and bicep has a genuinely reassuring step for that. Before you deploy anything, you can run a command called what if it takes your file and compares it against what's already in Azure, then shows you exactly what would be created, changed, or removed. The detail that matters is that what if changes nothing at all. It's a preview and it lets you catch a surprise before it becomes real. The preview uses simple symbols to tell you what's coming. A plus means a new resource will be created. A tilde means an existing resource will be modified and the output shows the specific settings that differ.

9:12 A minus means something would be deleted, which is the one you always want to read slowly. What if isn't perfect and it's worth knowing its limits. It sometimes reports a setting as deleted when the server simply fills in a default value during deployment, which is harmless noise rather than a real change. It also can't resolve certain values that only exist at deploy time, like the current timestamp. So those show up in the output exactly as you wrote them. Neither of those should scare you, and both just mean you read the result with a little judgment around the preview. The everyday workflow is short. You write your file, you check it for mistakes. You run. What if and then you deploy. The same steps work whether you type the commands yourself or let a pipeline run them for you on every change. Running. What if automatically on every change is one of the best habits you can build early?

9:55 The order matters more than it sounds. Previewing a change before it goes live is what separates a calm rollout from a frantic one, and it costs you nothing but the few seconds it takes to read the output. If you work on a team, the preview becomes even more useful. A pipeline can run. What if on every proposed change, post the results for review and wait for a human to approve before anything reaches production. That turns a risky deployment into a normal conversation about a diff. Two small habits pay off right away. Tag your resources with things like environment and owner so anyone can tell later what a resource is for and reach for the secure decorator for anything secret. So passwords and keys never end up sitting in your deployment history where they don't belong. That covers how you ship a file. What it doesn't answer is whether bicep is even the right tool for your situation, and that's worth settling before you invest a weekend in learning it.

10:39 Bicep versus arm versus Terraform. By now, you've probably heard a third name in the same breath as bicep, and that name is Terraform. It's fair to wonder which one you should actually learn. And the honest answer depends on your situation. ARM templates are the original. They're Azure only. They're written in Json and they're still fully supported today. Microsoft keeps them around because they're the native contract. Azure understands, and plenty of teams still run them in production. If you already have a working library of ARM templates, there's no emergency and no deadline. Bicep is the newer, friendlier face of the same idea. It's also Azure only, but it's concise, readable, and has the gentlest learning curve of the three. You don't manage a state file, and new Azure features tend to be supported in bicep from day one, which matters when you want to use something the moment it becomes available.

11:22 One more point in biceps favor is how directly Azure's own documentation maps to it. When you look up a resource, the settings you see in the docs are the same ones you type into your file. So learning bicep teaches you Azure. At the same time. Terraform comes from a different world. It isn't tied to Azure and that's its whole point. It works across many cloud providers with one consistent workflow, which is exactly what you want if your company also runs somewhere else. The trade off is that Terraform keeps its own state file, and that file has to be stored, shared, and protected. In return. It gives you a clear plan step and strong detection of drift. So the decision is less about which tool is best and more about your situation. If your world is Azure and you want. The easiest way in bicep is the natural pick.

12:02 If you're juggling several clouds or your team already knows Terraform, that's the smarter path. And if you're sitting on a library of ARM templates that still works, you can move to bicep gradually instead of all at once. That gradual path is real. Microsoft ships a command that converts an existing ARM template into bicep automatically, though the result is a starting point you'll want to tidy up rather than a finished product. The common advice is simple enough to remember. Write anything new in bicep and convert the old files only when you have a reason to touch them. The mistakes beginners make. Whichever tool you pick, beginners tend to trip over the same handful of things, and knowing them in advance saves a wasted weekend. The first is hard coding names. If you type a fixed name for a resource, your second deployment to a different place can collide with the first, and some names, like storage accounts, have to be unique across all of Azure.

12:48 The fix is to build the name from a short, stable expression that changes with the environment so it stays predictable but never repeats. The second is trusting a converted file too much. When you decompile an arm template into bicep, the tool gets the structure across, but the output is rarely clean. You'll want to read it, simplify the references, and split it into modules before you build anything on top of it. The third is running the wrong deployment command for your file. If your file is set up for a subscription but you run the resource group command resources, land in the wrong scope, or the command fails outright matching the two takes a two second check and saves a confusing afternoon. The last one is reaching for manual dependencies out of habit. If you point at another resource through its symbolic name, bicep already knows the order for you.

13:30 Typing the dependency by hand usually means you missed a reference you could have used instead, and it adds a fragile line you'll have to maintain later. There's a broader habit underneath all four of these, and it's worth naming. Treat your infrastructure file as the record that matters, not a one time script. Once you do the small discipline of reading what you changed before you deploy, it becomes second nature. And most of these mistakes stop happening. Recap. And one question for you. Pull it all together. And bicep is a simpler way to describe the Azure infrastructure you want. It doesn't ask you to be a developer, and it lets you start with one small file instead of a whole framework. The real prize is that file, because it turns a fading memory into something you can read, share, and deploy again. Here's the question I'll leave you with. If you had to rebuild the Azure environment you work in today from scratch tomorrow, how much of it could you actually recreate from memory?