Azure RBAC Scope and Least Privilege

The three parts of an Azure role assignment

Azure role-based access control (Azure RBAC) manages authorization to Azure resources. A role assignment has three core parts: security principal, role definition, and scope. The principal is the identity that receives permission. It can be a user, group, service principal, or managed identity. The role definition lists allowed actions. The scope identifies the set of resources where that permission applies.

When an AZ-104 scenario asks who can do what, write these three parts down before choosing an answer. If the scenario asks an application to read blob data, the principal may be its managed identity, the role must allow the data operation, and the scope should be limited to the relevant storage resources when practical. If a human operator must restart a VM, the principal is the user or group and the selected role must allow the required management action.

A role assignment grants the role’s permissions at its scope and generally at child scopes through inheritance. That makes scope a security decision. Subscription scope affects a wide set of resources; resource-group scope narrows access to that group; resource scope can narrow it to one resource. The right level is the smallest scope that supports the actual job without creating unmanageable administration.

Scope hierarchy and inheritance

Azure resources are organized into management groups, subscriptions, resource groups, and individual resources. A role assigned at a broader scope can be inherited by descendants. A role assigned at a resource group applies to its resources, while a role assigned at one resource is more restricted. Scope choices should account for what the person must manage and how often the resource set changes.

Suppose a team manages three virtual machines in a single project resource group. Assigning a suitable role at that resource group may be practical because the group represents the work boundary and new project VMs inherit the access. If the person should administer only one storage account, a role assignment on that account may be more appropriate. Granting at the entire subscription just because it is convenient expands authority to unrelated projects.

Scope inheritance can explain why a user has more effective access than expected. Inspect assignments at the resource, resource group, subscription, and management group. A permission may come from a group membership or a higher-level assignment. Removing a direct resource assignment will not remove a permission inherited from a parent scope. Check the effective access path before concluding that an assignment is absent.

Choose a role by required actions

Built-in roles package common sets of actions. Some roles are broad, while others target a narrow task. The Owner role has extensive authority, including managing access. Contributor can manage many resources but does not grant the same access-management control as Owner. Reader can inspect resources but cannot change them. There are also service-specific and data-specific roles. Read the role’s actual permissions when the scenario calls for a precise capability.

Do not pick a role based only on its name. Ask what action the principal must perform. ‘Manage virtual machines’ can mean start, stop, redeploy, or change configuration, and those operations may not all be covered by the same least-privilege role. ‘Read data’ is different from ‘configure the storage account.’ A broad role may technically work but violate the least-privilege goal.

If no built-in role meets a precise requirement, a custom role may be relevant in real administration. For exam scenarios, first determine whether a built-in role named in the options satisfies the stated need. Custom roles add maintenance responsibility and should not be selected just because they seem more specific without checking the actual permitted actions.

Management-plane and data-plane access

Azure distinguishes management of a resource from access to the data it contains. A management-plane role can allow someone to configure a storage account without allowing them to read blob contents. A data-plane role can allow data operations without granting broad control over account configuration. This distinction is a common source of exam errors.

For example, an application needs to read blobs. A broad management role on the storage account may not provide the intended data permission. Identify the workload identity, choose an appropriate blob data role, and assign it at the narrowest supported scope. If the scenario asks an administrator to configure networking or account properties, the management plane may be the relevant access surface.

Authentication and authorization also have separate jobs. Microsoft Entra ID establishes or verifies identity. Azure RBAC authorizes actions on Azure resources. An application can authenticate successfully and still receive an authorization error because it lacks the needed role. Conversely, a role assignment does not fix a broken network path or invalid credential.

Worked example: contractor access

A contractor must restart virtual machines in a project resource group for one month. The contractor must not add users, change virtual network rules, or work on other subscriptions. Start by identifying the principal, preferably an approved group or named account under the organization’s access policy. Select a role whose permitted actions include the needed VM operations but not unnecessary access-management rights. Set the scope to the project resource group if that boundary matches the assignment.

Then consider duration and review. Remove the grant when the assignment ends or use an approved time-bound access process if available. Verify the contractor can perform the required action and cannot change unrelated resources. A subscription-wide Owner assignment is much broader than needed. A tag that says ‘contractor’ does not authorize anything. A lock does not give permission to restart a VM.

Worked example: application reads storage

A web application hosted on Azure must read a set of blobs. The team wants to eliminate an account key stored in configuration. Enable a managed identity for the workload and grant that identity a suitable blob data role. Use the storage account or container scope that satisfies the requirement and supported role-assignment behavior. Then update the application to request tokens and validate that it can read the intended data.

Several tempting alternatives fail. A resource lock protects the resource from certain changes but does not grant data access. A tag classifies the account but does not grant permissions. A user password or account key stored in code creates credential risk. A broad Contributor or Owner role may grant unnecessary management actions and may not be the correct data role. The words ‘read blobs’ and ‘without a stored password’ determine the choice.

RBAC is not Policy, locks, or network security

Azure RBAC answers who may perform an action. Azure Policy evaluates or constrains resource configuration. Resource locks help prevent deletion or modification at a scope. Network security groups filter network traffic. These controls can work together, but one does not replace the others. If an administrator can deploy a prohibited VM location, Policy may address the configuration rule. If the concern is an authorized operator deleting a resource, a lock may be appropriate. If traffic is exposed, networking controls matter.

A candidate should first classify the failure. Is the principal unable to sign in, authenticated but unauthorized, blocked from reaching the endpoint, or attempting a configuration that violates governance? Those are different problems. Choosing a control from the wrong layer can add permissions while leaving the actual issue untouched.

Common RBAC mistakes

• Granting Owner because a user needs one administrative action. Check whether a narrower role suffices.
• Assigning at subscription scope when the work is limited to one resource group or resource.
• Confusing resource configuration rights with access to the data inside a service.
• Assuming a successful sign-in means the identity has permission to perform the action.
• Removing a direct assignment but overlooking inherited access from a parent scope or group.
• Treating tags, locks, Policy, and network rules as permission assignments.

A repeatable answer method

For an RBAC scenario, use this sequence: (1) name the principal; (2) state the exact action; (3) determine whether it is management-plane or data-plane; (4) select the narrowest role that permits the action; (5) choose a scope that covers the work and no more; (6) consider inherited access and duration; and (7) verify effective permissions. This method prevents answers based on role-name familiarity alone.

If two answer choices both permit the action, compare scope and privilege. If one role is broad and another is task-specific, the least-privilege answer is generally the narrower one, provided it truly includes the needed action. If the candidate cannot tell, inspect the role definition or the facts provided in the item rather than inventing permissions.

Exam and operational boundaries

AZ-104 tests the public skills outline, but Microsoft does not publish secure questions or a fixed count. This page teaches the RBAC decision model and original examples; it is not a simulation of a specific live item. Azure services and role definitions can evolve, so use current Microsoft documentation for exact permissions in an operational environment.

In production, follow organizational approval, change control, access review, and incident procedures. A technically correct assignment may still require business approval. The exam teaches Azure administration choices, while an administrator’s real responsibilities include following the organization’s security and governance process.