Azure Community-Policy holds custom policy definitions you must test yourself

A shared shelf of policies, not a product

The stated purpose is collaboration rather than distribution. The README says the repository is for Azure Policy users and Microsoft internal teams to share and collaborate on custom policies, and that these policies are built either by customers or by Microsoft Support engineers for customers. The critical sentence is the warning that follows: these are not built-in policies, hence they are not checked, tested or validated in any form by the Azure Policy release team, and readers are told to be wary of this and always test their policies before enforcing. That sentence defines the project's status precisely. A built-in policy comes with a product team behind it, a test matrix and a compatibility promise. A community policy is a starting point written by whoever hit the same requirement, published so that others can adapt it. The repository is MIT licensed, it is not archived, and the last push was on 2026-10-19, so it is an active collaboration space with a steady trickle of contributions rather than a curated catalogue. The audience is Azure governance engineers who know what a policy definition is and want a reference implementation, not a developer who wants a plug and play control.

The directory layout separates custom policies from the reference sets

The top level listing shows several directories that carry the actual content. Policies/ is where the contributed custom policies live, which is where you look for a starting point for your own guardrail. policyDefinitions/ and policySetDefinitions/ hold policy definition JSON and policy set definition JSON respectively, which is the structure Azure Policy itself consumes when you create a definition or a group of definitions to assign together. Scripts/ contains tooling, and the README names one of them, a PowerShell script that validates your policy against the contribution guide and fixes problems for you, and the project also has a Customer panel slide-recordings/ directory for recorded sessions. Separating the contributed policies from the definition and set definition directories matters for how you consume it. A policy definition is a single control, and a set definition is a bundle of them that you can assign as a unit, and the difference is what you point an assignment at. The other structural fact is that the primary language for this repository is listed as the Open Policy Agent, which is the Rego policy language that Azure Policy uses for its custom policy definitions, and it tells you what kind of artefact you are actually reading. You are reading Rego expressions wrapped in Azure Policy's JSON envelope, not a deployment script.

Taking a definition from the repository to an assignment

There is nothing to install. The repository holds JSON artefacts and Rego, and the tool the project gives you to work with them is a PowerShell script in the Scripts directory, Confirm-PolicyDefinitionIsValid.ps1, which validates a policy against the contribution guide and fixes problems for you. The flow for an adopter is therefore a four step reading of the repository layout. First, find the shape you need in the Policies directory, where contributed custom policies live, and note whether the thing you found is a single policy definition or a set definition, because policyDefinitions and policySetDefinitions are the two other content directories and an assignment points at one of them. Second, copy the artefact into your own repository rather than editing it in place, since the project is a collaboration space and your changes belong in your deployment pipeline. Third, run the validation script on your copy, which checks it against the contribution guide and repairs the mechanical problems, and read the diff it produces so you know what it changed. Fourth, assign the definition using the route the documentation describes, through the portal, Azure PowerShell or the Azure CLI, and start in audit mode rather than enforce. The README's instruction to always test before enforcing is the whole method in four words, and the articles it links for assignment and for effects are the reference for what each effect does to a resource. A definition that fails validation is a broken definition, and a definition that passes validation may still enforce the wrong thing, which is why the fourth step exists.

Contributions run through a CLA and an automated validity check

The contribution path is described in enough detail to tell you what a good pull request looks like. The project welcomes contributions and suggestions, and most contributions require you to agree to a Contributor License Agreement declaring that you have the right to, and actually do, grant the rights to use your contribution, with the details at the Microsoft CLA site. When you open a pull request, a bot automatically determines whether you need to provide a CLA and decorates the pull request accordingly, and the README notes that you only need to do this once across all repos using that CLA. The practical gate is the PowerShell script, Confirm-PolicyDefinitionIsValid.ps1, which validates your policy against the contribution guide and fixes problems for you. That script is the closest thing the repository has to a test suite, and it is worth understanding what it is. It checks a definition against the contribution guide, so it catches structural and editorial problems. It does not evaluate whether your policy logic does what you think it does, and the README's warning that nothing here is tested by the release team applies to the script's output as much as to the definitions. The project also has adopted the Microsoft Open Source Code of Conduct.

