Microsoft AZ-104 - Microsoft Azure Administrator - Manage Azure Identities and Governance -Manage access to Azure Resources

Manage Access to Azure Resources

• Azure RBAC Concepts 

• Manage built-in Azure roles

• Assign roles at different scopes

• Interpret access assignments

• Troubleshoot access issues

• Privileged Identity Management (PIM)

• Microsoft Entra access packages and access reviews

• Managed Identities

• Conditional Access

Azure RBAC Concepts

Azure Role-Based Access Control (Azure RBAC) is the authorization system built into Azure Resource Manager (ARM). A role assignment answers three questions: Who gets access? What can they do? Where does that access apply? For least privilege, choose a role that covers the required actions and assign it at the narrowest scope that covers the required resources.

A role assignment connects an identity, a role, and a scope

Role assignment = Security principal + Role definition + Scope

• Security principal is the identity receiving access. A user represents an individual. A security group lets you manage access for multiple users through one assignment. A service principal represents an application or automation workload in the tenant. Azure roles can also be assigned to managed identities, which use service principals that Azure manages.

• Role definition is the set of allowed operations. Azure provides built-in roles for common jobs and supports custom roles when an organization needs a different permission set. A role can cover broad resource management or a narrower task such as managing virtual machines.

• Scope is the boundary of the assignment. In the diagram, members of Ops-Readers get Reader access to resources in the Production resource group through their group membership. Assigning Reader to the group once lets you manage who receives that access by updating membership.

Built-in Azure role	What it lets you do
Owner	Manage Azure resources and assign Azure roles.
Contributor	Manage Azure resources. Creating Azure role assignments requires separate permission.
Reader	View Azure resource configuration. Reading service data, such as blobs, can require a separate data role.
User Access Administrator	Manage access to Azure resources.
Virtual Machine Contributor	Manage VMs and related operations covered by the role.

app registration is the blueprint, and a service principal is the tenant’s badge

The app registration defines the application’s identity and configuration in its home tenant. The service principal represents that application in a particular tenant. In the Microsoft Entra admin center, you typically find the blueprint under App registrations and the local badge under Enterprise applications. A multitenant app has one application object and a local service principal in each tenant where it has been added. Each tenant can grant its local service principal different access.

In this example, Tenant B grants its local service principal Reader on a single resource group. Adding the app to Tenant B establishes its local identity. The Azure role assignment is what grants access to that resource group. A managed identity follows a different lifecycle. Azure manages its service principal, and it has no associated app registration.

Azure resource scopes and Microsoft Entra directory scopes

Azure RBAC scopes inherit downward. A role assignment at management group scope can reach resources in descendant subscriptions. A subscription assignment reaches its resource groups and resources. In the diagram, the resource group assignment reaches both VMs. An assignment on VM01 alone would apply only within that VM’s scope. A resource provider such as Microsoft.Compute supplies resource types such as VMs. The four scope levels are the management group, subscription, resource group, and resource.

Microsoft Entra roles administer directory objects. Examples include Global Administrator, User Administrator, and Billing Administrator. For supported roles, an administrative unit narrows the set of objects an administrator can manage. For example, an AU-scoped Helpdesk Administrator can reset passwords for eligible users in that AU. Adding a group to an AU brings the group object into scope. To bring its users into scope, add the users themselves. The Microsoft Entra roles can be assigned to the group setting in the reference screenshot is for groups that receive Entra directory roles. An ordinary Entra security group can receive an Azure RBAC assignment without that setting.

Classic subscription roles are historical. Older material may refer to Account Administrator for the billing account and Service Administrator or Co-Administrator for subscription management. Microsoft documents classic administrator roles as fully retired as of May 2026. Use Azure RBAC for current Azure resource access scenarios.

Using Access control (IAM) in the Azure portal

Open the relevant Azure scope and select Access control (IAM). Use Role assignments to see who has access, which roles they hold, and where those roles were assigned. Use Check access to investigate a particular user, group, or workload identity. If you need to remove an inherited assignment, go to the parent scope where it was created. If the user receives the role through a group, review the group membership and the assignment to that group.

AZ-104 example. An operator can view VM01 but cannot restart it. They belong to Ops-Readers, which has Reader on the VM’s resource group. The assignment already reaches VM01 through inheritance. The missing piece is a role definition that permits restart. Broadening the scope of Reader would still grant only read access.

Microsoft Entra administrative units

An administrative unit (AU) groups selected users, groups, or devices within a Microsoft Entra tenant. Assigning a supported Entra role at the AU scope limits where that administrator can use the role. The role still determines what they can do.

Example. The East Helpdesk technician can reset passwords for eligible East employees in the AU. West employees are outside the scope of this assignment. Both sets of employees are in the same tenant.

• Group membership detail. Adding a group to an AU brings the group object into scope. To bring the people in that group into scope for tasks such as password resets, add their user accounts to the AU.

• AZ-104 distinction. An administrative unit scopes Microsoft Entra directory administration. An Azure resource group scopes Azure RBAC access to resources such as virtual machines.

