Cascade Regional Airlines' management group hierarchy has a single root management group, Cascade-Root, containing all current subscriptions for HQ, Outstations, and Kiosk-Ops. The subscription owner wants one "require approved regions" Azure Policy enforced across every current subscription and any subscription added in the future, using a single assignment. Where should the policy be assigned?
Select an answer to reveal the explanation.
Short Explanation
Assigning a policy at the very top of the management group tree is like posting one company-wide rule at headquarters instead of taping a copy to every office door. Any new office that opens under that same headquarters automatically inherits the rule too.
Full Explanation
Policy assignments made at a management group scope are inherited by every subscription, resource group, and resource nested beneath it, and that inheritance is dynamic: a new subscription moved into or created under Cascade-Root immediately picks up the assignment with no additional action. This covers both requirements, today's subscriptions and future ones, with exactly one assignment to maintain. Assigning the policy individually to each current subscription would cover today's environment but silently miss anything added later, requiring someone to remember to repeat the assignment, which is fragile governance. Assigning it at every resource group is even more repetitive and carries the same blind spot. A resource lock is an entirely different control, it prevents delete or modify operations and has no mechanism for evaluating or restricting deployment regions, so it cannot substitute for a regions policy. One caveat: assigning broadly at the root means any legitimate exclusion, say a sandbox subscription needing a different region, must be carved out with a policy exemption. Verify the rollout in the Compliance blade at the Cascade-Root scope, confirming every subscription appears under the assignment.