Azure Policy at Scale, Part 2: What “supported” actually means

Written in a personal capacity. I work as a Microsoft Cloud Solution Architect, but this series is my own research and my own opinion. It is not an official Microsoft position.

This is Part 2 of Azure Policy at Scale: Native ALZ Governance vs EPAC. Part 1 argued that the usual tool-versus-tool comparison fails, and it ended on a distinction I said would matter here: ALZ and AVM are not the same layer, and when you ask whether something is supported, the answer depends on which layer you are asking about.

This part tests that. It is the part of the series that needs the most precision, so almost everything below is a direct quote with a link, and I have tried to keep my own reasoning clearly separated from what the documents actually say.

The objection

There is one objection to EPAC I hear more than all the others combined, and it is usually the end of the conversation rather than the start of one:

“It’s not supported.”

Its mirror image is the positive case for the native path: choose ALZ and you are on the supported road. I have heard both stated as settled fact by people who know this domain well. I have also, in earlier engagements, made a softer version of the argument myself, which is part of why I wanted to check it properly rather than keep repeating it.

It is a good objection to test, because unlike most of this debate it is not a matter of taste. Either the support statements say something, or they do not.

What I actually did

On 24 August 2026 I traced the support statements across every repository in the six-layer implementation chain I defined in Part 1, plus the Azure Verified Modules support statement and FAQ, and the relevant Cloud Adoption Framework pages. Not summaries of them. The files.

That is a defined scope rather than an exhaustive one. The wider accelerator ecosystem has more repositories than the six layers — I checked two of the closest neighbours below — and I have not read every repository that could conceivably run in an ALZ deployment.

That sounds almost too simple to be worth writing up, and honestly I expected it to take an afternoon and produce a paragraph confirming what everyone already believed. Every file quoted below is two clicks from this page, and I would rather you checked than took my word for it.

The statements, word for word

Here is the whole picture, using the layering from Part 1. In every case, “the resources listed above” means GitHub Issues in that repository.

Layer	Repository	What its support statement says
Guidance	`Azure/Azure-Landing-Zones`	“Support for this project is limited to the resources listed above.”
Data	`Azure/Azure-Landing-Zones-Library`	“Support for this project is limited to the resources listed above.”
Engine (Bicep)	`Azure/bicep-registry-modules`	Points at the AVM support statement
Engine (Terraform)	`Azure/terraform-azurerm-avm-ptn-alz`	Points at the AVM support statement
Composition	`Azure/alz-bicep-accelerator`	“Support for this project is limited to the resources listed above.”
Bootstrap	`Azure/accelerator-bootstrap-modules`	“Support for this PRODUCT is limited to the resources listed above.”
EPAC	`Azure/enterprise-azure-policy-as-code`	“Support for Enterprise Policy as Code is limited to the resources listed above.”

Read the first column and the last one together, because that is the finding in miniature. Note the two engine rows, though: they are the exception, they do not say this, and they get a section of their own below.

EPAC’s support statement is materially the same sentence as the ones published by most of the non-AVM repositories in the native chain. The only difference is that somebody filled in the project name.

In the bootstrap repository — the one whose Terraform modules stand up “the accelerator bootstrap environments for Azure Landing Zones”, the repositories and pipelines your landing zone is deployed from — nobody filled it in. It still says “this PRODUCT”, in capitals, under a heading that reads “Microsoft Support Polic”, missing its last letter. My reading of that typo is that these files are a template applied across an organisation’s repositories, and that this copy was never proof-read. That is an inference about a process, not a claim about what anyone intended, and I would not build much on it. What I would say is that a templated file which nobody noticed was truncated cannot carry the weight of an architectural decision.

I also checked two repositories just outside the six layers, because a real deployment passes through them: Azure/alz-terraform-accelerator carries the same one-line statement, and Azure/ALZ-PowerShell-Module says “Support for this PROJECT or PRODUCT is limited to the resources listed above” — a second copy with the blank still in it. Neither changes the analysis. Both widen it.

Four of the six repositories in the chain carry the same one-line statement as EPAC. That was not what I expected to find, and at that point I still assumed the real support story lived somewhere else — in the official documentation rather than in a repo footer.

The sentence that changed my mind

It does live in the official documentation. It just does not say what I assumed.

The Cloud Adoption Framework page Keep your Azure landing zone up to date lists reasons to stay current. One of them is headed Get support:

“A landing zone, as a deployable reference and implementation, is an open-source project, so support is limited to community engagement. Keeping your landing zone aligned to the current implementation makes community support more likely.”

