DEV Community: Jonny Diamond

Using Azure archetypes at scale to simplify governance: Why the CAF works, part 2

Jonny Diamond — Tue, 06 Oct 2026 20:21:16 +0000

Using Azure archetypes at scale to simplify governance: Why the CAF works, part 2

In part 1 we looked at why the Cloud Adoption Framework works. In this post I want to look at the part of it that I think does the most for governance at scale: landing zone archetypes. What are they, and why does governing two hundred subscriptions with them take about the same effort as governing ten?

Start with what you’re hosting

Let’s start by emphasising that archetypes work best when you know the compliance and security requirements of your cloud workloads ahead of time. A good time to learn that lesson is early in adoption, ideally in the Strategy phase https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/strategy/. It sounds something like this: we are Company X, and we need to host workloads that are PCI DSS compliant, or ISO 27001 compliant, or that meet our very rigorous internal security benchmark. Or maybe it’s the Microsoft cloud security benchmark (MCSB), which is a collection of excellent security best practices.

If you don’t know the security requirements of what you’re hosting, that’s the place to start. It’s the cornerstone of everything that follows. What you’re hosting drives your requirements, and your security and information risk should decide what those requirements look like. You don’t need a list of every workload you’ll ever host, but you do need to know the kinds of risk you’ll carry, like the regulations that apply to you and how you classify your data.

Yes, you could just assume the highest standard for everything, but for most organisations I think that’s the wrong default. It comes with an operational toll and added cost that most workloads don’t need. If we’re adopting Azure, it’s because we want to host things there and get the benefits, like lower operational effort and more agility. Locking everything down to PCI level gives a lot of that back. One security posture for the whole estate is either too weak for your regulated workloads or too costly for everything else, and archetypes mean you can host both and have them coexist.

What it looks like without them

You may have seen a tenant where this went wrong. The management groups mirror the org chart, with one per business unit or region, and sometimes Dev, Test and Prod under each of those. Policy gets assigned wherever someone needed it at the time, the same assignments get repeated at different levels, and anything that doesn’t fit gets an exemption. Before long the exemption list is longer than the assignment list, and nobody can tell you what posture a subscription actually has without going and looking.

Microsoft’s management group guidance calls this out directly https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/tailoring-alz:

Don’t duplicate your organisational structure into a deeply nested management group hierarchy. Use management groups for policy assignment versus billing and RBAC purposes.

It also says not to create management groups for production, testing and development. Those should be separate subscriptions in the same management group.

Platform landing zones

Before we get to archetypes properly, I need to explain platform landing zones, commonly referred to as the shared services. These are the connectivity, identity and management landing zones. They exist to provide network services, identity services, platform automation and so on, which the application landing zones (our workloads) consume.

Depending on the operating model, the hub is centrally managed. It hosts either a standard hub VNet or an Azure Virtual WAN hub. Not every workload uses it, though. Some sit in isolated networks with their own VNet and firewall, sometimes called islands.

Each workload on the right is peered to the hub and consumes its central services. Keep this picture in mind, because the network is one of the things that defines an archetype.

So what is an archetype?

In the CAF we use landing zone archetypes to group subscriptions with the same policy requirements, and therefore the same compliance requirements. This is how Microsoft defines one https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/tailoring-alz:

A landing zone archetype describes what needs to be true to ensure a landing zone (Azure subscription) meets the expected environment and compliance requirements at a specific scope.

The examples it gives are Azure Policy assignments, RBAC assignments and “centrally managed resources such as networking”. So an archetype isn’t just a management group. The management group is how you implement it. Because policy is inherited down the tree, everything assigned above it counts too. A subscription in a PCI archetype gets the intermediate root’s policies, plus the Landing Zones policies, plus the PCI ones.

The question we must ask first is: can I categorise the types of workloads I’ll host? Do they have different compliance or security requirements? Should security be more strictly enforced in some than in others? It’s these requirements that drive the archetypes. Whatever types of workload you need to host, that’s the right answer for your archetypes, and Microsoft’s guidance says much the same:

Create management groups under your landing zone management group to represent the types of workloads that you host. These groups are based on the security, compliance, connectivity, and feature needs of the workloads.

Notice connectivity in that list. Out of the box, ALZ gives us Corp and Online (plus Local, for workloads on Azure Local), and the difference between Corp and Online is the hub-and-spoke picture from earlier. Corp is for workloads that connect to the corporate network through the hub. Online is for workloads that need direct internet access, or that don’t need a virtual network at all.

If you look at the ALZ library, every policy assignment Corp adds is about the network: deny public endpoints, deny public IPs on NICs, deny hybrid networking (that’s the hub’s job), and point private endpoints at the central private DNS zones. Online doesn’t add any of its own. It just inherits from Landing Zones. The islands have a different connectivity requirement again, so they don’t belong in Corp. They go in Online or in an archetype of their own.

The platform landing zones work the same way. Identity has its own assignment to deny public IPs. Connectivity can’t have that one, because the hub needs public IPs for its firewall and gateways, so the two get different policy.

Audit or enforce?

Now policy has a target, and we can enforce a posture on an archetype because the workload type requires it. This is where the catch with MCSB comes in: out of the box, it audits. If we look at the initiative definition, none of its effect parameters default to Deny. Assign it as-is and you get a very good report of where you’re falling short, but on its own it won’t stop anyone deploying something non-compliant. The PCI DSS v4.0.1 initiative is the same.

There are ways to enforce it, though:

Set the effect parameters to Deny in your assignment (or DeployIfNotExists or Modify, where the policy supports them). Dozens of the MCSB effect parameters accept Deny.

Use the Deny and Enforce options in Defender for Cloud, which work on a subset of MCSB recommendations.

Assign deny policies directly to the archetype, which is exactly what ALZ does for Corp.

Don’t flip everything to Deny on day one. Run it in audit first, look at what would break, then move it to Deny. And keep in mind that policy only covers the Azure side. PCI DSS also covers people and process, and no initiative does that part for you.

Okay, so how does this let governance scale?

Once we vend a subscription, we place it in an archetype and policy enforces the requirements. That’s pretty much it. The ALZ FAQ uses this as its example of policy-driven governance: a new subscription is created and placed into a management group, and Azure Policy makes sure Defender for Cloud is enabled on it.

