Can we define Azure Policy Definitions with different scopes in EPAC?

[kalevivek1988]

Hi Team,

We are exploring the usage of this repo for our environment and have a requirement to create Azure Policy Definitions with different scopes (not just assignments but the definitions themselves).

Is it possible to define policy definitions with a specific scope using this framework?

Or does it only support centrally defined policy definitions (management group / subscription level) and then handle scope at the assignment level?

Any guidance or example for handling multiple scopes for definitions would be really helpful.

Thanks in advance!
Vivek

[brianmooremsft]

My understanding is that with the Azure Policy specifications, policy definitions do not explicitly support the inclusion of a scope; only policy assignment definitions explicitly support a scope property. Policy definitions do support a "location" - such as a subscription or management group -where the policy will be stored. Location will then put a constraint on what "scope" can be allowed for assignment, as the scope must be somewhere below the hierarchy of the location. EPAC will follow these Azure Policy specifications. Perhaps you could provide a little more detail on what is driving the requirement to have policy definitions themselves limited to specific scopes, instead of using policy assignments. Brian From: Vivek Kale - RIT ***@***.***> Sent: Thursday, July 24, 2025 8:14 AM To: Azure/enterprise-azure-policy-as-code ***@***.***> Cc: Subscribed ***@***.***> Subject: [Azure/enterprise-azure-policy-as-code] Can we define Azure Policy Definitions with different scopes in EPAC? (Discussion #1010) Hi Team, We are exploring the usage of this repo for our environment and have a requirement to create Azure Policy Definitions with different scopes (not just assignments but the definitions themselves). Is it possible to define policy definitions with a specific scope using this framework? Or does it only support centrally defined policy definitions (management group / subscription level) and then handle scope at the assignment level? Any guidance or example for handling multiple scopes for definitions would be really helpful. Thanks in advance! Vivek - Reply to this email directly, view it on GitHub<#1010>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ASWPRU3F7TIBEQJ4GIQTIRT3KDZ5HAVCNFSM6AAAAACCJE5SU6VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZYGYZDSMBZGY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[wrzn040]

Hi @brianmooremsft ,

our requirement comes from the fact, that we manage an enterprise scale platform for multiple subsidiaries of our company. See our management group structure attached. We as the central DevOps / platform team, manage everything below the "Managed" management group.

We are aware, that policies are not active unless we assign them at a certain scope, and that we can assign the same policy on multiple different scopes below the policy definition location. Currently we define some of our policies under the "Managed" management group and some under the "Landing Zones". In the near future we plan to give the subsidiaries the option to request specific policies for their countries - e.g. subsidiary 1 having a different compliance requirement than subsidiary 2 - that's why we bring up the question of "scoping" or defining the policies under different management groups. At the moment, we would need to migrate all our existing definitions to the "Managed" management group, if we start utilizing EPAC as our policy management tool. It would also mean, that if we get a specific request aplicable only for "subsidiary 1", the definition will be available as well for all the other subsidiaries, even if it's not their concern. We are aware, that in practice it's probably no difference for the users, as having a definition available does not impact them any way. But as Azure offers this functionality by default (having different policy definition locations and not just one central), we would welcome if EPAC could reflect the same.