ARM templates look powerful on paper – but have you noticed how every deployment turns into a maze of JSON and copy-pasted sections? Many teams find that what should be a straightforward rollout quickly becomes cluttered, brittle, and frustrating to manage. That’s where Bicep comes in. In this podcast, we’ll break down why ARM often trips teams up, show how Bicep fixes those pain points, and walk through examples you can actually reuse in your own Azure environment. By the end, you’ll see how to make deployments simpler, faster, and far more consistent. Before we get into it, drop a comment with the biggest issue you’ve hit when using ARM templates. I want to see how many of you have wrestled with the same problems. So let’s start with the basics — why does something as small as deploying a single resource often feel like wrestling with far more code than it should?

Why ARM Templates Break More Than They Build

ARM templates were meant to make cloud deployments predictable and consistent, but in practice they often do the opposite. What looks straightforward on the surface tends to collapse into complexity the moment you write a real template. Take something as basic as spinning up a single virtual machine. You’d expect a few short definitions. Instead, a template like that quickly sprawls into hundreds of lines. Each piece is wrapped in JSON syntax, parameters are duplicated, dependencies stretch across the file, and the whole thing feels heavier than the task it’s supposed to handle. That mismatch between promise and reality is the biggest complaint teams share. The appeal of ARM lies in its declarative model—define the desired state, and Azure figures out the rest. But once you start building, the weight of formatting, nesting, and long property strings drags the process down. It’s less like writing infrastructure code and more like juggling brackets until something finally compiles. The closest analogy is building furniture from instructions. With a brand like IKEA, you at least get diagrams that guide you through. ARM feels like the opposite: no clear diagram, just dense text spelling out every screw and hinge in excruciating detail. You’ll end up with the finished product, but the road there feels unnecessarily painful. And the pain doesn’t stop at writing. Debugging ARM templates is where most teams hit the wall. Error messages rarely explain what’s actually broken. Instead, you’ll get vague references to invalid structures or missing parameters with no pointer to where the fault lies. That leaves you scrolling through a massive JSON file, trying to match braces and commas while the deployment pipeline blocks your release. The language itself is brittle enough that a missing bracket or an extra comma somewhere across those hundreds of lines can stop everything cold. For that reason, many Azure admins admit they spend far more time troubleshooting ARM than they’d like to admit. It’s a common story: a deployment fails for reasons that aren’t obvious, hours get burned tracking the issue, and eventually someone caves and applies the fix directly in the Azure portal. It works at that moment, but the template becomes useless because what’s in the file no longer reflects what’s actually running. One IT team I spoke with described this cycle perfectly. They had a template designed to set up a handful of basic resources—storage, load balancers, the usual. When it refused to deploy cleanly, they chipped away at the errors one by one. Every “fix” uncovered something else. Eventually, under pressure to meet a deadline, they gave up on the JSON and finished the changes manually. By the end, the live environment worked, but the template was so far out of sync it couldn’t be reused. That scenario isn’t unusual; it’s the pattern many teams fall into. Small workarounds like that are what make ARM especially risky. Because templates are supposed to act as the single source of truth, any time someone bypasses them with manual changes, that truth erodes. A firewall rule added here, a VM tweak applied there—it doesn’t seem like much at the time. But after a while, what’s meant to be a reliable, reusable script turns into little more than a skeleton you can’t actually trust. The template still exists, but the environment it represents has drifted away. This cycle—verbose files, vague errors, brittle syntax, and manual fixes—explains why so many people grow frustrated with ARM. The tool designed to simplify Azure ends up creating overhead and eroding consistency. And while it’s tempting to blame user error, the truth is that the language itself sets teams up for this struggle. Later in this video, I’ll show you what this looks like with a real demo: the same deployment written in ARM versus in its modern replacement, so you can see the difference side by side. But before we get there, there’s another effect of ARM worth calling out—one that doesn’t become obvious until much later. It’s the slow drift between what your template says you have and what’s actually happening in your environment. And once that drift begins, it introduces problems even ARM can’t keep under control.

The Silent Killer: Configuration Drift

Environments often start out looking identical, but over time something subtle creeps in: configuration drift. This is what happens when the actual state of your Azure environment no longer matches the template that’s supposed to define it. In practice, drift shows up through quick portal edits or undocumented fixes—like a firewall tweak during testing or a VM change applied under pressure—that never get written back into the code. The result is two records of your infrastructure: one on paper, and another running live in Azure. Drift builds up silently. At first, the difference between template and reality seems small, but it compounds with each “just one change” moment. Over weeks and months, those small edits grow into systemic gaps. That’s when a dev environment behaves differently from production, even though both were deployed from the same source. The problem isn’t in the template itself—it’s in the growing gap between written intent and working infrastructure. The operational impact is immediate: troubleshooting breaks down. A developer pulls the latest ARM file expecting it to mirror production, but it doesn’t. Hours get wasted chasing nonexistent issues, and by the time the real cause is found, deadlines are in jeopardy. Security risks are even sharper. Many incidents aren’t caused by brand-new exploits but by misconfigurations—open ports, unpatched access, forgotten exceptions—that came from these quick changes left undocumented. Drift essentially multiplies those gaps, creating exposures no one was tracking. A simple example makes the point clear. Imagine creating a rule change in the portal to get connectivity working during a test. The fix solves the immediate issue, so everyone moves on. But because the ARM template still thinks the original configuration is intact, there’s now a disconnect between your “source of truth” and what Azure is actually enforcing. That single gap may not cause a failure immediately, but it lays a foundation for bigger, harder-to-find problems later. Think of drift like a clock that loses small fractions of a second. Early on, the difference is invisible, but over time the gap grows until you can’t trust the clock at all. Your templates work the same way: a series of small, unnoticed changes eventually leaves them unreliable as a record of what’s really running. ARM doesn’t make this easier. Its bulk and complexity discourage updates, so people are even less likely to capture those little changes in code. Long JSON files are hard to edit, version control conflicts are messy, and merge collisions happen often. As a result, entire teams unknowingly give up on the discipline of updating templates, which accelerates drift instead of preventing it. The cost reveals itself later during audits, compliance checks, or outages. Teams assume their templates are authoritative, only to learn in the middle of a recovery effort that restoring from them doesn’t rebuild the same environment that failed. By then it’s too late—the discrepancies have been accumulating for months, and now they break trust in the very tool that was supposed to guarantee consistency. That’s why configuration drift is sometimes referred to as the “silent killer” of infrastructure as code. It doesn’t break everything at once, but it erodes reliability until you can’t depend on your own files. It undermines both day-to-day operations and long-term security, all while giving the illusion of control. The frustration is that drift is exactly the kind of problem infrastructure as code was meant to solve. But in the case of ARM, its structure, size, and difficulty in upkeep mean it drives drift instead of preventing it. Later in this video, I’ll show how Bicep—through cleaner syntax and modular design—helps keep your code and your environment aligned so drift becomes the exception, not the norm. And while that addresses one hidden challenge, there’s another looming issue that shows up as soon as you try to scale an ARM deployment beyond the basics. It’s not about drift at all, but about the sheer weight of the language itself—and the breaking point comes much faster than most teams expect.

Where ARM Templates Collapse Under Their Own Weight

Once templates start moving beyond simple use cases, the real limitations of ARM become unavoidable. What feels manageable for a single VM or a storage account quickly becomes unmanageable once you add more resource types, more dependencies, and start expecting the file to describe a real-world environment. The growth problem with ARM has two parts. First, there is no clean way to create abstractions or reuse pieces of code, so copy-paste becomes the only real option. Second, every copy-paste increases size, clutter, and repetition. A modest deploy