Manage Built-in Azure Roles

Azure RBAC custom roles

A built-in role is a permission set that Microsoft defines and maintains. Examples include Reader, Contributor, and Virtual Machine Contributor. A custom role is a permission set your organization defines when the available built-in roles grant too much access or leave out an action your team needs. In the Azure portal, you can clone an existing role, start from scratch, or import a JSON file. Cloning creates a separate role definition that you can edit.

In this example, Reader lets the support team view VMs, while Virtual Machine Contributor gives the team broader VM management permissions than it needs. A custom role can grant VM read and restart permissions while leaving out actions such as deleting VMs.

The exam distinction is between assignable scope and assignment scope. The assignable scope makes the custom role available for assignment within the Production subscription. The assignment scope is where the team actually gets permissions. Here, the VM Support group receives the role only on the App-VMs resource group. Creating the role definition by itself grants nobody access.

Licensing correction. The Microsoft Entra ID Premium licensing requirement applies to custom Microsoft Entra directory roles. For an Azure RBAC custom role, the creator needs Microsoft.Authorization/roleDefinitions/write on all of the role’s assignable scopes.

Azure built-in roles

Azure built-in roles are predefined permission sets maintained by Microsoft. A role defines what someone can do, and the assignment scope defines where they can do it. For example, Contributor assigned to a resource group grants resource management permissions within that group and its resources.

Built-in role	What it grants at the assigned scope	Typical use
Owner	Create, modify, and delete resources, and grant or revoke Azure RBAC access.	Reserve for administrators who need both resource and access management.
Contributor	Create, modify, and delete resources. Role assignments require separate permission.	Infrastructure administrators who deploy and maintain resources.
Reader	View resource configuration. Resource changes require a different role.	Auditors, security reviewers, and monitoring staff who need read-only visibility.
User Access Administrator	View Azure resource configuration and manage access assignments. The role itself grants neither general resource modification nor permission to read secret values.	Administrators who grant or revoke access. Treat it as privileged because the holder can grant powerful roles.
Virtual Machine Contributor	Manage VMs, VM configurations, and disks. Managing connected virtual networks, storage accounts, or role assignments requires separate permissions.	A team responsible for operating VMs.
Storage Blob Data Contributor	Read, write, and delete blob data.	A user or workload that needs to work with blob contents, for example within one container.

AZ-104 distinction. If an auditor needs to inspect a storage account’s configuration, choose Reader. If an application needs to read, write, and delete blobs inside a specific container, choose Storage Blob Data Contributor at that container’s scope. The operation and the scope together determine the access granted.

Assign Roles at Different Scopes

Scope determines where a role assignment applies. An Azure RBAC assignment connects a security principal such as a user, group, or managed identity to a role at a specific scope. The role defines what the principal can do. The scope defines which resources those permissions cover. Permissions inherit downward from a parent scope to its descendants.

In this example, Platform Ops receives Contributor on the Production subscription. The assignment applies to both resource groups and their resources, including the VM and storage account. The same assignment also covers resources added later within that subscription. Its reach stops at the subscription boundary.

Assignment scope	Where the permissions apply	Example
Management group	The selected management group and its descendants, including subscriptions, resource groups, and resources.	Give central auditors Reader access across several subscriptions.
Subscription	The selected subscription and all resource groups and resources within it.	Give Platform Ops Contributor across Production.
Resource group	The selected resource group and the resources it contains.	Give an application team Contributor on its own resource group.
Resource	The selected resource and any child scopes beneath it.	Give an operator Virtual Machine Contributor on one VM.

AZ-104 takeaway. Choose the narrowest scope that covers the task. If the team manages only the application VM, assign the role on that VM. If it manages the entire application stack in one resource group, assign the role on that resource group. A resource-group assignment applies to its own resources, while a subscription assignment reaches every resource group in that subscription.

Interpret Access Assignments

To determine a user’s effective permissions, start with the target resource and the action the user wants to perform. Combine all applicable role grants, including assignments made directly to the user and assignments received through groups. A role assigned at a parent scope also applies to its descendants. An applicable deny assignment overrides a grant for the action it blocks.

Reader at the subscription and Contributor on one resource group

Additive permissions. Maya can view and manage the app VM because it inherits Contributor from App-RG and Reader from the subscription. She can view the storage account’s configuration in Data-RG, where only Reader applies. The resource-group assignment adds permissions within its own branch of the hierarchy.

Deny assignments. If an applicable deny assignment blocks deletion of the app VM, Maya cannot delete it even though Contributor grants that action. Other actions, such as restarting the VM, remain available if granted and outside the deny. Azure creates deny assignments in supported scenarios, such as deployment stacks configured with deny settings.

Verify in the Azure portal

1. Open the target resource and select Access control (IAM) → Check access.

2. Select the user, group, or service principal. Review the role assignments that apply at that scope and where each assignment originates.

3. Compare the role’s permissions with the specific action you’re troubleshooting. Check the Deny assignments tab for blocks at that scope or inherited from a parent.

   
   