Nobody configures controls subscription by subscription, and nobody has to remember that this particular workload needs private endpoints. Policy becomes the guardrail for the archetype, and the archetype is the workload type. Whether we have ten subscriptions or two hundred, the effort is about the same.

It also means subscription vending is where the important decision gets made. When a new workload comes in, the intake asks what it is, what data it handles and what it needs to connect to, and this informs the archetype. This is why knowing roughly what types of workloads you need to host is beneficial.

Some tailored archetypes

The boxes in green are the safest place to change the CAF management group structure. That’s Microsoft’s wording too: it calls the area under Landing Zones “the most common and safest place in the hierarchy to add more archetypes”. Anything assigned at the intermediate root applies to every subscription below it, so that’s where you want to change the least. The example here includes PCI, which is also the example Microsoft uses, so any subscription with that requirement goes in there.

Summary

Archetypes simplify landing zone (workload) governance by letting us group workloads with the same requirements together. Work out your requirements early and let security and information risk shape them. Turn them into archetypes, make sure the policies enforce and don’t only audit, and pick the archetype when you vend each subscription. So why use them? Because once they’re in place, governing a new workload comes down to one decision at vending time, and policy does the rest.

Enabling Azure DDoS Protection at Scale with Policy-Driven Governance

Jonny Diamond — Sun, 04 Oct 2026 14:04:41 +0000

Part 1 of Why the CAF works: how the Cloud Adoption Framework (CAF) solves governance and scale problems. This one: DDoS protection.

To mitigate the threat from DDoS attacks we can use Azure DDoS Protection. In October 2025 Azure mitigated a 15.72 Tbps DDoS attack from more than 500,000 source IPs, the largest ever seen in the cloud (CPO Magazine). Cloudflare’s 2025 Q4 report shows network-layer DDoS attacks more than tripled in 2025, with attacks reaching 31.4 Tbps.

So the question becomes: how can we use Azure DDoS Protection to automatically protect our Azure estate? The solution needs to work reliably, at scale, under full automation.

A few caveats

When we talk about protecting our Azure estate with DDoS protection, we really mean protecting public IP addresses in Online landing zones in a hub-and-spoke topology. That’s where our network is exposed to the internet. These PIPs might be attached to VMs, Application Gateways, API Management, Bastion, Azure Firewall and so on.

DDoS Protection works at the network layer (L3 and L4). For application-layer protection we need Azure WAF or a similar solution.

PaaS services with public endpoints (for example a storage account) are out of scope. They sit behind Microsoft’s own edge protection, not your VNet.

Azure DDoS Protection is a resource like any other. It lives in the Microsoft.Network/ddosProtectionPlans resource provider.

Which tier do we need?

Every public IP in Azure gets infrastructure protection for free. It’s tuned to protect Azure itself, not your specific workload. Above that there are two paid tiers:

DDoS IP Protection : per-IP pricing, suited to small deployments with a handful of public IPs. You get core DDoS mitigation, but no DDoS Rapid Response, no cost protection and no WAF discount.

DDoS Network Protection : a plan that covers every public IP in any VNet enrolled in it. You also get DRR (access to the DDoS response team during an active attack), cost protection and a discount on Azure WAF.

The key design decision is scale. Once an estate has more than a handful of public IPs, IP Protection’s per-IP pricing quickly approaches the cost of a plan, and the plan covers 100 PIPs. Protect the VNet, not individual IPs. For an enterprise-scale estate, Network Protection is the correct default.

The problem this solves

In the CAF architecture, Online landing zones may be added frequently. Each one gets a spoke VNet, and each spoke VNet might get a PIP. If DDoS enrollment is a manual step, it might be missed or done incorrectly. Either way you end up with unprotected public endpoints. So we treat DDoS protection, along with other aspects of core networking, as a Platform concern. Also DDoS IP protection is less cost effective per resource than a DDoS plan (assuming you deploy more than about 15 PIPs).

This is exactly the class of problem CAF solves: a platform team that owns shared network services, and policy-driven governance that enforces the desired state instead of relying on a documented manual process.

Who owns the spoke VNet?

This is the question the whole design depends on, and it’s easy to skip past.

In the CAF reference model, the spoke VNet isn’t built by the workload team. It arrives with the landing zone through subscription vending. The platform team’s vending pipeline creates the subscription, places it in the Online Management Group, creates the spoke VNet and peers it to the hub. The workload team gets a subscription with its network already connected, and builds inside it.

That vending principal already has rights in the Connectivity subscription, because it has to create the hub side of the peering. That’s also important to note.

The CAF pattern

One plan. Create a single Microsoft.Network/ddosProtectionPlans resource in the Connectivity subscription alongside the hub. One plan can be shared across subscriptions in the same tenant.
Vend VNets already protected. Subscription vending creates each spoke VNet with enableDdosProtection: true and ddosProtectionPlan.id set to the central plan. New landing zones are protected from the moment the VNet exists.
Policy as the guardrail. Assign the built-in Virtual networks should be protected by Azure DDoS Protection (94de2ad3-e0c1-4caf-ad78-5d47bbc83d3d) at the Online landing zones Management Group. Don't assign it at the intermediate root, or it will also catch Platform and Corp VNets (or do, it depends on a few factors). It uses the Modify effect: any VNet created or updated without the plan gets it added in flight, and a remediation task fixes existing VNets.

Vending is the primary mechanism. The policy catches drift and anything created outside vending.

Modify is the right effect here. We’re only setting two properties on the resource being evaluated, there’s no nested deployment, and the VNet is protected at creation rather than minutes afterwards.

Why it works: the join check

Associating a VNet with a DDoS plan is an operation with two scopes. On every VNet create or update that references the DDoS protection plan, ARM checks that the caller has Microsoft.Network/ddosProtectionPlans/join/action on the plan.

Modify alters the caller’s request, so that check runs against whoever made the request. In the CAF model, that’s the platform vending principal, which already has rights in Connectivity. The check passes and everything works.

Remediation tasks for existing VNets run as the policy assignment’s managed identity instead, so that identity needs join rights on the plan too. The portal only grants the roles in roleDefinitionIds at the assignment scope (the Online MG). It doesn't grant anything on a plan in another subscription. Add that grant yourself: a custom role with just ddosProtectionPlans/join/action, or Network Contributor on the plan's resource group.

