Azure RBAC for AZ-104: Roles, Scopes and Effective Access

Introduction

This lesson covers the second objective of the AZ-104 skills area Manage Azure identities and governance (20–25% of the exam): manage access to Azure resources. The study guide lists three tasks: manage built-in Azure roles, assign roles at different scopes, and interpret access assignments.

The lesson on Microsoft Entra users, groups and SSPR introduces the identities that can receive Azure roles. Creating an identity alone does not grant Azure resource permissions; check its existing direct and group assignments. Azure role-based access control (Azure RBAC) is the authorization system built on Azure Resource Manager that decides who can do what, and where. After this lesson you will be able to read any role assignment, choose the smallest role and scope that satisfy a requirement, and diagnose why a user can or cannot perform an action.

Learning objectives

• Describe the three parts of a role assignment: security principal, role definition and scope.
• Choose among the fundamental built-in roles and common service-specific roles.
• Assign roles at management group, subscription, resource group and resource scope, and explain inheritance.
• Distinguish control-plane (Actions) from data-plane (DataActions) permissions.
• Interpret effective access using Access control (IAM), Check access and role assignment lists.
• Explain how Azure RBAC differs from Microsoft Entra roles, Azure Policy and resource locks.

The model: who, what, where

Every role assignment answers three questions:

Azure RBAC is additive: a principal's effective permissions are the union of all role assignments that apply, at all scopes above and at the resource itself. Evaluate conditions on each grant and any applicable deny assignments before concluding that an operation is allowed. In generally available scenarios, the platform manages deny assignments, for example through deployment-stack deny settings; customer-managed deny assignments are currently private preview. Authorization applies across portal, CLI, PowerShell, REST and templates, while resource providers enforce supported data-plane RBAC operations.

Azure RBAC is distinct from Microsoft Entra roles. Entra roles (User Administrator, Global Administrator) manage the directory: users, groups, domains. Azure roles manage Azure resources: virtual machines, storage accounts, networks. One exception links them: a Global Administrator can elevate access to become User Access Administrator at the root scope, for recovery or authorized access management. Remove the root-scope elevation when finished; it is not an automatic Owner assignment.

Role definitions

A role definition lists permitted operations. This illustrative custom role uses the PowerShell-style JSON representation; replace the subscription ID and resource group before creating it. It is not the full built-in Virtual Machine Contributor definition:

{
  "Name": "VM Power Operator",
  "IsCustom": true,
  "Description": "Example: read and operate VM power state without create or delete permissions.",
  "Actions": [
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/deallocate/action",
    "Microsoft.Resources/subscriptions/resourceGroups/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod-app"
  ]
}

• Actions and NotActions apply to the control plane: management operations sent to Azure Resource Manager, such as creating a storage account.
• DataActions and NotDataActions apply to the data plane: operations on the data inside a resource, such as reading a blob or a Key Vault secret.
• NotActions is not a deny. It subtracts from the wildcard in Actions within that one role, but another assignment can still grant the removed action.
• AssignableScopes lists where the role may be assigned.

Core resource and access-administration roles

