Governance with Policy, RBAC and management groups
Governance answers two different questions: who is allowed to act, and what is allowed to exist. Mixing them up is the most common mistake in this area.
Policy or RBAC
Azure RBAC controls who can perform actions. Azure Policy controls what resource configurations are allowed, whoever creates them. An Owner can still be blocked by a Deny policy.
| Need | Use |
|---|---|
| Give a team access to a resource group | RBAC role assignment |
| Block resources outside West Europe | Azure Policy (Deny) |
| Add a required tag automatically | Policy with Modify |
| Install an agent on every new VM | Policy with DeployIfNotExists |
| Report non-compliant resources only | Policy with Audit |
| Stop accidental deletion | Resource lock (CanNotDelete or ReadOnly) |
Group several policies into an initiative (policy set) and assign it once. Policy definitions can be assigned at management group, subscription or resource group level, and are inherited downward. Use exemptions for approved exceptions instead of weakening the assignment.
Scopes and management groups
The hierarchy is: tenant root management group, management groups (up to six levels of depth), subscriptions, resource groups, resources. Put policy and RBAC at the highest level that fits, so new subscriptions are covered automatically. Design the hierarchy by governance needs (for example Platform, Landing Zones, Sandbox), not by the org chart.
Least privilege
- Prefer built-in roles. Create a custom role only when no built-in role fits.
- Assign roles to groups, not to individuals.
- Use Privileged Identity Management for just-in-time elevation and access reviews to remove stale access.
- To limit access by resource tag, use role assignment conditions (Azure ABAC), supported for Blob storage data actions among others.
Standardizing deployments
Use Bicep or ARM templates kept in source control, published as template specs when teams need a versioned, shareable template. Azure Blueprints is deprecated, so new designs use template specs, deployment stacks and policy instead.
Cost governance
Use tags to attribute spend per project, budgets in Microsoft Cost Management to alert or trigger action groups, and Azure Policy to require the tags. Tags do not inherit by default, so a Modify policy can copy them from the resource group.
Exam traps
- Policy does not grant permission, and RBAC does not enforce configuration.
- Contributor cannot assign roles. Owner and User Access Administrator can.
- A ReadOnly lock can break operations that look like reads but use POST, such as listing storage account keys.
- Locks apply even to Owners, so remove the lock before deleting or changing a locked resource.
- Entra administrative units and tenants are not valid Policy scopes.
Practice questions
Choose an answer, then review the explanation to check your understanding.
1. A company has 40 subscriptions and wants every new storage account to be denied unless it uses a private endpoint. Where should the policy be assigned to cover all subscriptions with the least effort?
Show answer
Answer: B.Policy assigned to a management group is inherited by every subscription below it. Administrative units are not a valid scope for Azure Policy.
2. Resources that are missing a CostCenter tag must get the tag added automatically from the resource group. Which policy effect fits?
Show answer
Answer: C.Modify adds or changes tags during create or update. Audit only reports, and Deny blocks the request.
3. An engineer must be able to change a virtual machine but must not be able to grant access to others. Which built-in role?
Show answer
Answer: B.Contributor manages resources but cannot assign roles. Owner can also assign roles.
4. Admins should hold the Owner role only for a few hours when they need it, with approval and an audit trail. What should you use?
Show answer
Answer: B.PIM gives just-in-time, time-bound, approved role activation. It needs Microsoft Entra ID P2 (or ID Governance).