When the model breaks

The pattern is simple as long as the platform owns the VNet. It breaks when workload teams deploy VNets themselves, for example because:

application teams own their networking end to end,
a workload team takes over the vended VNet in its own IaC and redeploys the whole resource, or
landing zones are built by hand or per team instead of vended.

Now the VNet PUT runs as the workload team’s service principal. Modify adds the plan reference, ARM runs the join check against a principal with no rights in Connectivity (and it shouldn’t have any), and the deployment fails:

LinkedAuthorizationFailed: The client '<sp-object-id>' has permission to perform action
'Microsoft.Network/virtualNetworks/write' on scope 'vnet-spoke-01'; however, it does not have
permission to perform action 'Microsoft.Network/ddosProtectionPlans/join/action' on the
linked scope(s) 'ddos-central'

The policy that was meant to protect the landing zone now blocks the landing zone team from deploying its own network.

Three ways out

Put the ownership boundary back. The platform owns the VNet resource, and workload teams manage subnets, NSGs and route tables inside it. Subnets are child resources with their own PUT, so adding one doesn’t redeploy the VNet. This is the CAF answer, and it keeps the simple Modify pattern.
Grant join rights to workload deployers. Give each landing zone’s deploying principal a custom role with only ddosProtectionPlans/join/action on the plan (most network built-in roles will be too broad). The downside here is it adds permission on a platform resource across every landing zone, and it has to be granted again for each new one. Vending could automate this.
Switch to DeployIfNotExists. DINE doesn’t touch the caller’s request. The VNet is created as normal, the policy evaluates it afterwards, and a deployment runs as the policy assignment’s managed identity to enroll it. Only one identity ever holds join rights. The trade-offs:

The gap: a new VNet is briefly unprotected (typically minutes).
Complexity: a VNet PUT replaces the whole resource, so the template must carry across the existing address space, subnets, peerings and tags.
Flapping: if the workload’s IaC redeploys the VNet without the DDoS properties, the enrollment is removed and DINE adds it back afterwards. Each redeploy opens a short unprotected window.
A policy Denying resources without DDoS protection won't be happy

What the cloud operating model tells you

This is the real lesson, and it’s why the series is called Why the CAF works. Protecting the estate from DDoS is simple (one plan, one built-in policy, one assignment) because the operating model puts VNet ownership with the platform team. The policy effect, the permissions and the failure modes all follow from that one decision.

Move VNet ownership to workload teams and the same control needs extra permissions, a different policy effect, or both. That’s not a flaw in the built-in policy. It’s the cost of changing the operating model. Decide who owns the network first, then pick the mechanism.

Cost notes

A Network Protection plan is a flat monthly charge covering up to 100 public IPs, with a per-IP charge above that. A single plan can be shared across subscriptions in the same tenant. For any estate with more than a few Online landing zones, one shared plan plus policy enrollment is both cheaper and safer than per-IP protection or a manual process. Check current pricing for your region: Azure DDoS Protection pricing.

Summary

DDoS attacks at multi-terabit scale are now commonplace. Azure DDoS Network Protection mitigates L3/L4 attacks against public IPs in enrolled VNets. In the CAF model, the platform vends each spoke VNet already attached to a central plan in Connectivity, and the built-in Modify policy at the Online Management Group catches anything that drifts.

It works because the platform owns the VNet. When workload teams deploy VNets themselves, Modify runs as their principal and fails the join check on the plan. You can restore the ownership boundary, grant workload deployers join rights, or switch to a DINE policy running as a single managed identity. Pick based on who owns the network.

What is an Azure deployment?

Jonny Diamond — Mon, 01 Jun 2026 08:22:36 +0000

I've been thinking recently about what a deployment actually is. When you deploy a resource via the portal, ARM, or Bicep, you'll notice under the deployment scope that there's something called a deployment. This is also apparent when using Bicep modules and CLI deployments.
For example, nesting Bicep modules like this—with a main.bicep file calling modules that call other modules.

When deployed using the az deployment CLI command:

# log into azure 
az login

# create a resource group
az group create -n rg -l uksouth

# create deployment
az deployment group create -n my-deployment -g rg  -f main.bicep

What is ARM

First, let's talk about what Azure Resource Manager (ARM) is. It's the management layer that takes requests for provisioning resources and actions them. When we use the portal, CLI, ARM templates, or Bicep, we're ultimately interacting with ARM. It acts as the management layer, checking the validity of requests and ensuring sufficient permissions (using its own permissions system). All requests for control plane activities and updates are sent to ARM at https://management.azure.com.

The diagram demonstrates this nicely—no matter how the request for resources is made, it's ARM that acts as the management layer for requests, the gateway to the resource providers.
Resource providers are another important component of provisioning Azure services. They're the way ARM distributes requests to the relevant APIs that know how to provision the required resources. For example, a request for a virtual machine like this:

resource vm 'Microsoft.Compute/virtualMachines@2024-03-01' = {
  name: 'myExampleVM'
  location: 'uksouth'
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_B2s'
    }
    osProfile: {
      computerName: 'myvm'
      adminUsername: 'azureuser'
      adminPassword: 'P@ssw0rd123!'  
    }
    storageProfile: {
      imageReference: {
        publisher: 'Canonical'
        offer: 'Ubuntu2204'
        sku: '22_04-lts-gen2'
        version: 'latest'
      }
      osDisk: {
        createOption: 'FromImage'
        managedDisk: {
          storageAccountType: 'Standard_LRS'
        }
      }
    }
    networkProfile: {
      networkInterfaces: [
        {
          id: networkInterface.id  // Reference to a NIC resource (not shown for brevity)
        }
      ]
    }
  }
}

Sent to the Microsoft.KeyVault namespace will fail because Microsoft.KeyVault doesn't know what to do with properties.osProfile.computerName or any Microsoft.Compute properties—as this isn't a Key Vault property (or in the Key vault schema). Only Microsoft.Compute/ knows how to handle it.

Pretty much every resource has a resource provider, which is accessed via ARM.

Microsoft.Compute/virtualMachines
Microsoft.ContainerInstance
Microsoft.ContainerRegistry
Microsoft.AzureStack

These resource providers know how to handle requests for provisioning the resources they control. The resource providers define the operations for managing the resource and its configuration.

