A statewide Azure governance team assigns an Azure Policy at a management group that contains every city subscription. What inheritance behavior should municipal IT expect?
Select an answer to reveal the explanation.
Short Explanation
Put the rule high on the management-group tree and the subscriptions hanging under it feel it. That hierarchy is how states push one standard to many cities without pasting the same assignment fifty times.
Full Explanation
Azure management groups form a hierarchy above subscriptions. When a statewide governance team assigns Azure Policy at a management group that contains every city subscription, that assignment can apply to child subscriptions in the hierarchy (subject to how the assignment is configured). Municipal IT should therefore expect inherited policy evaluation rather than assuming each city must reinvent the same baseline.
It is incorrect that management group policies never affect subscriptions underneath them. Resource group locks are a different control and do not define Policy inheritance; Policy assignments intentionally participate in the management-group hierarchy. Child subscriptions do not need to re-upload policy JSON nightly for inheritance to work—assignments persist until changed.
Exam caveat: exemptions, different assignment scopes, and conflicting policies can create exceptions, so “inherits” does not mean every resource is forever identical without review. Operational check: at the management group, note an assigned built-in or custom policy, open a child city subscription’s Policy Compliance blade, and confirm the same initiative or definition appears as coming from the parent scope rather than only from a local subscription assignment.