That is Microsoft Learn. Not a GitHub footer, not a community wiki — the Cloud Adoption Framework, inside the landing zone design area, on a page that has been maintained for years.

Note how carefully it is worded. “As a deployable reference and implementation.” The architecture is guidance and stays guidance. The thing you actually deploy is an open-source project, and its support is community engagement.

I went looking for a support asymmetry so I could document it fairly and hand the native path a point it had earned. There is one, it is real, and the next section is about it. But it does not sit where the objection puts it: it is a property of one layer, not of “ALZ” as a whole. The premise of the most common objection in this entire debate — that the native path is supported end to end and EPAC is not — is not what these documents say.

I want to be precise about the size of that claim, because it is easy to overstate in both directions. It does not mean the two paths are equivalent — the next two sections set out a genuine advantage the native path has. It means that “one is supported and the other is not”, said of two whole stacks, is not a true description of the choice.

What AVM actually commits to

There is one layer with a serious support position, and it is stronger than I first gave it credit for. I had this section written the other way round until I read the FAQ properly, which is a good argument for reading the whole site rather than the one page you went looking for.

Start with what AVM says it is. Its FAQ, under the heading Is AVM a Microsoft official service/product/library or is this classified as an OSS backed by Microsoft?:

“AVM is an officially supported OSS project from Microsoft, across all organizations.”

“AVM is owned, developed & supported by Microsoft, you may raise a GitHub issue on this repository or the module’s repository directly to get support or log feature requests.”

“You can also log a support ticket and these will be redirected to the AVM team and the module owner(s).”

And then, in its own heading, the question everyone in this debate actually wants answered — So, does CSS support AVM?:

“Yes, and if they cannot resolve it (and/or it’s not related to a Microsoft service/platform/api/etc.) they will pass the ticket to the module owner(s) to resolve.”

That is not community support with extra steps. It is a documented CSS support entry point for an open-source project. I had written this section as though AVM’s advantage amounted to published GitHub response targets, and that was wrong. A support ticket is a legitimate way in, and Microsoft says so on the project’s own site.

The module support statement then sets out what happens on the GitHub side:

“5 business days for a triage, meaningful response, and ETA to be provided for fix/resolution by module owner (which could be past the 5 days)”

and for feature requests:

“15 business days for a meaningful response and initial triage to understand the feature request. An ETA may be provided by the module owner if possible.”

If the module owner misses that, the AVM core team is notified and attempts to respond within a further five business days. For security issues, the Bicep or Terraform product groups may step in after another five. That is a genuine escalation ladder, and nothing else in this discussion has one.

Two things keep it honest. The first is the scope of the promise:

“Please note that the durations stated above are for a reasonable and useful response toward resolution of the issue raised, if possible, and not for a fix within these durations; although if possible this will of course happen.”

A response, not a fix. The second is that the statement is recent: it was updated in June 2025, relaxing the previous three-business-day target to five. The announcement explains why with more candour than these posts usually contain:

“Being honest, we weren’t meeting the previous support statement 100% of the time, which we are striving for, across all the AVM modules.”

“Module owners are not 100% dedicated to only supporting their AVM modules; they also have other daily roles and responsibilities in their jobs at Microsoft.”

I quote that with respect rather than as a gotcha. Publishing a target, measuring yourself against it, admitting in public that you missed it, and then revising it with your reasoning attached is better engineering governance than quietly leaving the old number up. The same page also documents what happens when maintainers stop responding: modules become “orphaned”, get listed, and wait for a new owner. Both facts belong next to the support statement, not instead of it.

So “Supported by Microsoft”, which AVM uses prominently, holds up. AVM defines the term itself:

“The modules are supported by Microsoft, across it’s many internal organizations, as described in [Module Support]”

The thing to be careful about is not whether it is true. It is what it covers. Read the FAQ answers again and notice what they are about: this repository, the module’s repository, the module owners. The commitment is to AVM modules. It is not a statement about the ALZ Library, the accelerators, the bootstrap modules or the PowerShell module, each of which is a separate project with the one-line statement quoted earlier.

That distinction is the whole point of this post, and it is why the layering from Part 1 matters.

Module or platform: the distinction that does the work

The module support statement also contains the single most useful sentence in this whole area, and it is the other half of the FAQ answer above:

“If an issue is likely related to the Azure platform, its APIs or configuration, script or programming languages, etc., you need to raise a ticket with Microsoft CSS (Microsoft Customer Services & Support) where your ticket will be triaged for any platform issues. If deemed a platform issue, the ticket will be addressed accordingly. In case it’s deemed not a platform but a module issue, you will be redirected to submit a module issue on GitHub.”