They also represent the AUTH layer. You might notice that any resource provider URL looks like an API—that's because it is an API. It has permissions to perform activities or verbs like write, read, and delete. An object in a tenant's directory can have the authorization to perform actions on resource providers.

Microsoft.ResourceProvider/resource/action

This is how authorisation to perform actions on Azure resources—including creating them—works.

Subscriptions need resource providers registered to them, so we can conclude resource providers live in subscriptions. Not enabling resource providers by default is a good security practice.

So ARM takes requests for resources, and resource providers are APIs used to control and manage types of resources. Authorisation is accomplished using permissions over exposed RP APIs. But what is a deployment?

Even the Resource Manager documentation doesn't explicitly call out what a deployment is.

resource - A manageable item that's available through Azure.
resource group - A container that holds related resources for an Azure solution.
resource provider - A service that supplies Azure resources.
declarative syntax - Syntax that lets you state, "Here's what I intend to create,"
ARM template - A JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a resource group, subscription, management group, or tenant.
Bicep file - A file for declaratively deploying Azure resources.
extension resource - A resource that adds to another resource's capabilities.

So a resource is a manageable item, a resource group is a logical container for resources and a resource provider is a service that supplies resources - but still no mention of a deployment.

If we check a subscription's resource providers, we can see a resource provider called Microsoft.Resources, which is "registration free." This means its status—whether registered or unregistered—doesn't matter. You also can't unregister it.

More clues can be found in the output of our deployment above.

{
  "id": "/subscriptions/x/resourceGroups/rg/providers/Microsoft.Resources/deployments/my-deployment",
  "location": null,
  "name": "my-deployment",
  "properties": {
    "correlationId": "51e7f54e-9367-49bb-8a6e-613c00de3884",
    "debugSetting": null,
    "dependencies": [],
    "duration": "PT7.8943772S",
    "error": null,
    "mode": "Incremental",
    "onErrorDeployment": null,
    "outputResources": [],
    "outputs": {
      "greeting": {
        "type": "String",
        "value": "Help Im stuck!"
      }
    },
    "parameters": null,
    "parametersLink": null,
    "providers": [
      {
        "id": null,
        "namespace": "Microsoft.Resources",
        "providerAuthorizationConsentState": null,
        "registrationPolicy": null,
        "registrationState": null,
        "resourceTypes": [
          {
            "aliases": null,
            "apiProfiles": null,
            "apiVersions": null,
            "capabilities": null,
            "defaultApiVersion": null,
            "locationMappings": null,
            "locations": [
              null
            ],
            "properties": null,
            "resourceType": "deployments",
            "zoneMappings": null
          }
        ]
      }
    ],
    "provisioningState": "Succeeded",
    "templateHash": "439532930182033670",
    "templateLink": null,
    "timestamp": "2025-11-23T11:49:51.148630+00:00",
    "validatedResources": null
  },
  "resourceGroup": "rg",
  "tags": null,
  "type": "Microsoft.Resources/deployments"
}

We can see for the fields ‘type’ and ‘id’ the provider is ‘providers/Microsoft.Resources’ and ‘Microsoft.Resources/deployments’ we can also see in the API reference documentation that a deployment is a resource

Okay so what happens when we use this Microsoft.Resources resources to deploy our main.bicep? So the first step is to convert our bicep main.bicep into json

build our arm template

az bicep build --file main.bicep

Next step we create a new file deployment.bicep using the Microsoft.Resources/deployments resource type

resource nested 'Microsoft.Resources/deployments@2021-04-01' = {
  name: 'nestedDeployment'
  properties: {
    mode: 'Incremental'
    template: loadJsonContent('main.json')
  }
}

and we can now deploy this again using az cli

az deployment group create -n my-deployment -g rg -f deployment.bicep --debug

he result is we have another deployment in the portal, but this one contains all our previously nested deployments nestedDeployment, my-deployment then level 1 - level 4. So using Bicep we created a deployment to deploy our deployment which contains 4 other nested deployments. It seems that deployments are how we package requests to ARM for the provisioning of resources and this is automatically done for us by az cli.

Validation and safety nets

So now we know, a deployment is created as a resource itself—specifically a Microsoft.Resources/deployments resource—whose sole job is to orchestrate the creation of other resources defined in its template property. It is the 'container' for the instructions we send to ARM, and because it is a resource, it can be nested inside other deployments just like any other Azure resource.

We can provision resources which aren't wrapped in a deployment by using rest calls for example using the az rest command

➜  what-is-a-deployment az rest --method put \
  --url "https://management.azure.com/subscriptions/xxxx/resourceGroups/rg/providers/Microsoft.Storage/storageAccounts/sa4d56frv67tbyiun?api-version=2023-01-01" \
  --body '{
    "location": "uksouth",
    "sku": {
      "name": "Standard_LRS"
    },
    "kind": "StorageV2",
    "properties": {
      "minimumTlsVersion": "TLS1_2"
    }
  }'

We can bypass the deployment resource and ask the Microsoft.Storage/storageAccounts resource provider to provision a storage account for us, no need to get the deployments resource involved, and we can check this in the portal too.

Summary
An Azure deployment is a special type of resource which acts as a wrapper for requests to ARM. it provides deployment validation, auditability and monitors the progress of a deployment. We can’t know if our template will fail or succeed until we ask the resource provider.

Least privilege as a service for Azure deployments — part 1

Jonny Diamond — Thu, 26 Mar 2026 20:55:04 +0000

Least privilege is a concept that garners a lot of attention from Azure practitioners. It means using the exact required permissions to perform a task, and no more. This sounds great, but in practice it is difficult to achieve and is often added to security assurances as a tick box: “we will follow least privilege.” But when it comes to Azure IaC or template deployments, how can we ever know if a deploying security principal is using the least amount of privilege?

Let’s take an example of an Azure DevOps service connection, created using workload identity federation, which is the recommended approach for creating service connections with ARM roles at scopes such as subscriptions or resource groups. By default, the service principal automatically created at the scope of a subscription has the Contributor role, which in terms of ARM roles is second only to Owner (which can create role assignments). If the IaC template deployed by the service connection only has a storage account and an app service (and only ever will), then it is not following a least-privilege approach. It only needs to deploy an app service and a storage account, no more than this.

