Microsoft AZ-104: Azure RBAC Design for Platform Teams

Azure role-based access control works best when platform teams treat access as an architecture model instead of a collection of portal assignments. Every role assignment combines a principal, a role definition, and a scope. The security outcome therefore depends on choosing the smallest practical scope, the narrowest practical role, the right principal type, and an operating process that can review and remove access later.

Microsoft’s current Azure RBAC best practices emphasize least privilege, limiting subscription Owners, minimizing privileged administrator assignments, using Microsoft Entra Privileged Identity Management, assigning roles to groups instead of individual users, using role IDs in automation, and avoiding broad wildcards in custom roles. Current Azure ABAC capabilities can add role-assignment conditions for supported actions and can constrain delegated role-assignment administration.

RBAC design is therefore a platform-engineering concern inside Azure Architecture in Practice.

Design scope before role

Azure RBAC scopes can exist at management group, subscription, resource group, or individual resource level.

RBAC scope should be chosen before the role because a modest role assigned too broadly can expose more resources than a powerful role assigned narrowly.

Platform teams should map administrative boundaries to subscription and resource-group design so access assignments follow clear operational ownership.

Use groups for human access

Assign human users through Microsoft Entra groups where possible instead of creating many direct assignments.

This makes onboarding, offboarding, access reviews, and organizational changes easier to manage.

Group ownership should be governed because an RBAC group is effectively an access-control object; unmanaged membership can undermine a carefully designed Azure scope.

Use PIM for privileged roles

Standing privileged access increases the time window in which compromised credentials can be abused.

Microsoft Entra Privileged Identity Management can make eligible Azure resource roles time-bound and can add activation, approval, MFA, justification, notification, and audit features according to policy.

Use PIM especially for Owner, User Access Administrator, and other roles whose permissions can change access or platform-wide configuration.

Separate platform and workload roles

A central platform team may manage networking, policy, management groups, identity patterns, and shared monitoring while application teams manage resources inside assigned scopes.

Landing-zone governance is easier when shared platform scopes and workload scopes are distinct enough that each team can receive the permissions required for its responsibility without inheriting unrelated control.

Subscription structure should support this separation instead of forcing role assignments to compensate for a poor resource hierarchy.

Prefer built-in roles before custom roles

Built-in roles are easier to understand, support, and audit when they match the job function.

Create custom roles only when the combination of actions genuinely cannot be expressed safely with existing roles and scope.

When custom roles are required, explicitly list actions and data actions instead of broad wildcards that might silently include future permissions.

Use conditions for finer-grained delegation

Azure ABAC role-assignment conditions can reduce permissions granted through selected role assignments by evaluating supported attributes.

Microsoft also supports constrained delegation for role-assignment management, letting a delegate create only approved kinds of assignments instead of receiving unrestricted Owner or User Access Administrator authority.

Conditions are an extra filter on a grant, not a general deny system, so teams should design them with the underlying RBAC role and scope in mind.

Keep workload identities separate

Managed identities and service principals should receive the minimum resource permissions their workload requires.

Workload identities need governance because an over-privileged deployment pipeline or managed identity can bypass the human-access controls around administrators.

Runtime identities, deployment identities, and emergency administrative identities should remain separate unless one principal truly needs all of those responsibilities.

Document why assignments exist

Descriptions, group naming, role-assignment metadata, access reviews, and infrastructure-as-code can make access intent visible.

An auditor or responder should be able to answer who has access, what they can do, at what scope, why the assignment exists, and who owns its removal.

Assignments created for temporary projects should have expiry or a review trigger rather than becoming permanent by default.

Test access from the user’s perspective

Verify both allowed and denied behavior after changing RBAC.

Confirm that a platform operator can complete expected work and that a workload operator cannot change policy, networking, or access outside the assigned scope.

For AZ-104 administration, mature RBAC design is scope → role → principal → condition/PIM where appropriate → review → negative testing. Least privilege is strongest when the organization can prove both what a principal can do and what it cannot do.

Role-assignment limits also matter at enterprise scale. Thousands of per-resource user assignments create operational overhead and can approach platform limits. Use groups, meaningful resource scopes, and supported conditions to reduce assignment count without broadening authority unnecessarily.

