A state cloud team assigns Azure Policy at a parent management group that contains several city subscriptions. What describe-level behavior should leaders expect?

Azure Policy assigned at a parent management group is designed so inheritance can flow down the hierarchy. When a state cloud team assigns policy at a parent that contains several city subscriptions, leaders should expect child subscriptions—and the resources under them—to be in scope of that policy evaluation, subject to how the assignment is configured. That downward inheritance is the reason management groups exist as a governance tier for multi-city estates.

Expecting policy to stay only on the management group object and never affect child subscriptions denies the inheritance model. Expecting policy to automatically delete every resource group under the management group confuses compliance and remediation effects with blanket destructive deletion of groups. Expecting policy to apply only to on-premises Active Directory and never to Azure resources misidentifies Azure Policy’s target: Azure resource properties and configurations, not classic AD as such.

Exam caveat: inheritance is the default story, but exemptions, resource selectors, and assignment scope filters can narrow what is evaluated—leaders should read compliance results, not assume universal identical enforcement. Operational check: after assigning a pilot initiative at the parent management group, open Policy compliance for two different city subscriptions and confirm the assignment appears, then remediate or exempt deliberately rather than inventing per-subscription duplicate assignments without need.