Another example might be a Cloud Adoption Framework landing zone scenario. This is where a workload team has a landing zone subscription assigned to it. Then, through proper controls and governance, the workload team can deploy the Azure services they require into this landing zone. What role should the deploying principal get in this scenario? Contributor? Or Owner? Or should it be exactly what it needs to be?

Tracking down the precise permissions a template requires would be fairly arduous, and maybe through a mix of guesswork and trial and error, a lesser amount of privileges could be found. Or we could use a tool that can do this for us.

Azure Minimum Permission Finder (MPF) is a tool we can use to find exactly what permissions IaC templates need to deploy resources. It works by creating a test deployment at the resource group scope. This deployment is used to find the exact permissions ARM needs.

To install azmpf, follow the instructions here: https://github.com/Azure/mpf/blob/main/docs/installation-and-quickstart.md#quickstart--usage

Installation requires downloading and installing the azmpf utility and creating a dedicated MPF service principal.

Let’s create a main.bicep template and parameter file (MPF doesn’t support bicepparam files) which we can point MPF at.

param parStorageAccountName string
param parLocation string = 'uksouth'

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: parStorageAccountName
  location: parLocation
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "parStorageAccountName": {
      "value": "sa5crtvuybghkujk"
    }
  }
}

Once we have created these files we can invoke MPF using the following command

./azmpf bicep --bicepFilePath main.bicep --parametersFilePath params.parameters.json --verbose

More details on how MPF works can be found here: https://github.com/Azure/mpf/tree/main#how-it-works. The long and short of it is that MPF will perform dummy deployments of a template until it gets no authorisation errors, at which point it displays the exact permissions required. Below we can see the output.

------------------------------------------------------------------------------------------------------------------------------------------
Permissions Required:
------------------------------------------------------------------------------------------------------------------------------------------
Microsoft.Resources/deployments/read
Microsoft.Resources/deployments/write
Microsoft.Storage/storageAccounts/read
Microsoft.Storage/storageAccounts/write
------------------------------------------------------------------------------------------------------------------------------------------

So what now? Now that we know the permissions required, we can create a role containing these permissions and assign a service principal this role. Then, using that service principal for the Bicep deployment, we will actually be using least privilege.

But there’s an important distinction to make here. MPF tells us the permissions the template needs, but the template isn’t deploying itself.

Deployment tooling such as the Azure CLI has its own permission requirements on top of what the template needs. MPF works by calling the ARM deployment API directly (PUT on the deployments endpoint). But when you run az deployment group create, the command performs a pre-flight validation (POST on /validate) and checks deployment status (GET on /operationStatuses). These additional API calls require additional permissions that MPF never triggers. This may vary for Azure DevOps built-in tasks, GitHub Actions, or Terraform deployments.

In practice, for our az deployment group create command, this means we need to add these permissions to the MPF output:

Microsoft.Resources/deployments/validate/action
Microsoft.Resources/deployments/operationStatuses/read

Without these, the deployment will fail with AuthorizationFailed errors even though the template permissions are correct.

So the full set of permissions we actually need is the MPF output plus the deployment tooling permissions. This is like two layers: the template permissions (what MPF finds) and the deployment permissions (what the tooling needs to orchestrate the deployment). Both are required for a successful deployment.

So let’s create the role with the complete set of permissions:

az role definition create --role-definition '{
 "Name": "Storage deployer",
 "Description": "Deploy a storage account.",
 "Actions": [
     "Microsoft.Resources/deployments/read",
     "Microsoft.Resources/deployments/write",
     "Microsoft.Resources/deployments/validate/action",
     "Microsoft.Resources/deployments/operationStatuses/read",
     "Microsoft.Storage/storageAccounts/read",
     "Microsoft.Storage/storageAccounts/write"
 ],
 "DataActions": [],
 "NotDataActions": [],
 "AssignableScopes": ["/subscriptions/SUB_ID"] 
}'

Then let’s create a service principal (take note of the app id, password, and tenant id).

az ad sp create-for-rbac -n app-storage-deployer

And finally, assign the role to the app using the role’s GUID as the role:

az role assignment create --assignee APP_ID --role 53f635da-1c50-4f76-8ad2-ba4ba2ac21e9 --scope /subscriptions/SUB_ID

Now sign in as the service principal and perform the deployment.

az login --service-principal --username APP_ID --password SP_PSWD --tenant TENANT_ID
az deployment group create -n storage-deployer -g rg -f main.bicep -p param.parameter.json

{
  "id": "/subscriptions/SUB_ID/resourceGroups/rg/providers/Microsoft.Resources/deployments/storage-deployer",
  "location": null,
  "name": "storage-deployer",
  "properties": {
    "correlationId": "e32d27b5-0d6b-4c40-9103-1ccdf29d896f",
    "debugSetting": null,
    "dependencies": [],
    "duration": "PT2.0994047S",
    "error": null,
    "mode": "Incremental",
    "onErrorDeployment": null,
    "outputResources": [
      {
        "id": "/subscriptions/SUB_ID/resourceGroups/rg/providers/Microsoft.Storage/storageAccounts/sa5crtvuybghkujk",
        "resourceGroup": "rg"
      }
    ],
    "outputs": null,
    "parameters": {
      "parLocation": {
        "type": "String",
        "value": "uksouth"
      },
      "parStorageAccountName": {
        "type": "String",
        "value": "sa5crtvuybghkujk"
      }
    },
    "parametersLink": null,
    "providers": [
      {
        "id": null,
        "namespace": "Microsoft.Storage",
        "providerAuthorizationConsentState": null,
        "registrationPolicy": null,
        "registrationState": null,
        "resourceTypes": [
          {
            "aliases": null,
            "apiProfiles": null,
            "apiVersions": null,
            "capabilities": null,
            "defaultApiVersion": null,
            "locationMappings": null,
            "locations": [
              "uksouth"
            ],
            "properties": null,
            "resourceType": "storageAccounts",
            "zoneMappings": null
          }
        ]
      }
    ],
    "provisioningState": "Succeeded",
    "templateHash": "3036883372851194424",
    "templateLink": null,
    "timestamp": "2026-03-26T20:09:01.653200+00:00",
    "validatedResources": null
  },
  "resourceGroup": "rg",
  "tags": null,
  "type": "Microsoft.Resources/deployments"
}

