Courses Azure Administrator AssociateIdentity & governance

Azure RBAC

Assignments, scope, least privilege, two planes.

Beginner30 min · lesson 2 of 15

Once identities exist, Azure role-based access control (RBAC) governs what they can do to Azure resources. Understanding assignments, scope, and least privilege is central to the administrator role.

Assignments and scope

An Azure RBAC role assignment binds a security principal (user, group, service principal, or managed identity) to a role definition (a set of permissions) at a scope. Scope follows the resource hierarchy — management group, subscription, resource group, resource — and assignments inherit downward, so a Contributor role at a resource group applies to every resource in it. Built-in roles cover most needs: Reader (view), Contributor (manage resources but not access), Owner (full control including access), and User Access Administrator (manage access only). Crucially, Owner and User Access Administrator can grant access to others, making them privileged roles to audit. Where built-ins do not fit, define a custom role with exactly the actions needed.

least-privilege RBAC at the right scope

# Grant a specific built-in role at the NARROWEST scope that works.
az role assignment create --assignee <group-id> \
  --role "Virtual Machine Contributor" \
  --scope /subscriptions/<sub>/resourceGroups/app-rg   # RG, not the whole sub
 
# Audit who can grant access (the escalation-capable roles):
az role assignment list --all \
  --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='User Access Administrator']"

Least privilege and two planes

The guiding principle is least privilege: grant the specific role at the narrowest scope that meets the need, prefer namespaced built-in roles over broad ones, and assign to groups so access is managed centrally. Remember that Azure RBAC (resources) and Entra ID roles (the directory/tenant) are two separate planes — a Global Administrator manages identities and policies, while an Owner manages resources; you often need both, assigned deliberately and separately. Deny assignments (from Azure Blueprints or managed apps) can block actions even for principals who otherwise have a granting role. Getting RBAC right — scoped, group-based, least-privilege, across the correct plane — is what keeps an Azure environment both usable and secure as it grows.

RBAC decision

1principal

user / group / managed identity

2role definition

built-in or custom permissions

3scope

MG → sub → RG → resource (inherits down)

4least privilege

narrowest role + scope, via groups

Assign a specific role at the tightest scope to a group. Watch Owner/User Access Administrator — they can grant access to others.

Owner at the subscription is rarely the right grant

Assigning Owner at a subscription gives full control, including handing out access, over everything in it — far more than most tasks need. Grant a specific built-in role (Contributor, or a resource-specific role) at a resource group or resource scope instead, and reserve Owner and User Access Administrator for a very small, audited set of principals.

Microsoft Entra IDGovernance: Policy, locks & tags