Contributor deliberately excludes Microsoft.Authorization/*/write, so a contributor cannot grant access to anyone, including themselves. That separation is a favourite exam theme.

Service-specific roles

Many built-in roles are narrower than Contributor. The exam commonly uses:

Exam tip: If a question describes a user who "can manage a storage account but cannot read the blobs through Microsoft Entra authentication", the answer is that Storage Account Contributor is control plane only; the user needs a Storage Blob Data role.

Custom roles

When no built-in role matches, create a custom role by cloning a built-in one or defining actions from scratch, then list AssignableScopes. Creating or updating custom roles requires Microsoft.Authorization/roleDefinitions/write on all listed AssignableScopes, for example through Owner or User Access Administrator. Role Based Access Control Administrator manages assignments but does not by itself grant role-definition writes. Prefer a built-in role whenever one fits, because Microsoft maintains it as services evolve.

Scopes and inheritance

Scopes form a hierarchy; permissions inherit downward:

Management group  →  Subscription  →  Resource group  →  Resource

An assignment at a parent applies to every child. You cannot block inheritance at a lower level with RBAC itself; instead, assign narrower scopes to start with. A resource ID shows the scope, for example:

/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-web/providers/Microsoft.Storage/storageAccounts/stweb001

Azure supports up to 5,000 role assignments per subscription (a fixed limit including subscription, resource group and resource scopes, but not management groups). Eligible assignments and assignments scheduled in the future do not count toward that limit. Assigning roles to groups instead of individuals, and removing redundant lower-scope assignments, keeps you far below the limit.

Assigning a role

In the portal: open the target scope, select Access control (IAM) > Add > Add role assignment, choose the role, choose members, optionally add a condition, and review. The examples below grant the broader built-in VM-management role, not the power-only custom role above. Run them in the intended tenant/subscription, with permission to read the group (or supply its known object ID) and to create the assignment:

# Confirm the signed-in tenant and selected subscription before assigning access.
subscriptionId="$(az account show --query id -o tsv)"
groupId="$(az ad group show --group "App-Operators" --query id -o tsv)"
az role assignment create \
  --assignee-object-id "$groupId" \
  --assignee-principal-type Group \
  --role "Virtual Machine Contributor" \
  --scope "/subscriptions/$subscriptionId/resourceGroups/rg-app"

# Replace this value with the group object ID from Microsoft Entra ID.
$groupObjectId = "REPLACE_WITH_GROUP_OBJECT_ID"
New-AzRoleAssignment -ObjectId $groupObjectId `
  -RoleDefinitionName "Virtual Machine Contributor" `
  -ResourceGroupName "rg-app"

Role assignments can take a few minutes to propagate. A new assignment can appear ineffective until the user's token refreshes, so signing out and in is a valid first troubleshooting step.

To grant access you must hold Microsoft.Authorization/roleAssignments/write at that scope, available through Owner, User Access Administrator or Role Based Access Control Administrator, subject to scope and delegation conditions. Contributor alone does not grant it.

Conditions (ABAC)

A role assignment can include a condition, an additional check on attributes, such as "only allow reading blobs whose index tag Project equals Atlas". Conditions narrow an assignment; they cannot add permissions. They are supported for selected actions and roles, including blob-data access and constrained delegation of role assignments. A condition restricts only its own assignment: another unconditional grant may still allow access. Protect tag-writing permissions if tags govern reads.

Worked example: delegating without over-granting

Scenario. Litware's helpdesk team of 12 engineers must start, stop and restart virtual machines in the resource group rg-prod-app only. They must not delete VMs, change networks or create storage accounts. Management wants the least administration effort.

Reasoning, step by step.

1. Who? Twelve people means a group, Helpdesk-VM-Operators, not twelve assignments.
2. What? Contributor is too broad. Virtual Machine Contributor allows creating and deleting VMs. Use the explicit power-operation custom role shown above, retaining only the fully qualified read and power actions required here. Verify that no other group grant restores create/delete permissions.
3. Where? The requirement names one resource group, so assign at the resource group scope, not the subscription.
4. Assign the custom role to the group at rg-prod-app.

Solution. Custom role assigned to the group at resource group scope.

Why the alternatives are worse. Contributor at subscription scope violates least privilege and exposes every resource. Virtual Machine Contributor at the resource group scope still allows deletion, which the scenario forbids. Individual assignments multiply the effort and the audit surface.

Worked example: control plane versus data plane

Scenario. A developer, Priya, holds Contributor on the resource group that contains the storage account stdata01. She can create containers in the portal's control views, yet when she opens a container with Microsoft Entra user account authentication selected, she gets "You do not have permission to list the data using your user account".

Reasoning. Contributor has Actions: * but no DataActions. Accessing blob data via Entra ID needs a data-plane role. Contributor does allow listing the account keys (Microsoft.Storage/storageAccounts/listKeys/action), so with key authentication she could still reach data, which is itself a security concern.

Solution. For listing and reading only, assign Storage Blob Data Reader at the required container scope. Use Storage Blob Data Contributor only if writes/deletes are also required. The existing resource-group Contributor grant supplies portal navigation permissions; see identity-based storage access and Shared Key controls.

Why other fixes fail. Raising her to Owner still does not directly grant Entra-authorized blob DataActions, although Owner can assign additional roles. Switching to key-based access works but bypasses identity-based auditing and should be disabled where possible.

Interpreting access assignments

The exam often shows a screenshot or text of role assignments and asks what a user can do. Use this method:

1. Identify every assignment that targets the user, directly or through any group they belong to (including nested groups).
2. Note each assignment's scope and check whether the target resource sits below it.
3. Take the union of all applicable roles' permissions.
4. Check for separate blockers: deny assignments, Azure Policy, resource locks, network firewalls, and conditions.

Tools you can use:

• Access control (IAM) > Check access shows a principal's effective roles at that scope.
• Role assignments tab lists assignments at that scope and inherited ones (with a Scope column showing "This resource" or "Subscription (inherited)").
• Roles tab shows definitions, and Deny assignments shows deny entries.
• For a targeted CLI audit, use az role assignment list --assignee USER_OBJECT_ID --scope RESOURCE_SCOPE --include-groups --include-inherited after replacing the placeholders. Group expansion may require directory-read permissions. Use Get-AzRoleAssignment with appropriate identity and scope filters for PowerShell audits.
• The Activity log records role assignment writes, which helps answer "who gave this access?".

Worked example: reading assignments

Scenario. Ana belongs to groups Dev-Team and Auditors. Assignments:

Can Ana (a) delete a storage account in rg-dev? (b) delete a storage account in rg-prod? (c) restart a VM in rg-prod? (d) view a resource in rg-test?

Reasoning. (a) Yes, Contributor on rg-dev via Dev-Team includes delete. (b) No: in rg-prod she has Reader (inherited from the subscription) plus Virtual Machine Contributor, neither of which permits storage deletion. (c) Yes, through Virtual Machine Contributor. (d) Yes, Reader inherits at the subscription.

Solution. a yes, b no, c yes, d yes.

Why people get it wrong. They treat assignments as exclusive instead of additive, or forget group-inherited roles.

Azure RBAC versus other controls

Management locks apply to control-plane requests: even Owner cannot delete a locked resource until an authorized principal removes the lock. Locks do not protect blob contents from authorized data-plane deletion. Azure Policy can also block disallowed resource operations by Owners. For the broader controls, review subscriptions, governance and resource locks.

Pitfalls and exam tips

Exam tip: "Least privilege" plus a named resource group usually means a narrow role at resource group scope, assigned to a group.

Exam tip: For role-assignment delegation, Role Based Access Control Administrator is narrower than User Access Administrator. Both can be powerful: constrain roles/principals where appropriate and review other assignments.

Exam tip: Owner and Contributor have no data-plane permissions for Entra-based blob access. Use Storage Blob Data roles.

Pitfall: Expecting NotActions to deny. If a second assignment grants the action, it is allowed.

Pitfall: Assigning Owner at subscription scope "to be safe". Microsoft recommends a small number of subscription owners.

Pitfall: Forgetting propagation delay and token caching after a new assignment.

Pitfall: Confusing Global Administrator with Azure Owner. The Global Administrator directory role does not itself grant Azure resource access. A person may already hold separate Azure assignments; elevation is one recovery path, not the only way to receive access.

Mini case study: Adventure Works platform team

Adventure Works has a management group mg-corp with three subscriptions (dev, test, prod). Requirements:

1. The cloud platform team of 5 must manage all resources everywhere but must not be granted Azure RBAC role-assignment writes.
2. Developers (Entra group Developers) must fully manage resources in the dev subscription only.
3. The security auditor must read everything but never change it.
4. A deployment pipeline's managed identity must deploy to rg-web in prod only.

Solution, with commentary.

• Requirement 1: assign Contributor to the platform group at mg-corp. Contributor excludes Azure RBAC role-assignment writes. It can still expose account keys, deploy code or control workloads, so this does not mean it is unable to affect data access by every possible route.
• Requirement 2: assign Contributor to Developers at the dev subscription scope. Not at the management group, which would also include prod.
• Requirement 3: Reader to the auditor (preferably through a group) at mg-corp.
• Requirement 4: assign the pipeline's managed identity a role such as Contributor (or a narrower deployment role) at rg-web only. The scope is the control, since the role itself is broad.

Check: A platform engineer asks for the ability to assign roles. The correct answer is a separate, tightly controlled assignment of Role Based Access Control Administrator with suitable delegation conditions, ideally eligible/time-bound through Privileged Identity Management, not widening Contributor.

Key terms

• Security principal: user, group, service principal or managed identity receiving access.
• Role definition: list of allowed actions and data actions.
• Scope: the level at which a role applies; inherited downward.
• Control plane / data plane: management operations versus operations on data.
• NotActions: exclusions from a role's wildcard; not a deny.
• Condition (ABAC): attribute-based refinement of an assignment.
• Elevate access: Global Administrator temporarily gaining User Access Administrator at root.

Summary checklist

• I can state who, what and where for any assignment.
• I can distinguish Owner, Contributor, Reader and User Access Administrator.
• I distinguish direct DataActions from indirect access through keys, extensions or role-assignment privileges.
• I can pick the narrowest scope that meets the requirement and assign to groups.
• I can compute effective access as the union of inherited and group assignments.
• I can separate RBAC from Policy, locks and Entra roles.

Official sources

• Current built-in role permissions: https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles (opens in a new tab)

• Privileged built-in role definitions: https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/privileged (opens in a new tab)

• Delegate role assignments with conditions: https://learn.microsoft.com/en-us/azure/role-based-access-control/delegate-role-assignments-overview (opens in a new tab)

• Custom roles and AssignableScopes: https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles (opens in a new tab)

• Platform-managed deny assignments: https://learn.microsoft.com/en-us/azure/role-based-access-control/deny-assignments (opens in a new tab)

• CLI assignment commands and group expansion: https://learn.microsoft.com/en-us/cli/azure/role/assignment?view=azure-cli-latest (opens in a new tab)

• Azure PowerShell assignments: https://learn.microsoft.com/en-us/powershell/module/az.resources/new-azroleassignment (opens in a new tab)

• Management-lock scope: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources (opens in a new tab)

• AZ-104 study guide: https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/az-104 (opens in a new tab)

• Understand Azure role definitions: https://learn.microsoft.com/en-us/azure/role-based-access-control/role-definitions (opens in a new tab)

• Steps to assign an Azure role: https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-steps (opens in a new tab)

• Best practices for Azure RBAC: https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices (opens in a new tab)

• Azure RBAC limits: https://learn.microsoft.com/en-us/azure/role-based-access-control/troubleshoot-limits (opens in a new tab)