Excellent: we’ve deployed our IaC using a service principal that has our custom role. The custom role, “Storage deployer,” has only the permissions required by the template for ARM and the Microsoft.Resources/deployments permissions required for the az deployment command (to validate our template and poll its status).

This is great. We have achieved least privilege. But running azmpf manually every time we want to deploy anything can be pretty time-consuming. Could we automate this, or provide it as a service in a landing zone context?

How to validate an Azure deployment?

Jonny Diamond — Sun, 08 Mar 2026 16:57:46 +0000

In my previous blog What is an Azure deployment? we talked about what a deployment was and concluded that a deployment is a container or wrapper around requests to ARM for resources. One of the key advantages of using a deployment to deploy resources is validation or the ability to understand before a request is made whether it is valid.

Why should we validate a deployment?

Just like the practice of defence in depth with security writing IAC should have a quality in depth approach, and just like applying security in a shift left way (doing security earlier rather than later in the process) we should catch quality issues in bicep as far ‘left’ as possible because these same issues are more problematic when caught later.

So what are the layers of quality check we use to make sure Bicep code is high quality, error free and secure?

Lint

Linting is the process of checking code for potential errors and best practice violations. The Bicep CLI has a built-in linter which can lint files we pass to it to find syntax errors and enforce coding standards.

az bicep lint -f main.bicep

So let’s try this out on a Bicep file to see what it comes up with:

param name string
param name string
param anotherParam string = 'usefulString'

resource sa 'Microsoft.Storage/storageAccounts@2032-06-01' = { 
  name: name
  location: 'uksmouth'
  kind: 'BlobStorage'
  sku: {
    name: 'ReallyGood'
  }
  properties: {
    accessTier: 'Hot'
    allowBlobPublicAccess: false
    defaultToOAuthAuthentication: true

    minimumTlsVersion: 'TLS1_8' 
    networkAcls: {
      bypass: 'AzureServices'
      defaultAction: 'Deny'
      ipRules: []
      virtualNetworkRules: []
    }
    supportsHttpsTrafficOnly: true
  }
}

Bearing in mind VS Code has the Bicep linter built in, the az bicep lint command is useful because it means that linting can be performed in a pipeline task for example.

The output shows two errors and two warnings: I’ve declared the ‘name’ param twice and declared ‘anotherParam’ but not used it in the code. So through linting I’ve caught code quality errors, and importantly I can also define what linting checks are performed.

We can also run the build command, compiling Bicep into ARM JSON. This uses the same linting that the lint command uses but also produces an ARM template built from the Bicep passed to the command:

az bicep build -f main.bicep

Custom linter rules

The VS Code extension and the Bicep CLI use default linter rules based on the arm-ttk test cases (https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/linter). Custom linter rules can be added using a bicepconfig.json file placed in your project root:

{
  "analyzers": {
    "core": {
      "enabled": true,
      "rules": {
        "adminusername-should-not-be-literal": {
          "level": "warning"
        },
        "no-unused-params": {
          "level": "off"
        },
        "what-if-short-circuiting": {
          "level": "off"
        }
      }
    }
  }
}

So in the above config we are specifying that the rule ‘no-unused-params’ is off, and now our linter ignores the unused param. The lint command has no output either.

and the lint command has no output either

Validate

From the example above it’s clear that linting can check our Bicep to ensure we’re following best practice and there are no syntactical errors. If we look at the Bicep above we can see the linter is happy with all the properties we have passed — for example the linter expects the minimumTlsVersion value to be a string and as long as a string is passed it’s happy. But we’ve passed ‘TLS1_8’ and TLS 1.8 does not exist. The Bicep is syntactically correct, but it isn’t valid.

