AZ-104
Deep Dive
Azure's authorization system. The AZ-104 tests role assignment, scope, inheritance, custom roles, and the principle of least privilege.
Contents
RBAC (Role-Based Access Control) controls who can do what on which resources in Azure. A role assignment = Security Principal + Role Definition + Scope.
Security Principal
Who is the role assigned to?
Role Definition
What can they do?
Scope
On which resources?
Roles are inherited downward. Assigning at a higher scope affects all child resources.
Management Group
/providers/Microsoft.Management/managementGroups/{id}
↳ Affects every subscription in the group and their resources
Subscription
/subscriptions/{subscriptionId}
↳ Affects all RGs and resources in that subscription
Resource Group
/subscriptions/{id}/resourceGroups/{name}
↳ Affects all resources within the RG
Resource
/subscriptions/{id}/resourceGroups/{rg}/providers/{type}/{name}
↳ Only that specific resource
Inheritance: A role assigned at the Subscription level → the user has that role in EVERY RG and resource in that sub. Permissions flow from top to bottom, never the other way.
Azure has 300+ built-in roles. The AZ-104 tests the fundamental ones and when to use each.
| Role | Can | Cannot | Typical case |
|---|---|---|---|
| Owner | Everything, including assigning roles | — | Subscription technical lead |
| Contributor | Create, modify, delete resources | Assign RBAC roles or Azure Policies | Senior developers, DevOps |
| Reader | View all resources and configs | Any write operation | Auditors, management, L1 support |
| User Access Administrator | Manage RBAC role assignments | Create/modify resources | Admin who manages permissions without touching resources |
| Virtual Machine Contributor | Create and manage VMs | Access the VNet/Storage where they live, or assign roles | VM operations team |
| Storage Blob Data Contributor | Read/write/delete data in blobs | Manage the storage account itself (keys, configs) | Apps that read/write blobs |
| Key Vault Administrator | All operations in Key Vault (secrets, keys, certs) | Manage the Key Vault resource itself in ARM | Security team managing secrets |
Control vs Data plane — a critical distinction
Control plane (ARM)
Managing the RESOURCE: create, configure, delete. E.g., creating a blob container, changing the Storage tier. Controlled by actions/notActions.
Data plane
Accessing the DATA within the resource: reading/writing blobs, reading Key Vault secrets. Controlled by dataActions/notDataActions. Requires specific data roles.
For when no built-in role fits your exact needs. Requires Entra ID P1 or higher.
Anatomy of a Custom Role (JSON)
{
"Name": "VM Operator - Read Only + Start/Stop",
"Description": "Can view VMs and start/stop them",
"Actions": [
"Microsoft.Compute/virtualMachines/read",
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/deallocate/action"
],
"NotActions": [],
"DataActions": [],
"AssignableScopes": [
"/subscriptions/{subscriptionId}"
]
}Creating a Custom Role — options
Azure Portal
Entra ID → Roles and administrators → New custom role (Entra roles only) or Subscription → Access control (IAM) → Add custom role → Start from scratch / clone
PowerShell
New-AzRoleDefinition -InputFile "role.json" — accepts the JSON with the full definition.
Azure CLI
az role definition create --role-definition role.json
ARM/Bicep
A resource of type Microsoft.Authorization/roleDefinitions — for IaC.
Limits
Inheritance rules
Deny Assignments
They block specific actions even when there's an Allow in another role. Created by Azure Blueprints and Azure Managed Applications — users cannot create Deny Assignments directly.
Just-in-time (JIT) access to privileged roles. Reduces the attack surface by eliminating standing permissions. Requires Entra ID P2.
Eligible vs Active
Permanent Active
The role is permanently assigned — the user ALWAYS has the access, with no action required.
High — if the account is compromised, the attacker has immediate access
Eligible (PIM)
The user is "eligible" for the role but must explicitly activate it. Activation can require justification, MFA, approval from another admin.
Low — limited access window, auditable, approvable
PIM activation flow
PIM also covers: Entra ID roles (Global Admin, etc.) in addition to Azure RBAC roles. And it enables Access Reviews to clean up stale assignments.
When a user says "I don't have access" or "I have too much access," these are the tools to diagnose it.
Diagnostic tools
Access control (IAM) → Check access
On any resource/RG/Subscription: search for a user/SP and show every role they have at that scope (including inherited ones).
Portal: Resource → IAM → Check access → search by userMy Access portal
The user can see their own access, request access to packages (Entitlement Management), and review their active assignments.
aka.ms/myaccessaz role assignment list
Lists all role assignments for a principal or specific scope.
az role assignment list --assignee user@contoso.com --allGet-AzRoleAssignment
PowerShell equivalent. Useful for audit scripts.
Get-AzRoleAssignment -SignInName user@contoso.comActivity Log
Records role assignment changes: who assigned which role to whom, when. 90-day retention.
Monitor → Activity Log → filter by "Create role assignment"Common problems and causes
User has access they shouldn't
Cause: Inheritance from a higher scope (Subscription or MG). Verify with "Check access" at a higher scope.
Solution: Revoke the assignment at the correct scope
"Unauthorized action" even though the role allows it
Cause: The specific resource might have a Resource Lock, or the action is a dataAction that requires a different role.
Solution: Check locks and whether the operation is control plane or data plane
Role change has no immediate effect
Cause: Access tokens are valid for up to 1 hour. The change applies on the next token.
Solution: Wait up to 1 hour, or have the user sign out and back in
Deny Assignment blocks an otherwise permitted action
Cause: An Azure Blueprint or Managed App created a Deny Assignment that takes priority over all roles.
Solution: Identify the Deny Assignment in IAM → Deny assignments and contact the Blueprint owner
RBAC limits in Azure
Critical for large tenants — use groups instead of individual users
Less common but worth keeping in mind
Usually not a problem
Migrate to modern RBAC — classic accounts have effective Owner access
Scalable RBAC management
Use groups, not individual users
Assign roles to security groups. Manage group membership. 1 role assignment for 100 people uses only 1 of the 2,000 limit.
Principle of least privilege
Always assign the most restrictive role that allows the work to be done. Review periodically with Access Reviews (P2).
Most specific scope possible
Assign at the Resource Group, not the Subscription, if access is only needed for resources in that RG. Reduces the blast radius.
Time-bound assignments
In IAM → Add role assignment → there's an expiration date option. Without PIM, RBAC assignments can natively be time-limited.
The AZ-104 tests this distinction. Many people confuse them because both "control" things in Azure.
RBAC answers: who can do what?
Controls the operations a security principal can perform. "User X can create VMs in this RG."
Azure Policy answers: what state should the resource have?
Controls the properties and configuration of resources. "All VMs must have tags. All Storage must be encrypted."
| Aspect | Azure RBAC | Azure Policy |
|---|---|---|
| Goal | Control who can execute operations (CRUD) | Control the state/configuration of resources |
| Question it answers | Can I create this VM? | Does this VM comply with organizational rules? |
| Denial effect | The operation cannot be executed (not authorized) | The resource cannot be created if it violates the policy (Deny effect) |
| Scope | MG > Subscription > RG > Resource | MG > Subscription > RG (not individual resources) |
| Granularity | Per operation (e.g., read-only for VMs in an RG) | Per resource property (e.g., required tag, allowed region) |
| Retroactive | No — only applies to future operations | Yes — Audit can flag existing non-compliant resources |
| Used for | IAM — who manages infrastructure | Compliance — what configurations are acceptable |
Combined example
RBAC: a Developer has Contributor on RG-Dev
They can create VMs, modify storage, deploy apps in that RG.
Policy: "VMs only in East US, no premium SKU"
Even though the dev CAN create VMs (RBAC), if they try to create one in West Europe or with a premium SKU, the Policy rejects it.
RBAC controls capability. Policy controls the rules. You need both.
Did you get this topic?
Test what you just learned
An external auditor needs to review all resources in an Azure subscription without being able to modify anything. Which RBAC role should be assigned to them?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.