Troubleshooting Access Issues

Start with the identity, the requested action, and the target resource. For example, “Maya can view VM01 but can’t restart it” gives you a specific operation and scope to investigate. Open Access control (IAM) → Check access on the target resource to review the role assignments that apply there.

Check	What to look for
Role	Does the role grant the exact action? Reader lets Maya view VM01. Restarting it requires a role that grants the restart operation.
Scope and inheritance	Is the role assigned on the target resource or a parent scope? A role on a sibling resource group gives Maya no access to VM01.
Group membership	If the role was assigned to a group, confirm the caller belongs to the group that received the assignment.
Deny assignment	In IAM → Deny assignments, check the target scope and inherited denies. An applicable deny blocks the specified action even when a role grants it.
Azure Policy	RequestDisallowedByPolicy points to a governance rule. For example, a Contributor can have permission to create a VM, yet Azure Policy can block deployment in a disallowed region. Check the policy identified in the error.
Propagation	If the assignment was just added or changed, allow time for it to take effect. Sign out and back in, or refresh the access token if you’re calling the API.

AZ-104 exam tip. Break each scenario into security principal + role + scope. Trace direct, group-based, and inherited assignments to determine which roles apply. Then check whether an applicable deny blocks the requested action. If the question gives you RequestDisallowedByPolicy, investigate the policy named in the error.

Microsoft Entra Privileged Identity Management

Privileged Identity Management (PIM) gives administrators just-in-time access. An eligible assignment lets someone activate a role when they need it. An active assignment lets them use the role’s permissions. When a time-limited activation expires, the user loses the permissions granted by that activation and can activate again if they’re still eligible.

Example. A cloud operator is eligible for Virtual Machine Contributor on the Production-VMs resource group. During a maintenance window, the operator requests activation for one hour, provides a justification, and satisfies the MFA requirement. If the role requires approval, an approver must also approve the request. Once active, the operator can manage VMs within that scope until the hour ends. The role and scope control what the operator can do and where. PIM controls when and for how long.

PIM supports Microsoft Entra directory roles, Azure RBAC roles, and eligible group membership or ownership through PIM for Groups. The slides use the older name Azure AD Premium P2. Current licensing options include Microsoft Entra ID P2 or Microsoft Entra ID Governance.

Microsoft Entra access packages and access reviews

An access package answers “What access does this person need to get started?” An access review answers “Does this person still need the access they already have?” Both are part of Microsoft Entra ID Governance.

Feature	What it does	Project Atlas example
Access package	Bundles resource access into one assignment. Its policy controls who can request it, whether approval is required, and when it expires.	A new team member makes one request for the project security group, tracking app, and SharePoint site.
Access review	Lets designated reviewers confirm whether existing access should continue. Review results can be applied manually or automatically, depending on the configuration.	The project owner reviews assignments quarterly and removes package access for people who have moved off the project.

An access review can also cover access granted outside a package, such as group membership or an enterprise app assignment. Reviews of Microsoft Entra directory roles and Azure resource roles can be configured through Privileged Identity Management (PIM).

Managed Identities

A managed identity gives an Azure workload an identity in Microsoft Entra ID. Azure manages the underlying credentials, so the application can request an access token without storing a client secret or certificate in its code or configuration.

Example — An Azure VM reads files from Blob Storage

The app requests the token through Azure’s managed identity endpoint. The token identifies the caller. An Azure RBAC role assignment such as Storage Blob Data Reader on the target container authorizes the read. Enabling the identity and granting it access are two separate steps.

Identity type	Lifecycle	When to use it
System-assigned	Enabled on one Azure resource and deleted when that resource is deleted.	One VM needs its own identity and permissions.
User-assigned	Created as a separate Azure resource. It can be attached to multiple supported resources and survives their deletion.	Several VMs need the same permissions, or a replacement VM needs to reuse the existing identity.

AZ-104 cue. If the identity must survive replacing the VM, choose user-assigned. If the identity should belong to just one VM and be deleted with it, choose system-assigned.

Microsoft Entra Conditional Access

Conditional Access is the policy engine in Microsoft Entra ID that decides under what conditions a user can access an app. After the user completes initial authentication, Entra evaluates the policies that apply to the request. Those policies can use signals such as the user’s group, the target app, the network location, the device’s compliance status, and sign-in risk.

Example. A policy requires employees accessing the Azure portal to use multifactor authentication (MFA) and a compliant device. An employee who satisfies both requirements can proceed. If the device fails the compliance check, completing MFA alone is insufficient. A separate session control, such as sign-in frequency, can govern when the employee must authenticate again.

Where tokens fit. The client presents an access token to the app or API. When the client has a refresh token, it can use it with Entra to request a new access token, and Entra can reevaluate applicable policies. For supported apps and clients, Continuous Access Evaluation (CAE) can respond to certain changes, such as a disabled account, before the current access token expires.

AZ-104 distinction. Conditional Access governs the conditions for accessing the Azure portal. Azure RBAC governs what the user can do with Azure resources, such as viewing or restarting a VM.