In a previous post we talked about what a deployment is (https://medium.com/@jonny\_11585/what-is-an-azure-deployment-e327e4ebc120) — it’s a wrapper around a request to ARM. The az deployment group command has several subcommands such as validate.

Let's run the validate command on our template.

az deployment group validate -g rg -f main.bicep -p name=name

the output of this command shows us our location is invalid:

{"code": "LocationNotAvailableForResourceType", "message": "The provided location 'uksmouth' is not available for resource type 'Microsoft.Storage/storageAccounts'. 
List of available regions for the resource type is 'eastus,eastus2,westus,westeurope,eastasia,southeastasia,japaneast,japanwest,northcentralus,southcentralus,centralus,northeurope,brazilsouth,australiaeast,australiasoutheast,southindia,centralindia,westindia,canadaeast,canadacentral,westus2,westcentralus,uksouth,ukwest,koreacentral,koreasouth,francecentral,australiacentral,southafricanorth,uaenorth,switzerlandnorth,germanywestcentral,norwayeast,westus3,jioindiawest,swedencentral,qatarcentral,polandcentral,italynorth,israelcentral,mexicocentral,spaincentral,newzealandnorth,indonesiacentral,malaysiawest,chilecentral,austriaeast,belgiumcentral'."}

So lint and build missed the invalid location but validate has picked up on it. If we change the location to ‘uksouth’ our Bicep passes validation:

{
  "error": null,
  "id": "/subscriptions/sub_id/resourceGroups/rg/providers/Microsoft.Resources/deployments/main",
  "name": "main",
  "properties": {
    "correlationId": "6d51362d-0ed0-479c-9e00-6d0a04c7df48",
    "debugSetting": null,
    "dependencies": [],
    "duration": "PT0S",
    "error": null,
    "mode": "Incremental",
    "onErrorDeployment": null,
    "outputResources": null,
    "outputs": null,
    "parameters": {
      "anotherParam": {
        "type": "String",
        "value": "usefulString"
      },
      "name": {
        "type": "String",
        "value": "name"
      }
    },
    "parametersLink": null,
    "providers": [
      {
        "id": null,
        "namespace": "Microsoft.Storage",
        "providerAuthorizationConsentState": null,
        "registrationPolicy": null,
        "registrationState": null,
        "resourceTypes": [
          {
            "aliases": null,
            "apiProfiles": null,
            "apiVersions": null,
            "capabilities": null,
            "defaultApiVersion": null,
            "locationMappings": null,
            "locations": [
              "uksouth"
            ],
            "properties": null,
            "resourceType": "storageAccounts",
            "zoneMappings": null
          }
        ]
      }
    ],
    "provisioningState": "Succeeded",
    "templateHash": "12093554567674034375",
    "templateLink": null,
    "timestamp": "2026-03-08T06:52:44.305259+00:00",
    "validatedResources": [
      {
        "id": "/subscriptions/sub_id/resourceGroups/rg/providers/Microsoft.Storage/storageAccounts/name",
        "resourceGroup": "rg"
      }
    ]
  },
  "resourceGroup": "rg",
  "type": "Microsoft.Resources/deployments"
}

But even the validate command has missed many issues with the template: a resource provider API version that doesn’t exist (2032–06–01), the SKU ‘ReallyGood’, minimum TLS version ‘TLS1_8’, and the string ‘car’ in the ipRules array.

param name string
param anotherParam string = 'usefulString'

resource sa 'Microsoft.Storage/storageAccounts@2032-06-01' = {
  name: name
  location: 'uksouth'
  kind: 'BlobStorage'
  sku: {
    name: 'ReallyGood'
  }
  properties: {
    accessTier: 'Hot'
    allowBlobPublicAccess: false
    defaultToOAuthAuthentication: true

    minimumTlsVersion: 'TLS1_8'
    networkAcls: {
      bypass: 'AzureServices'
      defaultAction: 'Deny'
      ipRules: ['car']
      virtualNetworkRules: []
    }
    supportsHttpsTrafficOnly: true
  }
}

By using — debug we can see the validate command reaches out to a validate endpoint

az deployment group validate -g rg -f main.bicep -p name=name --debug

cli.azure.cli.core.sdk.policies: Request URL: ‘https://management.azure.com/subscriptions/my_sub_id/resourcegroups/rg/providers/Microsoft.Resources/deployments/main/ validate?api-version=2022-09-01'

The REST API docs (https://learn.microsoft.com/en-us/rest/api/resources/deployments/validate) describe this endpoint as: “Validates whether the specified template is syntactically correct and will be accepted by Azure Resource Manager.” The key word here is “Azure Resource Manager” — not the resource provider. So the validate command doesn't actually check validity with the resource provider.

What-If

Even the what-if command doesn’t catch these issues. What-if is fundamentally a diff tool, not a validation tool — it compares your template against the current state and tells you what would change, but it doesn’t validate whether those changes would actually succeed:

  + Microsoft.Storage/storageAccounts/name [2032-06-01]

      apiVersion: "2032-06-01"
      id: "/subscriptions/sub_id/resourceGroups/rg/providers/Microsoft.Storage/storageAccounts/name"
      kind: "BlobStorage"
      location: "uksouth"
      name: "name"
      properties.accessTier: "Hot"
      properties.allowBlobPublicAccess: false
      properties.defaultToOAuthAuthentication: true
      properties.minimumTlsVersion: "TLS1_8"
      properties.networkAcls.bypass: "AzureServices"
      properties.networkAcls.defaultAction: "Deny"
      properties.networkAcls.ipRules: [
        0: "car"
      ]
      properties.supportsHttpsTrafficOnly: true
      sku.name: "ReallyGood"
      type: "Microsoft.Storage/storageAccounts"

  * Microsoft.Storage/storageAccounts/3d65fr67tvbiu

Resource changes: 1 to create, 1 to ignore.

The what-if happily echoes back all the invalid values — ‘ReallyGood’, ‘TLS1_8’, ‘car’ — without flagging any of them. It simply says “looks good to me”.

Validation gap

So we have a significant gap: lint/build checks code quality and type structure, validate checks whether ARM will accept the template structure, and what-if shows what would change — but none of them validate whether the resource provider will accept the property values. The only thing that truly validates resource property values is the actual deployment itself.

There are few Azure-native options to fully validate deployments before they run, but there are strategies to make sure our IaC is valid.

Use Azure Verified Modules

Azure Verified Modules (https://azure.github.io/Azure-Verified-Modules/) are Microsoft’s official, Bicep modules that bake in best practices. They use typed parameters with constraints, so many invalid values are visible immediately.

Because the AVM module defines typed parameters with allowed values, passing ‘reallygood’ as a SKU name or ‘TLS1_8’ as a TLS version would be caught at build time — the Bicep compiler knows these aren’t valid values for the module’s parameters. You could also write your own modules that perform similar type validation using @allowed() decorators or user-defined types.

Use PSRule

PSRule for Azure (https://azure.github.io/PSRule.Rules.Azure/) is an open-source tool that validates ARM/Bicep templates against hundreds of rules covering Azure best practices. It runs offline and will catch all the issues in the above template.

PSRule runs on PowerShell and is a good candidate to be integrated into CI pipelines via GitHub Actions or Azure DevOps tasks without needing a local install.

Summary

Validating Bicep deployments requires a layered approach because no single tool catches everything. Lint and build catch code quality issues and type errors. ARM validate catches structural problems and invalid regions. What-if shows what would change but doesn’t validate values. And the resource provider only validates property values at actual deployment time.

Azure DevOps Build Agents: Microsoft-Hosted vs. Self-Hosted vs. Managed Pools

Jonny Diamond — Thu, 19 Feb 2026 06:54:18 +0000

What's the difference between these options and how do they work?

Hosting options

When we want to build code, run code or even deploy some IaC in an automated way, we need somewhere for these commands to run. This is usually just some compute to run CLI commands, and the best choice is to use pipelines. With pipelines we can integrate source control, event triggers and security scanning.

With Azure DevOps we have a few options to host our pipelines, basically we have:

Microsoft hosted Agents

Self-Hosted Agents

These options represent the compute that runs our jobs and tasks.

An Azure DevOps pipeline is broken down into tasks, jobs and stages — each job requires an agent to run tasks, which can be inline scripts or prebuilt tasks we can consume like AzureCLI@2 which can run az cli commands.

Jobs are an extremely important concept for agent hosting. Microsoft provides a free job with up to 1,800 minutes a month, but the catch is only one job can be run simultaneously. If you want to run different jobs at the same time you need to purchase this — so you purchase concurrency. This is also the case for self-hosted agents, which we will go into more detail on.

This is similar to GitHub repositories which provide free GitHub runners, but only if your project is a public one where people can browse to the repo from the internet. Microsoft have recently removed the option to have public Azure DevOps projects, so the table above only really applies if you already have publicly visible ADO projects.

Microsoft hosted build agents

How do I set this up? — Create a pipeline and specify a well-known image in the pipeline, then run.

trigger: none

pool:
  vmImage: ubuntu-latest

The first type of agent hosting is the Microsoft-hosted agent, where Microsoft manages the infrastructure, networking and agent provisioning, and you pass the agent your job. The Microsoft documentation states that each time you run a pipeline you get a fresh virtual machine for each job in a pipeline. This is probably achieved by pre-warmed virtual machine scale set instances which are waiting for job allocation after an instance runs the job it’s then destroyed and replaced by a new instance.

We can do some exploring of a Microsoft hosted image by creating a new pipeline in an azure devops project and running some commands to see what it tells us.

trigger: none

pool:
  vmImage: ubuntu-latest

jobs:
- job: forensicInspection
  displayName: "inspecting microsoft hosted agents"
  steps:

  - bash: |
      echo "env with grep"
      env | sort | grep -E 'SYSTEM_|BUILD_|AGENT_|GITHUB_' || true
    displayName: "environment variables filtered with grep"

  - bash: |
      echo "env no grep"
      env 
    displayName: "environment variables"

The output will give some additional insight into the agent

AGENT_ACCEPTTEEEULA=True
AGENT_BUILDDIRECTORY=/home/vsts/work/1
AGENT_ID=8
AGENT_ISSELFHOSTED=0
SYSTEM_ISAZUREVM=1
SYSTEM_ISDOCKERCONTAINER=0
SYSTEM_TASKINSTANCENAME=Bash1
VSTSAGENT_CONTINUE_AFTER_CANCEL_PROCESSTREEKILL_ATTEMPT=true
VSTSAGENT_DOCKER_ACTION_RETRIES=true
BUILD_ADVANCEDSECURITYENABLED=false
BUILD_QUEUEDBY=Jonny Diamond
BUILD_REPOSITORY_PROVIDER=TfsGit
BUILD_SOURCEBRANCH=refs/heads/main
BUILD_SOURCEBRANCHNAME=main

The different environment variables have prefixes which give insight into what they are for. For example, BUILD_xx supplies information like the repository, who queued the job and whether Advanced Security is enabled (that’s probably GitHub Advanced Security). SYSTEM_TASKINSTANCENAME tells the agent you are running bash tasks, so expect bash commands. We can also see AGENT_ISSELFHOSTED , SYSTEM_ISAZUREVM and SYSTEM_ISDOCKERCONTAINER — these tell us that we aren’t using a self-hosted agent, it’s an Azure virtual machine, and that it’s not a Docker container. These variables are provided to an agent at execution runtime; it’s a bit like saying “here is the repo, here is the code and this is what you’re doing.”

Managed DevOps Pools

How do I set this up? — Deploy network resources, Dev Center, Dev Center project, then the Microsoft.DevOpsInfrastructure/pools resource. Add the pool in ADO.

The other flavour of Microsoft-managed agents is Managed DevOps Pools. These are agents which are managed on behalf of the customer by Microsoft. The compute is actually hosted in a Microsoft subscription, with the option to VNet-inject into a subnet of your choice by delegating the subnet to the Microsoft.DevOpsInfrastructure/pools service.

When a pipeline is triggered and Azure DevOps requests an agent, a virtual machine agent is provisioned in a Microsoft-managed subscription. The VM’s NIC is injected into your delegated subnet as below.

We can see this in our lab by viewing the connected devices in our delegated subnet.

The subnet is delegated to the resource provider Microsoft.DevOpsInfrastructure/pools. This allows virtual machine agents in Microsoft’s managed subscription to have their NICs injected into this subnet, effectively surfacing the Managed DevOps Pool resource inside our virtual network.

In fact, if we click on the virtual machine in the portal under connected devices, we can see some more interesting information. We can see the Microsoft subscription it lives in and the tenant too. I am unable to list the resource as the issuer of the access token is not the correct tenant:

{

“code”: “InvalidAuthenticationTokenTenant”,

“message”: “The access token is from the wrong issuer ‘https://sts.windows.net/my_tenant_id/'. It must match the tenant ‘https://sts.windows.net/microsoft_tenant_id/' associated with this subscription. Please use the authority (URL) ‘https://login.windows.net/microsoft_tenant_id' to get the token. Note, if the subscription is transferred to another tenant there is no impact to the services, but information about new tenant could take time to propagate (up to an hour). If you just transferred your subscription and see this error message, please try back later.”

}

This demonstrates the VM exists in Microsoft’s subscription, but its network interface is injected into our subnet. All traffic flows through our network infrastructure, giving us full control over routing, NSGs and firewall rules. It also demonstrates that Managed DevOps Pools run on virtual machine scale sets.

Self-Hosted agents

How do I set this up? — In ADO > Project Settings > Add Agent Pool > Self-Hosted. Generate the zip and put it on your compute of choice.

The third option is self-hosted agents. In this scenario you host the agent yourself on your compute of choice: virtual machines, VMSS, Azure Container Apps or even AKS. The key difference between Microsoft-hosted or Managed DevOps Pools and self-hosted is that, as opposed to job sessions being provisioned on demand, self-hosted agents are instead long-running processes which poll Azure DevOps for jobs — they are always running and always listening for jobs.

Azure Virtual Machine Scale Sets

How do I set this up? — Deploy a VMSS, navigate to “Add Pool” in ADO, select the VMSS.

The final option is self-hosted on VMSS. This was Microsoft’s preferred choice for self-hosted agents, which allowed agents to be provisioned on an existing VMSS service to simplify deployment — no manual deploying of the agent. It’s also the inspiration behind Managed DevOps Pools. In this model, ADO manages the scaling when there are no agents waiting to pick up jobs or there are fewer agents than there should be. Like other self-hosted options, you can decide on the size and image you are running too, unlike the Microsoft-hosted agents which probably use Dasv5-size VMs.

Summary

So to host our ADO pipeline agents we have two main options: Microsoft-hosted and self-hosted. Managed DevOps Pools provide managed-on-behalf-of infrastructure injected into your network. Microsoft-hosted agents are fast to provision and useful in most cases, but they don’t have line of sight to private resources. Self-hosted agents maximise customisability but come with obvious management overhead, and you will still need to pay to run more than two jobs.