Microsoft Azure Administrator Training Course

Azure role-based access control answers one question: may this principal perform this operation on this resource? Everything else — scopes, inheritance, effective permissions — is detail on top of that. This lesson covers how a role is constructed and what the roles you will actually use permit.

The three parts of an assignment

Every access grant in Azure is a role assignment, and every role assignment joins three things:

• A security principal — a user, a group, a service principal representing an application, or a managed identity.
• A role definition — the collection of permissions.
• A scope — the management group, subscription, resource group, or individual resource the grant applies to.

Memorize that triple. Almost every RBAC exam question is asking you to identify which of the three is wrong.

How a role definition is built

A role definition is a document with four permission arrays and a list of assignable scopes:

• Actions — management operations that are allowed, written as provider strings such as Microsoft.Compute/virtualMachines/read. A wildcard * means all operations.
• NotActions — operations subtracted from Actions. This is not a deny rule; it is an exclusion applied while computing what this role grants. A permission removed by NotActions in one role can still be granted by a different role assignment on the same principal.
• DataActions — operations on the data inside a resource, such as reading a blob or a queue message.
• NotDataActions — the same subtraction, applied to data operations.

The split between management and data operations matters. An account holding Contributor on a storage account can regenerate its access keys and therefore reach the data indirectly, but Contributor by itself grants no DataActions — it does not permit reading a blob through Entra authentication. That is why the storage data roles exist and why the exam distinguishes Storage Blob Data Reader from Reader.

The core built-in roles

Four general-purpose roles cover most scenarios, and their boundaries are precise:

• Owner — full management access plus the right to delegate, meaning it can create role assignments.
• Contributor — full management access to create, modify, and delete resources, but it cannot create or modify role assignments. This distinction is the single most tested fact in the domain.
• Reader — view everything in scope, change nothing.
• User Access Administrator — manage user access to resources, meaning create and remove role assignments, without the ability to manage the resources themselves.

The complementary pairing of Contributor and User Access Administrator is the standard least-privilege alternative to handing out Owner: one person can build, another can delegate, and neither alone can do both.

Beyond the four, Azure ships a large catalog of service-specific roles — Virtual Machine Contributor, Network Contributor, Storage Account Contributor, Backup Operator, Monitoring Reader, and many more. You are not expected to recite the catalog. You are expected to know that service-specific roles exist, that they are the correct answer whenever a requirement says a person should manage only one service, and that a service-specific Contributor role manages that service without granting rights over the resources it depends on. A Virtual Machine Contributor, notably, cannot create or manage the virtual network or the storage account the machine uses.

Custom roles

When no built-in role fits, author a custom role. You define its Actions, NotActions, DataActions, and NotDataActions, and you set AssignableScopes, which controls where the role may be assigned. Custom roles are stored in the directory, can be created through the portal, PowerShell, the CLI, or a template, and there is a tenant limit on how many you may define — check the current subscription limits documentation rather than assuming a number.

The usual practice is to start from the JSON of the closest built-in role, remove what is not needed, and set assignable scopes as narrowly as the role will genuinely be used. Note that custom roles cannot use wildcards in DataActions in the way they can in Actions, and that a custom role you can no longer assign anywhere is usually an assignable-scopes problem rather than a permissions problem.

Inspecting a role before you assign it

Never assign a role you have not read. In the portal, the Roles tab of any Access control (IAM) blade lists every built-in and custom role with a description, and opening one shows its permissions and its JSON. On the command line, az role definition list --name "Virtual Machine Contributor" and Get-AzRoleDefinition return the same document. Reading the Actions and NotActions before assigning is the difference between granting what a team needs and granting a surprise.

What RBAC does not cover

Two boundaries save you from wrong answers. RBAC governs the Azure resource plane through Resource Manager; it does not govern the directory, where Entra roles apply. And RBAC is not the mechanism that protects a resource from deletion by someone who legitimately holds Contributor — that is a resource lock, covered later in this module. When a question asks how to stop an administrator from accidentally deleting production, the answer is usually a lock, not a role.

What to take away

Every grant is principal plus role plus scope. Contributor manages resources but cannot delegate; Owner can do both; User Access Administrator delegates without managing. NotActions subtract rather than deny. Data operations are separate from management operations. Reach for a built-in role first and write a custom role only when nothing fits.