Azure governance: management groups, subscriptions, RBAC and Azure Policy
Explain Azure management groups, subscriptions and resource groups through inherited RBAC and policy assignments. Work through a denied deployment, existing noncompliance and a bounded policy exception.
TL;DR: Azure RBAC authorizes a principal's operations; Azure Policy evaluates whether resources comply with assigned rules. Management-group inheritance distributes both controls across subscriptions, but neither a role assignment nor a compliance report proves that existing resources have been repaired.
Give each scope an operational purpose
Management groups organize subscriptions within a Microsoft Entra tenant. Subscriptions contain resource groups, and resource groups contain resources. Use this hierarchy to express durable ownership and control requirements. A production subscription and a sandbox subscription may inherit different restrictions while sharing selected organization-wide controls.
Azure RBAC assignments at a management group can flow down through descendant subscriptions. Assigning a narrower role at a resource group does not subtract a broader inherited grant. Microsoft documents RBAC scope and management-group inheritance. Entra directory roles and Azure resource roles govern different objects; directory administration does not mean every deployment uses an authorized resource identity.
The remediation identity is a separate actor. The delivery pipeline's successful login does not supply that identity's permissions.
Read the policy effect before promising a repair
A policy definition describes a condition and effect. An assignment applies it at a scope with parameters and exclusions; an initiative groups definitions. An audit result records noncompliance without blocking a request. A relevant deny rule can block a new or updated resource configuration. Existing resources do not disappear when the rule is assigned.
Effects such as modify and deployIfNotExists can support remediation, subject to their specific behavior. Existing noncompliant resources need a remediation task to perform the supported correction. The assignment's managed identity needs the required resource permissions. Azure Policy's overview and remediation guide explain the evaluation and execution paths.
| Observation | What it establishes | Next evidence |
|---|---|---|
| Pipeline can authenticate | The identity obtained credentials | Its role assignments at the target scope |
| Deployment denied by policy | An applicable rule rejected configuration | Assignment, definition, parameters and effect |
| Resource reported noncompliant | Evaluation found a mismatch | Repair eligibility and remediation status |
| Remediation deployment failed | A correction did not complete | Assignment identity permissions and operation error |
Work through a region restriction
Suppose a fictional production management group permits application VMs only in two approved regions. A new subscription is moved beneath it. The delivery identity still has Contributor on its resource group, but a VM deployment targeting a third region now fails with policy evidence.
Granting Owner to the pipeline would increase its authority without resolving the region restriction. Inspect the inherited assignment and deploy into an approved region if the workload has no contrary requirement. Before moving another subscription, inventory its regional dependencies, recovery copies and automation parameters. A subscription move changes inherited controls, not just the diagram on an architecture slide.
An existing VM in the third region may be reported noncompliant. That finding does not migrate the VM, and changing a location field is not a general relocation procedure. Plan a supported workload move, including data and downtime, or request a scoped exception with an owner and review date.
Keep exceptions and remediation attributable
A justified exception should identify the policy assignment, affected resources, business reason and intended end condition. Azure supports policy exemptions, including expiry. Expiry restores normal evaluation; it does not itself move a resource or finish deferred engineering work. Track the repair separately.
For an assignment created through code, verify the managed identity's actual role assignments. Listing role IDs inside a definition is not evidence that an automation workflow granted them. A task can be authorized to create a policy assignment yet fail to authorize the subsequent repair. Inspect the remediation deployment's errors using that distinction.
In an interview, explain which decision belongs to the platform owner and which belongs to the application owner. “Disable the policy” skips both the reason for the control and the consequences for other subscriptions.
Self-check: an audit-only policy identifies missing tags on fifty existing resources. Will rerunning the compliance scan add the tags? No. It evaluates them again. Select a supported modifying policy and authorized remediation path if automatic repair is intended, then verify the resource values as well as the compliance state.