Put the two together and the routing works in both directions. Platform problems go to CSS wherever they surface. Module problems are best raised on GitHub, and if you take one to CSS instead, it gets passed along rather than turned away.

That reframes the risk considerably, and in a direction that should be reassuring whichever path you pick. Azure Policy is a first-party Azure service. Your policy definitions, set definitions, assignments and exemptions are Azure resources, created through Microsoft.Authorization, evaluated by the platform, and reported on by Microsoft.PolicyInsights. If a policy evaluates incorrectly, if compliance data goes stale, if a DeployIfNotExists remediation fails against the resource provider, that is a ticket CSS will triage, and which tool wrote the resource is not what decides whether they do. Plenty of those tickets come back as something other than a platform defect — policy logic, a parameter, a remediation identity missing a role assignment — and then you are back in your own repository. But the door is the same door on both paths.

What differs is what happens once you are through it. For an AVM module, there is a documented onward route and a named team at the other end. For the ALZ Library, the accelerators, the bootstrap modules and EPAC alike, the published answer is a GitHub issue in that repository.

One honest caveat, and it is a real one. I looked for a Microsoft page stating as a general principle that Azure support covers Azure resources but excludes open-source deployment tooling, and I found no such statement. Nor did I find a documented CSS entry point for the ALZ Library, the accelerators, the bootstrap modules or EPAC comparable to the one AVM publishes — but an absence of documentation is not a documented absence, and I would not want that read as a rule about what CSS will or will not accept. What I have is the routing quoted above, the FAQ answers, and the Cloud Adoption Framework sentence about community engagement. The picture I build from them is my reading, not a quote.

So where does the boundary actually run?

Putting the evidence together, the honest picture is three tiers rather than two camps — and the boundary between them cuts through the native stack rather than around it.

Tier	What is in it	What the documentation says you get
The platform	Azure Policy itself: definitions, assignments, exemptions, compliance data	CSS triage on the terms of your own support agreement, whichever tool created the resource
AVM modules	`avm/ptn/alz/*` on Bicep and Terraform	An officially supported Microsoft OSS project: CSS is a valid entry point, plus published target response times and an escalation ladder on GitHub
The rest of the tooling	ALZ guidance, the ALZ Library, the accelerators, the bootstrap and PowerShell modules — and EPAC	GitHub Issues in the relevant repository, per each project’s own statement. No published response-time commitment found for any of them

Be careful with that third row. Those projects are not interchangeable just because their SUPPORT.md files read alike — they have different maintainers, different release cadences and different levels of activity, and a similar sentence is not a similar experience. What they share is the published commitment, which is the same in each case: raise an issue.

Now the fair reading, including the part that does not favour my own hypothesis.

There is a real difference, and it is the middle tier. The native path runs through AVM, which is explicitly supported by Microsoft, has a documented CSS entry point, publishes response targets and has an escalation ladder. EPAC has none of that documented, as far as I can find. If you want to argue that the native path carries a stronger support commitment than EPAC, that is the argument, it is legitimate, it is better than the argument people usually make, and I am not going to explain it away.

But be precise about what it covers. AVM is the engine. The ALZ Library carries much of the policy baseline and archetype content that the native implementation consumes — though your actual policy estate will also contain Azure built-ins, your own parameters and overrides, and whatever custom definitions and custom library content you add. Those layers sit outside AVM’s statement.

So the accurate version of the support argument is narrower than the one people make, and sharper. Choosing the native path buys you a genuinely supported module layer. It does not wrap one support boundary around the entire ALZ implementation stack, and it does not move your policy content into a different tier from EPAC’s.

What EPAC says about itself

For completeness, since projects making inflated claims about themselves is a real phenomenon: EPAC does not.

Its documentation describes it as:

“an open source community project that provides a CI/CD automation solution for the development, deployment, management and reporting of Azure policy at scale”

and describes its provenance precisely:

“three distinct open source projects or tools internally developed and maintained by Microsoft employees”

I found no claim anywhere on the EPAC documentation site that it is “supported by Microsoft”. Its self-description — an open-source project maintained by Microsoft employees — is more accurate than most of what gets said about it in either direction.

The same page also does something I did not expect. It routes readers away from itself:

“If your DevOps (CI/CD) maturity is lower, Azure Landing Zones direct implementation of Policies might be a better choice.”

That is EPAC’s own documentation making the argument I set out in Part 1, about EPAC.

What this does not mean