Support for this repository is explicitly outside the usual channels

This is the part that catches people out, so it is worth stating plainly. The README says the general Azure Policy support role that this repository has is not supported by standard Azure support channels. The listed routes for help are the Microsoft Tech Community Azure Governance conversation space, the monthly call on Azure Governance, and the StackOverflow tag for azure-policy, for general questions that the Azure Policy documentation does not answer. If your questions are more in depth or involve information that is not public, the answer is to open an Azure Customer Support ticket. For documentation corrections there is a feedback area at the bottom of each page, and for proposing a new built-in policy there is a separate Azure Governance Ideas board, whose suggestions are actively reviewed and prioritised for implementation. So there is a genuine path from a custom policy you wrote to a built-in one, but it is a proposal path, not a support path, and it applies only to policies Microsoft would want to ship. For livesite issues that may be caused by problems in Azure Policy itself, the README still directs you to a support ticket. Nothing in this repository gives you a warranty.

Why you would write a custom policy in the first place

The existence of this repository implies the gap. Azure Policy ships a large catalogue of built-in policies, and the README points to the separate azure-policy repository for those, so the division of labour is explicit. A custom policy is needed when the built-in library does not cover a control you have to demonstrate, which is common for a customer with a specific regulatory or internal baseline, or when you need a control that combines several conditions in a way no built-in definition expresses. The mechanics of assignment are documented rather than assumed, with articles covering the Azure Policy overview, how to assign policies through the portal, through Azure PowerShell and through the Azure CLI, plus the definition structure, the policy effects, how to create policies programmatically, how to get compliance data and how to remediate non-compliant resources. The effect model is the part to read before authoring, because a definition can audit, deny, modify or append the effect, and a policy deployed with the wrong effect will either do nothing or break a subscription. The point of Community-Policy is that someone has already written the Rego for the common cases, so you are editing a definition and its assignment rather than authoring from an empty file.

What it costs to adopt, and what the licence covers

The licence is MIT, with the licence file at the root of the repository, so the definitions can be copied, modified and used inside a commercial Azure deployment without copyleft obligations, and your own legal review should confirm that for your situation rather than take the badge as the answer. The real cost of adoption is engineering time, not licence terms. A custom policy that is not validated by anyone has to be tested by you, which means running it against a subscription you can afford to disturb, checking the compliance data it produces, and verifying the effect behaves as intended on the resource types you care about, and that is work the repository explicitly leaves to you. There is also a maintenance obligation that built-in policies do not create. A custom definition is yours to keep in step with the Azure Policy schema, and when Microsoft changes the platform the definition you copied may need updating, with no upstream to pull the fix from unless the community publishes it. The maintenance status of the repository itself is recent, with the last push on 2026-10-19, and the two releases on record, 100911 and 100908, are dated 2019-11-19, so the release tags are not a useful signal of activity here. What signals activity is the commit history and the Policies directory, and the two GitHub releases that exist carry the label Official Microsoft Sample from 2019 and say nothing about the current content. Treat the repository as a live collection rather than a versioned product.

Editorial conclusion

Community-Policy suits an Azure customer who needs a policy the built-in library does not have and wants to see how others solved the same guardrail, and who has the time to validate, test and adapt a Rego definition before turning it on in enforce mode. It does not suit anyone who wants a policy that Microsoft stands behind, because the README states these are not built-in policies and are not checked, tested or validated in any form by the Azure Policy release team, and it does not suit a team that has no way to test a policy against a subscription before enforcing it. Before you adopt a definition from the Policies or policyDefinitions directories, run the repository's own Confirm-PolicyDefinitionIsValid.ps1 script against it, then test the policy against a non production subscription, and only then consider an assignment.

Frequently asked questions

Official sources

1. Azure/Community-Policy on GitHub
2. Issues
3. License: MIT
4. README
5. Releases