Automation should use immutable role IDs rather than display names so scripts survive role-name changes. IaC should also avoid creating duplicate role assignments with unpredictable GUIDs on each deployment.

Break-glass access should be designed separately from routine PIM workflows. Emergency accounts need strong protection, monitoring, periodic testing, and very limited use; they should not become the convenient way around a broken access model.

Finally, platform teams should monitor privileged assignments and access changes as security signals. A new Owner assignment can be as consequential as a firewall change and should enter the same operational and incident-review processes as other high-impact control-plane events.

Role inheritance should be reviewed before adding a new assignment. A principal with Reader at a management group and Contributor at one resource group has a different effective permission set than the assignment list on the resource alone suggests. Access reviews should consider inherited assignments so administrators do not grant duplicate or unnecessarily broad roles simply because the current scope view looks empty.

Role-assignment conditions can also help storage and delegated administration scenarios where simple RBAC would require many granular assignments. Use conditions only where the supported resource and action model is understood, and test them with both allowed and denied examples. A complicated condition that nobody can explain becomes difficult to audit and can fail unexpectedly during application change.

Custom roles should have clear ownership and version history. New Azure resource-provider actions can appear over time, which is one reason Microsoft recommends avoiding wildcards. Periodically compare custom roles with current built-in roles; a custom role created years ago may become unnecessary after Microsoft adds a supported built-in job-function role.

Subscription Owner assignments should be rare because Owners can change both resources and access. Microsoft recommends limiting the number of subscription Owners, and platform teams should usually separate resource administration from access administration rather than assigning Owner broadly for convenience.

Service principals created by automation deserve the same review as humans. CI/CD systems can accumulate permissions across subscriptions as new deployments are added. Use separate identities by environment or platform function when that reduces blast radius, and remove obsolete role assignments when pipelines or applications are retired.

Access governance should include management-plane logging. Azure Activity Log records role-assignment creation and deletion, and privileged access changes can be surfaced into security monitoring. Alerting on unexpected access-control changes is useful because an attacker with role-assignment authority can grant durable persistence without changing a single workload resource.

Platform teams should also define how application teams request additional access. A self-service workflow can capture principal, role, scope, business reason, duration, and owner. This reduces ad hoc Owner grants and creates evidence for later access review.

RBAC design should be reviewed after reorganizations, subscription moves, landing-zone changes, and acquisitions. Resource hierarchy and team boundaries can change while inherited assignments continue to grant access. A periodic review of privileged and broad-scope roles prevents historical access from outliving its business purpose.

For large environments, publish an access matrix that maps platform personas—network operator, security operator, app operator, database operator, FinOps analyst, support engineer—to approved roles and scopes. This makes least privilege repeatable instead of reinvented for every subscription.

Custom roles should also be reviewed for DataActions, not only management-plane actions. A role that cannot modify a storage account may still read or write blobs if it includes data-plane permissions. Platform teams should inspect both planes when assessing blast radius and should separate resource administration from data access where practical.

Role assignment at management-group scope can be useful for central platform functions but carries a large inheritance footprint. Assign broad-scope roles only to teams whose responsibility truly spans the hierarchy. A network team managing one connectivity subscription usually does not need equivalent rights across every application subscription beneath the root.

Access reviews should focus on privileged and dormant assignments first. A role that has not been used for months, belongs to a departed project, or is attached directly to a person rather than a governed group deserves immediate scrutiny. Review effort should follow potential consequence rather than treating every Reader assignment like an Owner assignment.

In platform automation, separate the identity that deploys role assignments from the identity that consumes the resulting resource access. This prevents a runtime service from granting itself additional roles if it becomes compromised and makes role-management events easier to attribute.

Delegated access management should preserve separation of duties. A team can be allowed to assign a narrow set of job-function roles to approved principal types inside one resource group without gaining the ability to grant Owner or User Access Administrator. Current Azure ABAC delegation patterns are valuable precisely because they let platform teams automate common access tasks without giving away unrestricted access-control authority.