Here's what we built and why it matters:

The Problem

We were working with a customer with project subscriptions with foundational networking resources VNets, Subnets, Route Tables, VPN Gateways, NSGs the underlying infrastructure that connects workloads back to the hub and keeps everything running.

Here's the challenge: the customer needed to grant their engineers full Owner access within these project subscriptions to move fast and deliver. But it wasn't just about access, engineers also needed the autonomy to create their own VNets, VPN Gateways, and other networking resources for their project needs. You can't just blanket block all networking operations.

But being an owner means having the freedom to do anything within the scope(all, or specific resource), they could also accidentally (or intentionally) delete or modify the foundational networking infrastructure that the landing zone depends on. The spoke VNet connecting back to the hub, the Route Tables enforcing traffic flow, the pre-configured peerings all of it was exposed.

Resource Locks? Owners can remove them. RBAC restrictions? that's IT overhead and never-ending race of the correct permissions, also every month new project is launched, and new Custom role is needed.

What about Azure Deployment Stacks? for those of you who dont know: Deployment Stacks offer built-in deny assignments that can protect managed resources from deletion and modification. It's actually a great fit for this kind of problem. But there was a catch: Azure Deployment Stacks currently only supports Bicep. The customer's entire infrastructure is built and managed with Terraform. Switching IaC tools wasn't on the table.

So, we needed a solution that works natively with Terraform and still gives us that level of protection. The customer needed a way to say: "You own everything in your project subscription create whatever you need but you can't touch the networking foundation beneath your feet."

The Idea: Tags as a Protection Mechanism

We designed a multi-layered Azure Policy solution where a simple tag — Environment: networking_protected becomes an immutability shield around landing zone networking resources.

Here's how it works:

Layer 1 — Tag Based Immutability (The Game Changer)

• A Deny policy prevents any modification to resources carrying the protected tag

• A DenyAction policy prevents any deletion of resources carrying the protected tag

The result? Once a networking resource in a project subscription exists that we want to lock, it's locked. No one not Contributors, not even Owners — can delete or modify it through the Azure control plane. Engineers keep their full Owner permissions for everything else — including creating their own VNets and VPN Gateways — but the networking foundation remains untouchable. The tag acts as a boolean "this resource is now immutable" flag.

In this picture you can see multiple policies triggered one for specific DNS config changes block and one for deny creation of any change to Microsoft.Network/* resources

But then you ask yourselves well I can just delete the tag and then I can do whatever I want, that's where Layer 2 come to play with Modify effect

Layer 2 — Self Healing Auto-Tagging
We built a Modify policy that automatically tags every networking resource (Microsoft.Network/*) with Environment: networking_protected the moment it's created or updated. No human intervention needed. A System-Assigned Managed Identity handles the tagging seamlessly. Every Route Table, every VNet, every VPN Gateway tagged and protected from day one,

• Modify policies provide corrective remediation and are not a synchronous enforcement boundary.

And what happens when someone deletes this tag? it automatically within seconds attach back because of the Modify effect

Layer 3 — Compliance Enforcement

• That's optional step, not every customer want to deny creation without tag

• The Deny policy provides the hard enforcement boundary

A Deny policy blocks the creation of any networking resource that's missing the required tag. This acts as a safety net if the auto tagging policy is ever disabled, non-compliant resources simply can't be created.

Layer 4 — Granular Action Level Controls
We also tried to narrow it down beyond just Microsoft.Network/*. Rather than broad resource-type blocking, we successfully built policies that target specific actions for example, blocking only VNet peering creation or deletion, locking DNS server changes on VNets, or preventing VNet deletion specifically. This gave us surgical precision: protect exactly what needs protecting without interfering with engineers everyday work.

Why We Chose This Solution

The Infrastructure as Code Angle

The entire solution is deployed via Terraform parameterized, reusable, and scope flexible. You can deploy it at the subscription level, resource group level, or management group level. It supports:

• Definition-only mode (deploy policies without assignments)

• Audit-only mode (monitor before enforcing)

• Full enforcement mode

One codebase. Any scope. Full governance.

The Takeaway

Governance is not about making every day work harder it's about finding the sweet spot between what the company needs and what engineers need to do their jobs.

Azure Landing Zones give you a solid foundation but protecting the networking within project subscriptions, while giving engineers the freedom to build what they need, is the real-life challenge to many companies. Azure Policy is one of the most underutilized tools in cloud governance. With the right combination of Modify, Deny, and DenyAction effects, you can turn a simple tag into a protection mechanism that even subscription Owners can't bypass, and it works beautifully with Terraform.

Engineers get full Owner access. They create their own resources freely. Landing zone networking stays untouchable. Everyone wins.

Tags aren't just metadata. They can be guardrails.

Want the Terraform code? If this sounds interesting to you, reach out I'd gladly share the Terraform files so you can implement this in your own environment.