Manage Access to Azure Resources: Azure RBAC (AZ-104)

Azure role-based access control (Azure RBAC) is the authorization system built on Azure Resource Manager that controls access to Azure resources — virtual machines, storage accounts, virtual networks, resource groups, subscriptions, and everything else you manage. Authentication (proving who you are) is handled by Microsoft Entra ID; authorization (deciding what you are allowed to do) is handled by Azure RBAC. The two work together every time someone opens the portal or calls the Azure API.

RBAC follows the principle of least privilege: you grant each person, group, or application only the permissions they need, at only the scope they need, rather than making everyone an administrator. You do this by creating role assignments, and you manage them from the Access control (IAM) blade that appears on every management group, subscription, resource group, and resource.

The mechanism is deliberately simple to reason about: a role is a named bundle of allowed actions, and assigning that role to someone at a scope grants them those actions across everything in that scope. Because assignments are additive and inherited, most access questions on the exam are really questions about which roles apply at which scope — the subject of the rest of this lesson.

Every Azure role assignment is built from three elements, and the exam expects you to name all three. Together they answer who can do what and where.

• Security principal (the who) — the identity being granted access. It can be a user, a group, a service principal (an application identity), or a managed identity (an Azure-managed identity for resources like a VM or function app). Assigning to a group is best practice, so access follows group membership.
• Role definition (the what) — a named collection of permissions listing the Actions and NotActions for management operations and DataActions and NotDataActions for operations on data, such as reading a blob. Reader, Contributor, and Owner are role definitions.
• Scope (the where) — the set of resources the access applies to, expressed as one of four levels: management group, subscription, resource group, or a single resource.

You bind these three together on the Access control (IAM) blade with Add role assignment: pick the role, pick the members (principals), and the scope is set by wherever you started — assigning on a resource group scopes it to that resource group. Change any one of the three and you have a different assignment. On the exam, if a question asks what a role assignment consists of, the answer is always security principal + role definition + scope.

Azure ships with many built-in roles, but four are fundamental and appear constantly on the exam. Learn exactly what each grants — especially the line between managing resources and managing access to them.

The single most tested distinction is Owner versus Contributor. Both can fully create, change, and delete resources, but only Owner can also manage access — that is, grant roles to other principals. A Contributor can build a virtual machine but cannot give a colleague permission to it; an Owner can do both. If a scenario says someone must be able to manage access as well as resources, the answer is Owner.

User Access Administrator is the mirror image: it can manage role assignments but cannot manage the resources themselves — useful when you want a person to delegate access without touching workloads. Reader grants view-only access with no changes at all. These four are general-purpose; Azure also provides many service-specific roles (for example, Virtual Machine Contributor or Storage Blob Data Reader) that grant narrower permissions when full Contributor is too broad.

Scope is where a role assignment applies, and Azure scopes form a hierarchy with four levels, from broadest to narrowest: management group > subscription > resource group > resource. The critical rule is inheritance: a role assigned at a higher scope is automatically inherited by every child scope beneath it. Assign a role on a subscription and it applies to all resource groups and all resources in that subscription; assign it on a management group and it applies to every subscription under that group.

Admin scenario. Your auditors need read-only visibility across an entire subscription that contains twelve resource groups. Rather than create twelve separate assignments, you open the subscription, go to Access control (IAM), and assign the Reader role to the auditors' group once at the subscription scope. Every one of the twelve resource groups — and every resource inside them, including ones created next month — inherits Reader automatically. This is exactly the exam phrase assign once and it applies to all child resource groups.

Inheritance flows in one direction only: downward. An assignment on a single resource group grants nothing at the subscription level or in sibling resource groups. Because assignments are additive, a principal can hold Reader inherited from the subscription and Contributor assigned directly on one resource group, ending up as Contributor there and Reader everywhere else. Choosing the right scope — broad enough to be efficient, narrow enough for least privilege — is a core administrator skill.

When no built-in role fits your requirement, you create a custom role. Built-in roles cover most needs, but you might need something in between — for example, a role that can restart virtual machines but not create or delete them, which no single built-in role provides. A custom role lets you specify exactly the permissions you want.

A custom role is defined in JSON (or built in the portal) with the same structure as a built-in role: Actions and NotActions for management operations, DataActions and NotDataActions for data operations, and AssignableScopes — the list of management groups, subscriptions, or resource groups where the role can be assigned. The effective permissions are the Actions minus the NotActions. A tenant can hold up to 5,000 custom roles.

A practical way to build one is to start from an existing built-in role, clone it, and trim or add individual operations. You create custom roles from Access control (IAM) > Add > Add custom role, or with PowerShell, the Azure CLI, or an ARM template. On the exam, the trigger is simple: if the required permissions do not match any built-in role, the answer is a custom role — do not try to force-fit Owner or Contributor onto a requirement that needs a narrower set of actions.

To interpret someone's effective permissions, remember two rules. First, Azure RBAC is additive: a principal's effective access is the union of every role assignment that applies to them, whether assigned directly or inherited from a higher scope, and whether granted to them personally or to a group they belong to. There is no concept of one assignment reducing another — if you hold Reader from the subscription and Contributor on a resource group, you are a Contributor on that resource group.

Second, deny assignments override role assignments. A deny assignment blocks a principal from performing specific actions even if a role assignment would otherwise allow them, and deny always wins. Deny assignments are not something administrators create by hand in the IAM blade; they are created by Azure itself — for example by Azure Blueprints or by managed applications — to protect the resources those services manage. You can view them, but the exam point is the precedence: an explicit deny beats any allow.

So the evaluation order is: gather all applicable role assignments (additive allow), then apply any deny assignments (which subtract). If a user seems to have too much or too little access, the cause is almost always an inherited assignment from a parent scope or a group membership they forgot about. Check both direct and inherited assignments before concluding a permission is missing.

A classic exam trap is confusing Azure RBAC with Microsoft Entra roles. They are two separate permission systems that both grant access, but to different things. Azure RBAC controls access to Azure resources — VMs, storage, networks — and is scoped through the management group, subscription, resource group, and resource hierarchy. Microsoft Entra roles control access to Microsoft Entra ID itself — managing users, groups, applications, domains, and directory settings — and are scoped to the directory (tenant), with some support for administrative units.

They are independent: being a Global Administrator in Entra ID does not automatically grant access to Azure resource subscriptions, and being an Owner of a subscription does not let you manage users in the directory. A Global Administrator can, however, choose to elevate access to manage all Azure subscriptions in the tenant — a deliberate toggle, not automatic. On the exam, manage Entra (users, groups, domains) means an Entra role, while manage Azure resources means Azure RBAC.

To see what access a principal has, use the Access control (IAM) blade, which is available on every management group, subscription, resource group, and resource. It has two tools you should know for the exam.

Check access lets you select a user, group, service principal, or managed identity and see the effective role assignments they have at the current scope, including roles inherited from parent scopes. Use it to answer questions like whether a contractor can delete resources in a given resource group, without guessing.

The Role assignments tab lists every assignment at the current scope, showing the principal, the role, and — importantly — whether each was assigned at this scope or inherited from a parent, so you can tell where access originates. There is also a Roles tab listing all available role definitions and a Deny assignments tab.

When troubleshooting, always check at the scope in question and read the inherited column: an unexpected permission usually traces back to an assignment on the subscription or management group above. On the exam, check access and the role assignments list are how you interpret and verify who can do what across your Azure resources.