Microsoft AZ-104: Azure RBAC and Entra Roles

Role confusion is one of the easiest ways to lose points on AZ-104 because Azure uses more than one authorization system. Azure role-based access control governs access to Azure resources such as subscriptions, resource groups, virtual machines, storage accounts, and other resources managed through Azure Resource Manager. Microsoft Entra roles govern directory resources such as users, groups, applications, and tenant-level identity administration.

The current AZ-104 objectives give 20–25% of the exam to identities and governance. Microsoft expects candidates to manage Entra users and groups, assign Azure roles at different scopes, interpret access assignments, and work with subscriptions, management groups, policy, locks, tags, and cost controls. The exam therefore rewards candidates who can distinguish identity administration from resource authorization.

The simplest rule is useful but not sufficient: Entra roles manage the directory; Azure roles manage Azure resources. Scenario questions often become harder because the same person may need both, and because words such as “administrator,” “owner,” and “contributor” can sound similar even when they belong to different control planes.

Start by identifying the resource being administered

Before choosing a role, ask what object the task is trying to change. If the requirement is to create users, reset passwords, manage applications, or administer directory settings, you are in the Microsoft Entra control plane. If the requirement is to create a VM, configure a storage account, manage a resource group, or assign access to an Azure resource, you are in Azure RBAC.

The distinction is explained clearly in Microsoft Entra ID and Azure RBAC. The systems use similar concepts—roles, assignments, principals, and scope—but they protect different resources and store their authorization information separately.

Train yourself to underline the noun in a scenario. “Manage users” points toward Entra. “Manage virtual machines” points toward Azure RBAC. “Allow an application to read a storage account” involves an identity from Entra but a permission granted through Azure RBAC. That last pattern is especially common because identity and authorization often meet in one workflow.

Azure RBAC is built from security principal, role, and scope

An Azure role assignment combines who receives access, what permissions are granted, and where those permissions apply. The security principal can be a user, group, service principal, or managed identity. The role definition contains allowed operations. The scope can be a management group, subscription, resource group, or individual resource.

Scope inheritance makes design important. A role assigned at a subscription can flow to many resource groups and resources, while a role assigned to one storage account is much narrower. Least privilege therefore means choosing both the smallest useful role and the smallest useful scope.

Use Azure Policy and Azure RBAC to keep authorization separate from governance. RBAC answers who may perform an action. Policy evaluates or constrains what resource configurations are allowed. Giving someone Contributor does not exempt their deployment from policy.

Microsoft Entra roles control identity administration

Microsoft Entra ID has many built-in administrative roles, plus support for custom roles in eligible scenarios. These roles govern directory objects and services. Examples include administration of users, groups, applications, authentication, security settings, and other tenant resources.

Study Microsoft Entra ID as an identity system rather than as “the place users live.” It authenticates identities, supports applications and workload identities, and provides the foundation that Azure RBAC later uses when granting access to Azure resources.

A directory administrator does not automatically gain broad rights over Azure resources. Likewise, an Azure subscription Owner does not automatically become a global directory administrator. This separation of control planes is intentional and supports separation of duties.

Built-in role names can hide important permission differences

Owner, Contributor, and Reader are common Azure roles, but exam questions often depend on one critical permission. Owner can manage resources and grant access. Contributor can manage resources but cannot normally grant Azure RBAC access. Reader can view resources without making changes. More specialized roles reduce privilege further.

Do not memorize role names without testing them. In a lab subscription, assign a user Reader at a resource group and Contributor at one resource. Sign in as that user and observe what is possible. Then compare effective access at each scope. Practical testing makes inheritance much easier to reason about.

For identity-focused administration, related learning such as SC-300 identity and access administration can deepen the Entra side, but keep the AZ-104 target in view. AZ-104 expects enough Entra knowledge to administer Azure effectively, not the full depth of a dedicated identity certification.

Groups and managed identities reduce assignment sprawl

Assigning roles directly to many individual users creates administrative overhead. Groups let you manage membership separately from resource permissions, which makes access easier to review and change. For workloads, managed identities reduce the need to distribute credentials to applications and scripts.

Practice giving a managed identity access to one resource and then removing the assignment. Observe how the application fails. The exercise makes a key principle concrete: authentication proves which identity is calling; authorization decides whether that identity may perform the requested action.

This is also why application secrets and Azure RBAC are different topics. A credential can authenticate an application, but it does not define what the application should be allowed to do. Good design separates credential management from permission management and minimizes both long-lived secrets and broad role assignments.

SSO and authentication are related to RBAC but solve different problems

Candidates sometimes mix single sign-on, MFA, conditional access, and RBAC into one idea because they all affect access. They operate at different stages. Authentication methods help prove identity. Conditional access can apply policy to the sign-in. SSO reduces repeated authentication across applications. RBAC determines what the authenticated principal can do to a protected resource.

The mechanics of single sign-on are useful background because they show how identity sessions differ from authorization decisions. A user can sign in successfully and still be denied access to a resource because the required role assignment is missing.

When answering a scenario, ask where the failure occurs. If the user cannot authenticate, investigate identity and authentication controls. If sign-in succeeds but the user cannot perform the resource action, investigate authorization. Separating those stages prevents many wrong answers.

Practice effective access instead of memorizing diagrams

Real Azure environments contain nested group membership, inherited role assignments, resource-level exceptions, policies, and multiple subscriptions. The exam is easier when you are comfortable tracing effective access. Start at the resource, move upward through scopes, and identify every relevant assignment to the user, groups, or workload identity.

Then add governance. Apply Azure Policy that blocks a configuration and observe that a Contributor still cannot deploy the disallowed resource. Add a resource lock and observe another kind of restriction. These controls overlap in effect but arise from different mechanisms.

The core AZ-104 skill is not memorizing two lists of roles. It is recognizing which authorization system owns the decision, selecting the least-privileged role, applying it at the right scope, and explaining why authentication or governance controls may still affect the result. Once you can reason through that sequence, RBAC and Entra role questions become much more predictable.

Privileged access deserves extra attention because the consequence of a wrong assignment is much higher. Permanent broad administrative rights create unnecessary exposure. Where licensing and requirements permit, organizations can use privileged identity controls so eligible users activate sensitive roles only when needed, often with additional verification and approval. Even if AZ-104 does not ask you to design an entire privileged-access program, the least-privilege reasoning is directly relevant.

Custom roles are another area where candidates should resist overengineering. Built-in roles are usually preferable when they meet the requirement because they are easier to understand and maintain. A custom role makes sense when the needed permission set genuinely does not exist and the organization can own the lifecycle of that definition. Do not create a custom role simply because a built-in role contains one permission you dislike without first checking whether a narrower built-in option exists.

Use access reviews as a mental habit even when a question does not explicitly mention them. Ask how the organization will know later whether the assignment is still justified. Group-based assignments, clear scope boundaries, temporary elevation, and documented ownership all make review easier. Role design is not complete at the moment access is granted; it also includes how access is removed.

One final lab ties the concepts together: create a user, a group, and a managed identity. Give each a different Azure role at a different scope. Add an Entra administrative role to only the user. Test which directory and resource actions each identity can perform, then remove one assignment and retest. That concrete comparison is difficult to forget and makes many exam scenarios feel obvious.

For revision, build a two-column sheet with “directory action” and “Azure resource action.” Place tasks such as resetting a user password, registering an application, starting a VM, assigning access to a storage account, and changing a resource group into the correct column. Then identify which identity performs the action and which role system grants it. This simple drill reinforces the boundary more effectively than memorizing role lists.

• Category: All Certifications Certifications