Azure RBAC and governance: management groups, subscriptions and Azure Policy
In short: Azure governance rests on a scope hierarchy of management groups, subscriptions and resource groups. Azure role-based access control (RBAC) decides who can do what at each scope, and Azure Policy decides what resources are allowed, so the two together keep large estates safe and consistent.
The scope hierarchy
Azure organises everything in a tree. Settings flow down, so a decision made high up applies to every resource beneath it. This makes governance scalable but also means a careless assignment at a high scope can grant far more than intended.
- Management groups group subscriptions, for example by environment or business unit.
- Subscriptions are billing and quota boundaries and a common unit of isolation between workloads.
- Resource groups hold resources that share a lifecycle, such as all parts of one application.
How Azure RBAC works
A role assignment has three parts: a security principal (user, group, service principal or managed identity), a role definition (a list of allowed actions) and a scope.
| Built-in role | Can do | Use sparingly? |
|---|---|---|
| Owner | Everything, including assigning roles | Yes, very few people |
| Contributor | Create and manage resources, but not grant access | Yes |
| Reader | View only | No, safe default for viewers |
| User Access Administrator | Manage role assignments | Yes |
| Service-specific roles | E.g. Virtual Machine Contributor, Key Vault Secrets User | Preferred for least privilege |
az role assignment create --assignee-object-id <group-object-id> --assignee-principal-type Group --role "Reader" --scope /subscriptions/<subscription-id>/resourceGroups/rg-webAssign roles to groups rather than individuals, at the narrowest scope that works. Azure RBAC (for Azure resources) is separate from Entra ID roles (such as Global Administrator), though both need care. Use PIM for just-in-time elevation to powerful roles.
Azure Policy
An Azure Policy definition describes a rule and an effect. Common effects are Deny (block non-compliant deployments), Audit (report them), Modify or Append (add missing settings such as tags) and DeployIfNotExists (deploy something, such as a diagnostic setting). Group related definitions into initiatives, such as the Microsoft cloud security benchmark, and assign them at management group level.
Useful starter policies: allowed locations, required tags, no public IP on network interfaces, storage accounts must disable public blob access, and send diagnostic logs to Log Analytics.
Putting governance together
- Design a management group tree that mirrors how you want policy to differ (for example Production, Non-production, Sandbox).
- Assign baseline policy initiatives at the top, stricter ones lower down.
- Grant access to groups with the least powerful role that works.
- Apply resource locks (CanNotDelete) to critical items such as hub networks.
- Review role assignments and policy compliance regularly.
Tip: a common exam trap is mixing up RBAC and Policy. If the question is about a person's permissions, think RBAC; if it is about a resource's settings, think Policy.
Practice
You must stop anyone creating resources outside UK regions. RBAC or Policy?
Why is assigning Owner at a management group risky?
What are the three parts of a role assignment?
Key takeaways
- Scopes run from management groups to subscriptions, resource groups and resources.
- Assignments at a scope are inherited below it.
- RBAC controls who can act; Policy controls what resources may look like.
- Assign specific roles to groups at the narrowest scope.
- Use initiatives, locks and regular reviews for governance.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.