In Part 1, we started with what sounded like a straightforward technology decision: should the customer use Bicep or Terraform for its Azure Landing Zone?
A few workshops later, that question had become harder to answer. We had uncovered ownership boundaries, brownfield complexity, security requirements and operational questions around drift and recovery.
The platform manager eventually asked, “How do we actually prove which one fits us better?”
That was when we agreed to build a proof of concept.
But we weren’t going to deploy the same virtual network twice, count the lines of code and declare a winner. Both technologies could deploy Azure resources. What we needed to prove was whether the organisation could operate the resulting Landing Zone.
That distinction mattered. Microsoft’s current Azure Landing Zone guidance supports an Infrastructure as Code approach using Azure Verified Modules with either Terraform or Bicep. The question for us was therefore not whether either technology could build the platform. It was whether the implementation model fitted the organisation that would eventually own it.
TL;DR
Both Bicep and Terraform can deploy an Azure Landing Zone. The right choice depends on which approach an organisation can operate confidently over time. A useful proof of concept should therefore test reproducibility, team ownership, governance changes, subscription vending, upgrades, scale and traceability, rather than deployment alone.
We started smaller than everyone expected
The engineering team initially suggested recreating most of the Landing Zone using both technologies. It sounded thorough, but I wasn’t convinced it would give us better evidence.
Instead, we selected a representative slice: a small management group hierarchy, subscriptions, policy assignments, RBAC, hub networking, Log Analytics, diagnostics and an application Landing Zone.
The requirement was functional equivalence, not structural equivalence. Forcing Terraform and Bicep into identical repository, module and deployment structures would have distorted the comparison. Each approach needed to use patterns we would realistically consider running in production.
Both environments deployed successfully.
One engineer said, “So technically, they both work.”
He was right. But successful deployment was the easiest test we were going to run.
So, we gave the platform to another engineer
The engineer who builds an IaC implementation knows where every assumption is hidden. They understand every pipeline variable, prerequisite and naming dependency.
That makes them a poor test of operational readiness.
We gave the repository and documentation to another engineer and asked him to deploy the Landing Zone without a walkthrough from the author. Almost immediately, we found an undocumented prerequisite and a pipeline permission that was obvious only to the original engineer.
None of that told us which tool was better. It told us whether the implementation could become an organisational capability rather than another form of tribal knowledge.
The platform manager put it simply: “If the person who built these leaves, can somebody else operate it?”
That became our first meaningful criterion.
We also started measuring things we had not originally planned to measure: how many prerequisites needed manual intervention, how easily a new engineer could navigate the repository, whether pipeline failures pointed clearly towards the problem and whether the documentation described the platform rather than merely how the original author had built it.
Reproducibility was becoming a supportability test.
Multiple teams made repository design matter
We then introduced another enterprise reality: several teams changing the platform at roughly the same time.
The network team prepared a hub change, the platform team had a policy update, and security wanted to modify diagnostic controls.
For Terraform, this brought state boundaries, locking, backend design and repository structure into focus. We wanted to understand whether a single state boundary created unnecessary coupling and whether independent domains could change without affecting unrelated parts of the platform.
For Bicep, the discussion centred on deployment scopes, sequencing, repository boundaries and how independently owned deployments would interact.
The important question was not whether Azure could process multiple deployments. It was whether several teams could operate without creating competing sources of truth.
A single repository could simplify coordination but create unnecessary coupling. Splitting everything into separate repositories created autonomy, but poorly defined interfaces could make dependencies harder to manage.
We therefore started documenting the interfaces between domains. The network platform could expose required outputs rather than forcing another team to own its deployment. Security could manage central controls without taking ownership of application resources. Platform engineering could maintain the management group and subscription model without becoming responsible for every workload.
The customer was designing team autonomy with controlled boundaries, not just choosing an IaC language.
A tiny policy change had the largest blast radius
The next test looked harmless. We changed a policy assignment at management group scope.
The security architect immediately asked, “How many subscriptions inherit this?”
That was the right question.
As the platform grows, a small governance change can affect many subscriptions and workloads. We therefore tested the promotion process rather than simply deploying the change.
Could the team stage it at a representative lower scope? Could it understand inheritance, compliance and exemptions? Could it validate the outcome before wider promotion? And after deployment, could it confirm that the resulting compliance state matched the intended design?
This highlighted an important point: Terraform plan and ARM/Bicep what-if are valuable review mechanisms, but they should not be treated as guarantees of application behaviour or governance outcomes. Change preview, staged validation and post-deployment verification solve different parts of the problem.
For governance changes, blast-radius management became as important as deployment automation.
That also changed how the customer thought about pull requests. A five-line change to a management group policy might deserve more scrutiny than a much larger change confined to a development workload. The size of the code change was not a useful measure of the operational risk.
Subscription vending turned the POC into a platform test
The platform manager eventually asked, “Can a workload team request a Landing Zone without raising five tickets?”
That took us into subscription vending.
We deliberately treated vending as more than subscription creation. The workflow needed to capture the request, provision or identify the subscription, place it beneath the correct management group and apply the appropriate baseline.
That baseline could include RBAC, policy inheritance, connectivity, diagnostics, tagging and other organisation-specific guardrails.
The first request worked. We ran another, then another.
Now we were measuring how much manual intervention remained, whether each Landing Zone received a consistent baseline and whether failed requests could be diagnosed easily. We also looked at whether the platform team could offer different standard patterns without turning every request into a bespoke implementation.
That distinction matters. Subscription vending works best as a platform capability with defined product patterns rather than an automation script that accepts every possible variation.
The POC had moved from testing an IaC tool to testing a repeatable platform service.
Then we fast-forwarded six months
A POC that finishes at version one can give false confidence, so we simulated something guaranteed to happen later: we upgraded the implementation.
For Terraform, that could involve Azure Verified Module versions, the AzureRM provider, AzAPI or changes in provider behaviour. For Bicep, it could involve AVM versions, module updates, resource API versions or changes in the Azure platform itself.
We reviewed what changed in place, what might be replaced and whether engineers could understand the impact before production.
Then we considered the exception path. What happens when Azure introduces a capability before the higher-level abstraction supports it?
Terraform might use AzAPI or a lower-level provider path. Bicep may reference the underlying Azure resource type directly or, in some cases, introduce another deployment mechanism.
Neither is automatically a problem. The concern is exception growth.
A clean platform can gradually turn into a mixture of reusable modules, scripts, CLI commands and one-off workarounds. We therefore added three questions to the POC: Who owns the exception? How is it tested? What causes it to be retired?
Without that discipline, exceptions can quietly become permanent architecture.
Finally, we increased the scale
For the last exercise, we added more subscriptions, policies, role assignments and deployment scopes.
The most interesting moment came during change review. The platform manager looked at a sizeable proposed change and asked, “Which of these actually matters?”
That captured the final requirement.
At enterprise scale, Infrastructure as Code becomes partly a human decision-making system. Engineers need to identify destructive changes, governance impact, unexpected replacements and changes crossing ownership boundaries without becoming overwhelmed by routine output.
We also tested traceability. Could a production change be tied back to a pull request, reviewer, approval and pipeline run? Could an incident team reconstruct what changed, who approved it and why?
Those capabilities become essential once the Landing Zone is shared infrastructure.
A platform is not operationally mature simply because every resource is represented in code. It also needs enough evidence for another engineer to understand how the current state came to exist.
We finished with evidence, not a winner
At the final workshop, nobody asked me to declare Terraform or Bicep the winner. By then, that would have been the wrong outcome.
Instead, we had evidence. We understood how each approach behaved across reproducibility, team boundaries, governance change, subscription vending, platform evolution, scale and supportability. We also understood the organisational factors around the technology: existing investment, engineering capability, onboarding effort, migration cost and future platform scope.
For another organisation, the weighting could be completely different. That is precisely why the evaluation matters.
The point of the exercise is not to prove that one tool is universally better. It is to remove assumptions and make the decision against the environment the organisation will operate.
By the end, the original question:
Should we use Bicep or Terraform?
had become a much better one:
Which approach gives this organisation the strongest operational fit for its Azure Landing Zone?
That is ultimately the decision the POC and evaluation framework should help answer.
Both technologies can deploy an Azure Landing Zone. The differentiator is whether the chosen approach can be understood, governed, scaled and sustained by the teams responsible for operating it.
A good IaC decision is not the one that produces the cleanest first deployment. It is the one the organisation can continue to operate confidently years later.
Use the technology comparison to form a hypothesis. Then test that hypothesis against the environment your engineers will operate.
Because deploying an Azure Landing Zone is only the beginning.
Don’t just prove that the tool can deploy the platform. Prove that your organisation can operate it.
