IAM — Azure RBAC & Entra ID Roles

Why This Topic Matters

Azure uses two distinct permission systems that are often confused: Azure RBAC (resource plane) and Entra ID roles (directory plane). Knowing the difference prevents misconfigurations, ensures least-privilege designs, and is essential for AZ-104 exam scenarios.

At a glance

	Azure RBAC	Entra ID Roles
Controls what?	Azure resources (VM, Storage, RG, Sub, MG…)	Entra ID objects (users, groups, apps, policies…)
Managed where?	Access Control (IAM) on resource / RG / Sub / MG	Entra > Roles and administrators
Custom roles	✅ free	✅ (but P1 required)
Custom role creator	Owner / User Access Admin	Global Admin / Privileged Role Admin
Possible scopes	MG → Sub → RG → Resource	Tenant / Administrative Unit / Application

AZ-104 trap: being Global Admin in Entra ID does not automatically grant rights on Azure resources. Enable Access management for Azure resources in Entra to allow role assignment on the tenant root management group.

RBAC concepts (common)

A role assignment = triplet: Security principal (user/group/service principal/managed identity) + Role definition (built-in or custom) + Scope (MG/Sub/RG/Resource). Always apply least privilege and the smallest practical scope.

Azure RBAC

Fundamental built-in roles

Role	Permissions
Owner	Full access + access management (RBAC)
Contributor	Full access except access management
Reader	Read-only
User Access Administrator	Manage access only (RBAC)

There are hundreds of specialized built-ins (e.g., Virtual Machine Contributor, Storage Blob Data Reader).

Scope hierarchy & inheritance

Management Group
   └─ Subscription
        └─ Resource Group
             └─ Resource

Roles assigned at a level are inherited downward. Grant at the narrowest scope possible — Owner on a subscription equals Owner everywhere inside.

Custom Roles — JSON structure

Example skeleton:

{
  "Name": "Koalification Team",
  "Description": "...",
  "Actions": [ "Microsoft.Compute/virtualMachines/*" ],
  "NotActions": [ "Microsoft.Compute/virtualMachines/delete" ],
  "DataActions": [ "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read" ],
  "AssignableScopes": [ "/subscriptions/<sub-id>" ]
}

Key fields:

• Actions / NotActions: management-plane allows and exclusions (not a deny).
• DataActions / NotDataActions: data-plane permissions (blobs, keys).
• AssignableScopes: where the role can be granted.

Note: NotActions excludes permissions from the role but does not deny them if another role grants them.

Deny assignments

• Deny assignments explicitly block actions, taking precedence over allows.
• You cannot create deny assignments yourself; Azure creates them in limited contexts (Managed Apps, Azure Blueprints historically).
• Example: a Marketplace managed app may create deny assignments so you cannot modify certain resources in the managed resource group even if you are Owner at subscription scope.

View: Resource > IAM > Deny assignments (read-only).

Entra ID Roles

Entra roles control directory operations: creating users, resetting passwords, managing applications and roles, reading audit logs.

Common built-in roles

• Global Administrator — full directory control (minimize use).
• User Administrator — manage user lifecycle and passwords.
• Helpdesk Administrator — limited password reset rights.
• Privileged Role Administrator — assign directory roles.
• Application Administrator / Cloud App Administrator — manage app registrations and service principals.
• Authentication Administrator — manage MFA methods.

Particularities

• Scopes differ: Tenant, Administrative Unit (AU) or Application, not resource groups.
• To make a group assignable to Entra roles the group must be created with Microsoft Entra roles can be assigned to the group enabled (P1 requirement and irreversible at creation).
• Custom Entra roles require P1 and cover a subset of directory actions.

Demo — portal flows & commands

Assign an Azure RBAC role (portal)

1. Resource (or RG/Sub/MG) > Access control (IAM) > Add > Add role assignment
2. Choose role → Next
3. Members → User / Group / Service Principal / Managed Identity → Select
4. Review + assign

Check a user’s roles: IAM > Check access > select the identity.

Create an Azure RBAC Custom Role (Cloud Shell)

# 1. Prepare JSON file
cat > koalificationteam.json <<'JSON'
{ /* JSON role definition with AssignableScopes */ }
JSON

# 2. Create role (PowerShell)
New-AzRoleDefinition -InputFile ./koalificationteam.json

# CLI alternative
az role definition create --role-definition ./koalificationteam.json

Assign an Entra ID role (portal)

Method 1 — direct on role:

• Entra > Roles and administrators > [Role] > Add assignments (scope: Directory or AU)

Method 2 — via group (P1):

• Entra > Groups > New group → enable Microsoft Entra roles can be assigned to the group at creation → then assign roles to that group.

Create an Entra custom role: Entra > Roles and administrators > New custom role → define permissions → assign.

For automation and finer control use PowerShell or Microsoft Graph API.

To remember for the exam

• Azure RBAC ≠ Azure Policy (RBAC decides who can do what; Policy enforces standards).
• Owner = Contributor + access management.
• Inheritance is cumulative: a principal’s effective permissions are the union of all role assignments.
• Deny assignments win over allow but are rare and typically managed by the platform or publishers.
• P1 is mandatory for: Entra custom roles and groups assignable to Entra roles.

---

This post clarifies Azure RBAC vs Entra ID roles, practical patterns, and exam-focused notes.