Azure RBAC design: governing access through the tenant management hierarchy

Azure RBAC works best when the tenant management hierarchy is designed as a governance model, not as a copy of the organisation chart. Management groups sit above subscriptions and provide inherited governance scopes. Use them to apply common policies and compliance controls to related subscriptions, while keeping the hierarchy shallow enough to remain understandable. Begin with a clear separation of responsibilities. A practical model places platform subscriptions and workload subscriptions beneath distinct management groups, then separates online and corporate workloads where their security, connectivity, or compliance needs differ. Use subscriptions for isolation between production, non-production, and different business or billing boundaries. Use resource groups for resources that share a lifecycle. Apply Azure Policy and initiatives at the highest appropriate management-group scope. Keep root-management-group assignments limited because every inherited policy increases the cost of troubleshooting. Avoid granting workload teams broad RBAC at management-group scope. Instead, grant application teams the smallest built-in role at the subscription, resource-group, or resource scope required for their work. Platform teams may need carefully governed management-group access to operate shared services. Assign roles to Microsoft Entra groups rather than directly to users. Use separate groups for readers, operators, contributors, and privileged administrators, with clear owners and regular access reviews. Limit Subscription Owner assignments, avoid standing high-privilege access where possible, and use Microsoft Entra Privileged Identity Management for time-bound, approved activation of sensitive roles. Treat custom roles as code. Prefer built-in roles where they fit; when a custom role is necessary, specify only the required Actions and DataActions, avoid wildcards, use the immutable role ID in automation, and test the assignment at a narrow scope first. Record every exception with a purpose, owner, expiry date, and review point. Finally, protect the hierarchy itself. Restrict who can create or move management groups, set a dedicated default management group for new subscriptions, and audit hierarchy changes through Activity Log. A strong Azure RBAC model makes access predictable: policy defines the guardrails, the hierarchy provides scope, groups express responsibility, and just-in-time privilege reduces exposure.