Four guardrails, because this finding is easy to over-read in both directions.

It is not an argument for adopting EPAC. Removing a bad reason to reject something is not the same as producing a good reason to adopt it. My hypothesis from Part 1 — default to native, treat EPAC as a deliberate exception requiring a named requirement — survives this, and on the support question it now rests on something better than a slogan. Supportability is a legitimate factor in favour of the native route, because one layer of it is genuinely supported by Microsoft. What it is not is a knockout argument about two whole stacks.

It is not a claim that support does not matter. It matters a great deal. But in my experience, on an active project with responsive maintainers, a well-written GitHub issue is often answered faster than a low-severity ticket — and both of these projects are active. That is my experience rather than a documented commitment, and it cuts the other way for anything urgent enough to justify a high severity. Community support is not a synonym for no support; it is a different mechanism with different failure modes.

It is not a criticism of anyone’s documentation. Every statement quoted here is published, findable and internally consistent. Microsoft says plainly that a deployed landing zone is an open-source project with community support, and AVM says just as plainly that it is officially supported by Microsoft. Both are true, of different layers. The gap is not in the documentation. It is that these sentences live on pages nobody reads while making a tooling decision — one of them on a page about keeping your environment up to date — so a folk version circulates instead, and the folk version has no layers in it at all.

It is not a statement about your agreement. If you hold a Unified Support contract, a partner arrangement, or anything negotiated, your entitlements may differ from what a public SUPPORT.md implies. I cannot see your contract. If support is genuinely the deciding factor for you, that is a question for your account team with a specific scenario attached — not something to settle by reading a repository footer, which is exactly what I have just spent three thousand words doing.

Better questions than “is it supported?”

The question is close to useless in the form people ask it, because it is asked of two whole stacks and answered per layer. Three replacements that can actually be answered:

When this breaks at two in the morning, who fixes it? In my experience, on both paths: your team, that night. If it looks like the platform, a ticket; if it is an AVM module, a ticket or a GitHub issue; if it is anything else in either chain, a GitHub issue in the morning. If that answer is unacceptable, most of it is unacceptable for the native path too, and the conclusion is about your operating model rather than your tooling.

What is the blast radius when it goes wrong? Here the two genuinely differ, and this is the question I would actually spend time on. EPAC’s own documentation is blunt about its model: it “takes possession of all Policy Resources at the deploymentRootScope and its children” and “will delete any Policy resources not defined in the EPAC repo”. The native path has its own removal semantics through Deployment Stacks. Those are different risks with different mitigations, and Part 3 takes them apart properly.

Can you hire or contract someone who knows it? For an operating model you cannot easily change later, that is a more practical support question than any statement of intent, and unlike “is it supported” you can find out.

What I could not establish

In keeping with the sourcing rules I set out in Part 1, the absences — phrased as absences of documentation, not claims about the world:

I found no Microsoft page stating explicitly, as a general principle, that Azure support excludes open-source deployment tooling. The distinction is established by routing, not by declaration.
I found no published response-time target for EPAC, equivalent to AVM’s.
I found no documented CSS entry point for EPAC, the ALZ Library, the accelerators or the bootstrap modules comparable to the one AVM’s FAQ publishes. That is an absence of documentation, not evidence that a ticket would be refused.
I found no support statement on the ALZ documentation site itself. The statements live in the repositories and in the Cloud Adoption Framework.
I found no differentiation in AVM’s support statement between resource, pattern and utility modules. One statement covers all of them.
I did not read every repository in the wider accelerator ecosystem. My scope was the six-layer chain from Part 1 plus the two adjacent repositories named above.

Everything above reflects what I could verify on 24 August 2026. Support statements change — AVM’s changed in June 2025 — so check the current versions before you decide anything on them.

Part 3 is One library, two engines: how both routes can now draw their policy content from the same ALZ Library, why that is not the same claim as sharing a data layer — EPAC still keeps its own repository as the operational source of truth — why Deployment Stacks are not a generic “AVM capability”, and a correction to a claim about them that I see repeated constantly, including by me until recently.

For this part, the summary is short. Both approaches deploy first-party Azure Policy resources, so platform support does not depend on which tool created them. The native route does pass through AVM, which has an explicitly stronger Microsoft support position than EPAC — that is a real advantage and it deserves to be argued properly. What it does not have is one support boundary wrapped around the whole ALZ implementation stack. “Supported” is a property of individual layers, not of “ALZ versus EPAC” as two indivisible products, and if the folk version of it was the deciding factor in your policy operating model, it is worth going back and finding the real one.