Microsoft Entra ID and Azure governance for Microsoft AZ-104 Azure Administrator: Concepts, Scenarios, and Study Priorities

 

Identity and governance are easy to study as separate lists, but Azure administration treats them as a connected control system. Microsoft Entra ID defines users, groups, external identities, and authentication-related capabilities. Azure role-based access control determines who can perform management actions at a particular scope. Azure Policy evaluates or enforces organizational rules. Resource locks protect against selected management-plane changes. Tags, resource groups, subscriptions, management groups, budgets, and Advisor recommendations add structure, cost visibility, and governance across the environment.

The current AZ-104 objectives give this area 20–25 percent of the exam. The April 17, 2026 blueprint specifically includes Entra users and groups, licenses, external users, self-service password reset, built-in Azure roles, role assignments at different scopes, effective access, Policy, locks, tags, resource groups, subscriptions, management groups, and cost controls. The challenge is not remembering that these features exist. It is knowing which layer owns a requirement and how the layers interact.

A useful way to study the domain is to ask four questions in order: Who is the principal? What action is required? At what scope should it apply? What separate governance rule might still allow or block the outcome? That framework prevents many common errors, especially the tendency to use RBAC to solve a Policy problem or to assume a Contributor assignment overrides every other management control. The Azure Administrator page provides the certification context, while the governance practice set can be used after the concepts below are clear.

A control-ownership model for identity and governance

When an AZ-104 scenario feels ambiguous, classify the requirement before choosing a feature.

Microsoft Entra ID owns the identity object: users, groups, external identities, properties, licensing, and self-service password reset. Azure RBAC owns authorization to Azure resources: which principal can perform which management or data action at which scope. Azure Policy owns organizational compliance rules and allowed configuration patterns. Resource locks protect against selected management-plane deletion or modification. Tags organize and classify resources. Resource groups, subscriptions, and management groups create administrative and governance boundaries at different levels. Budgets, alerts, and Advisor recommendations help manage cost.

The controls can overlap in one scenario without being substitutes. A user can have Contributor access to a resource group and still be unable to delete a locked resource. A resource can be deployed by an authorized user and still be noncompliant with Policy. A tag can help allocate cost without granting or denying access. A management-group policy can affect subscriptions that inherit the assignment even though the user never configured the subscription directly.

This layered model is more reliable than memorizing feature descriptions because it explains why apparently conflicting controls can all be active at once.

Manage identities as a lifecycle

Start with the identity lifecycle

Microsoft Entra ID is easier to understand when you follow an identity from creation to retirement. A user or workload receives an identity, gains attributes and group memberships, is assigned or inherits access, authenticates, performs authorized actions, changes responsibilities over time, and eventually has access removed.

For study purposes, create lifecycle scenarios. A new employee joins the finance team. Which user properties matter? Which groups should the user join? Which licenses are required? What Azure access should come from group membership instead of a direct assignment? If the user changes departments, what needs to be removed as well as added? If the user leaves, what happens to Azure access, application access, and ownership relationships?

This way of thinking prevents a common mistake: treating “create user” and “manage group” as isolated portal tasks. The real administrative skill is maintaining correct access as identity state changes.

Users, groups, and properties

You should be comfortable with creating users and groups, modifying properties, and interpreting how group membership influences administration. Groups reduce the number of direct assignments and make access easier to review. If five administrators need the same Azure permissions, assigning the role to a group can be cleaner than managing five individual assignments.

But groups do not automatically solve governance. You still need to choose the right group type and membership model for the scenario, ensure the correct users are included, and understand that an Azure role assigned to the group applies according to the role assignment’s scope.

Practice by creating a fictional organization with several job functions. Give each function a group, then make a matrix of what Azure access each group needs. This turns group management into a role-design exercise.

Licensing as an administrative dependency

AZ-104 may not require you to become a Microsoft 365 licensing specialist, but the blueprint includes managing licenses in Microsoft Entra ID. The practical takeaway is that some identity capabilities and workloads depend on appropriate licensing. A user object can exist without automatically having every service entitlement.

When a scenario mentions that a user cannot access a licensed service even though the identity exists, do not jump immediately to RBAC. Ask whether the problem is a service entitlement, authentication problem, application permission, or Azure resource authorization issue. Separating those layers prevents incorrect troubleshooting.

External users and collaboration

External identities appear when people outside the organization need controlled access. The important study point is not merely that “guest users exist.” It is how an external identity fits into the same lifecycle and authorization model. An external collaborator may be invited into the tenant, added to a group, and assigned a role at a specific Azure scope.

Build scenarios where a consultant needs temporary Reader access to one resource group. Ask why subscription-level Contributor would be excessive. Ask how you would remove the access when the engagement ends. The principle is least privilege combined with lifecycle management.

Separate authentication from authorization

Understand authentication and authorization as separate questions

Identity topics become much clearer when you separate “Who are you?” from “What are you allowed to do?” Authentication establishes the identity. Authorization determines whether that identity can perform the requested action.

Self-service password reset belongs primarily to the authentication/account-recovery side of identity administration. Azure RBAC belongs to authorization for Azure resources. A user who can sign in successfully can still receive an authorization error when trying to modify a resource. Conversely, assigning a role does not fix a sign-in problem.

In practice questions, pay attention to the symptom. “Cannot sign in” points toward identity or authentication. “Can sign in and see the resource but cannot modify it” points toward authorization or another management constraint. “Has Contributor but still cannot delete” may require you to consider a resource lock or policy effect rather than simply adding more permissions.

Azure RBAC: principal, role, and scope

Learn Azure RBAC as principal + role + scope

Azure role-based access control is one of the most important governance mechanisms in AZ-104. A useful mental model has three parts:

1. Principal — the user, group, service principal, or managed identity receiving access.
2. Role definition — the collection of allowed management actions, such as Reader or Contributor.
3. Scope — the boundary at which the assignment applies.

If any of these are wrong, the assignment may not produce the intended result. The user may have the wrong role, the right role at the wrong scope, or the role may be assigned to a different principal than expected.

Scope and inheritance

Azure provides a hierarchy that commonly includes management groups, subscriptions, resource groups, and individual resources. A role assignment at a broader scope can be inherited by resources beneath that scope. This makes scope a central exam concept.

Consider a user who needs to restart one virtual machine but should not manage other resources. Subscription-level Contributor is far broader than necessary. A more targeted role and narrower scope may fit. Conversely, if an operations team needs Reader across every resource group in a subscription, repeating resource-level assignments would be inefficient compared with an appropriately scoped assignment.

When you study any role scenario, ask: what is the narrowest practical scope that satisfies the requirement? Then check whether inherited access already exists.

Built-in roles and least privilege

Avoid memorizing every built-in Azure role. Understand the pattern. Reader can view without changing. Contributor can manage resources but does not grant all access-management capabilities. More specialized roles can limit actions to a service or responsibility.

The exam often rewards recognition of least privilege. If a storage operator needs only storage-related management, a more targeted role may be better than broad subscription Contributor. The challenge is to satisfy the stated task without granting unnecessary authority.

Interpret effective access, not just direct assignments

A principal can receive access through several assignments: direct, group-based, and inherited from parent scopes. Removing one assignment does not guarantee that access disappears if another path still grants it.

Practice by assigning Reader at the subscription level and Contributor on one resource group. Then reason about what the user can do in that group versus elsewhere. Add group membership and see how the effective permission picture changes. This is more valuable than memorizing a static table of roles.

The governance practice can help you test whether scope and governance concepts remain clear under question wording.

Governance controls are not interchangeable

Distinguish RBAC from Azure Policy

RBAC and Azure Policy are frequently confused because both can influence what happens to resources. Their primary jobs are different.

RBAC answers an authorization question: is this principal allowed to perform an action at this scope? Azure Policy evaluates resource configuration against organizational rules and can audit, deny, modify, or otherwise apply policy effects depending on the definition and assignment.

Imagine an organization allows a team to create virtual machines but requires all resources to be deployed only in approved regions. RBAC can give the team permission to create the VM. Policy can constrain the region choice. The fact that a user is authorized does not mean every possible configuration is permitted by governance.

A good study habit is to write scenarios where both controls are present. Ask what happens if a user has Contributor but attempts a deployment that violates an assigned policy. Ask what happens if the configuration is compliant but the user lacks authorization. These examples force you to separate the decision layers.

Policy definitions, assignments, and scope

At a conceptual level, a policy definition states a rule, while an assignment applies that rule at a scope. The scope decision matters because governance can be broad or targeted. Be ready to reason about why a subscription-wide assignment affects resources differently from an assignment to one resource group.

Practice interpreting the purpose of a policy: audit existing resources, prevent noncompliant deployments, or enforce a required configuration. Do not reduce Azure Policy to “a thing that blocks resources.” Many governance scenarios are about visibility and compliance as much as denial.

Resource locks protect against management-plane changes

Resource locks are a different control again. They are used to protect important resources from accidental deletion or modification, depending on lock type. A lock can apply at a scope and be inherited by child resources.

The exam-relevant distinction is that a lock is not a substitute for RBAC. A user may be authorized to manage a resource but still be blocked from an operation because a lock is present. Likewise, removing a lock requires appropriate permission.

Build a simple scenario: give a user a role that normally permits deletion, place a delete lock on the resource group, and predict the result. Then ask which control should be changed if the goal is to prevent accidental deletion for everyone with management access rather than remove one user’s authorization.

Tags organize resources but do not secure them

Tags provide metadata, commonly as name-value pairs, that can support organization, cost reporting, automation, ownership, and operational processes. They are useful but should not be confused with security boundaries.

A tag such as Environment=Production can help reporting or policy logic, but it does not itself prevent access. A tag such as Owner=Finance does not assign the Finance group any role. Treat tags as descriptive or management metadata whose value often appears when combined with policy, cost management, scripts, or operational standards.

Practice creating a tag standard for department, environment, owner, and cost center. Then decide which tags should be required through governance and which are merely helpful. This connects tagging to policy and cost management.

Resource groups are lifecycle and management containers

A resource group is a logical container for Azure resources. The exam expects you to understand management at this level, including permissions, policies, locks, and resource moves where supported.

Avoid thinking of a resource group as a network boundary. Resources in the same resource group do not automatically share network connectivity. Resources in different resource groups can still participate in the same application. The grouping is primarily about management and lifecycle.

A useful design question is: which resources should be managed, deployed, updated, or deleted together? That often leads to a sensible resource-group strategy. But real organizations also consider ownership, permissions, environments, and operational boundaries.

Practice moving supported resources between resource groups and identify dependencies. Even when the move itself is straightforward, the exercise reminds you that RBAC, policy, locks, resource IDs, and automation may be affected by scope changes.

Hierarchy and cost governance

Subscriptions create important governance and billing boundaries

Subscriptions are major Azure management boundaries. They influence billing, quotas, access, policy scope, and resource organization. A role assignment at subscription scope is powerful because it can apply across many resource groups. A policy assignment at subscription scope can shape the configuration of a large environment.

In exam scenarios, identify when the subscription is part of the requirement. A team may need access across all resource groups in one subscription but no access to another. A budget may be monitored at subscription scope. A management group may contain multiple subscriptions so policy and access can be administered consistently.

Avoid assuming that “same tenant” means “same subscription” or that a resource can move freely among all subscriptions without constraints. Keep identity tenant, subscription, resource group, and resource hierarchy as separate concepts.

Management groups extend governance above subscriptions

Management groups allow organizations to arrange subscriptions into a hierarchy and apply access or policy at a broader scope. They are particularly useful when many subscriptions share governance requirements.

For AZ-104, focus on the scope model rather than designing a massive enterprise hierarchy. If ten subscriptions must follow the same location policy, a management-group assignment can be more maintainable than ten separate assignments. If an operations team needs Reader across a set of subscriptions, a role assignment at the appropriate management-group scope may satisfy the requirement.

The key reasoning pattern is inheritance. A control assigned at a parent scope can influence child scopes. This is powerful and therefore requires careful least-privilege and governance design.

Cost management is part of governance

Governance is not only security and compliance. Administrators also need to control and understand cost. The current AZ-104 objectives include alerts, budgets, and Azure Advisor recommendations.

A budget does not magically prevent spending in the same way an authorization rule prevents an action. Treat cost tools as monitoring and management mechanisms. A budget can help track spend against thresholds and trigger notifications or related workflows. Advisor recommendations can highlight opportunities related to cost, reliability, security, performance, and operational excellence depending on context.

Build a scenario where a department owns a subscription and wants notification before monthly spending exceeds an internal threshold. Ask which cost-management control creates visibility, who should receive the alert, and how tags or resource organization could improve attribution.

Cost scenarios are useful because they connect nontechnical business requirements to Azure administration. The administrator needs to know not only how to deploy resources, but also how to manage them responsibly over time.

Management plane and data plane

Know the management plane versus data plane distinction

Many Azure services have management operations and data operations. Azure RBAC roles can authorize management-plane actions, while services may also use data-plane roles or service-specific authorization for access to the actual data.

Storage is a useful example. A user may be able to manage a storage account as an Azure resource yet still lack the appropriate data access to read blobs, depending on the assigned roles and authorization method. Conversely, a principal may be granted data access without broad management rights.

You do not need to memorize every role. Understand that “can manage the resource” and “can access the resource’s data” are not always the same permission question. This distinction prevents many identity-related errors in storage and other services.

Three scenarios that expose control ownership

A governance scenario: development subscription with guardrails

Imagine a development team receives its own Azure subscription. Developers need enough freedom to create common resources, but the organization requires approved regions, mandatory ownership tags, protection for a shared networking resource, and a spending alert.

Break the requirement into controls. RBAC determines which developers can create and manage resources. Policy can restrict deployment regions and require or audit tags. A resource lock can protect the shared networking resource from accidental deletion. A budget and alert can monitor spending. Resource groups can separate workloads or lifecycle boundaries.

Notice that no single feature solves the whole requirement. That is a common AZ-104 pattern. Strong answers come from mapping each constraint to the control that actually owns it.

After designing the environment, introduce a troubleshooting symptom: a developer with Contributor cannot deploy a VM in a region. Do not immediately add permissions. Check whether policy denies the region. Another symptom: a developer cannot delete an old resource despite sufficient RBAC. Check for a lock. The scenario becomes easier when you know which layer to inspect.

An identity scenario: external consultant with temporary access

A consultant needs read-only access to resources in one project for two weeks. The organization does not want to create a broad internal administrator account.

A reasonable design can use an external identity, group membership if appropriate, and a narrowly scoped Reader assignment. The expiration process should be part of the plan: remove the role, group membership, or external identity relationship when access is no longer needed according to organizational policy.

Now change the requirement. The consultant needs to update only a specific type of resource. Broad Contributor may be excessive. Consider whether a more specialized built-in role or carefully defined access model fits the task. The principle is to grant only the permissions needed at the narrowest sensible scope.

This scenario also teaches that identity lifecycle continues after initial provisioning. Temporary access is only secure when offboarding is planned.

A troubleshooting scenario: “I have Contributor but it still fails”

This sentence should trigger a structured investigation. First, confirm that the role assignment is actually effective at the target resource. Check principal, role, scope, group membership, and inheritance. If authorization is correct, identify whether another control affects the operation.

A delete lock may block deletion. Azure Policy may deny a noncompliant deployment. A service-specific permission model may apply to data-plane actions. A license or identity issue may affect another service. The correct response depends on the action and symptom.

Do not respond to every failure by assigning Owner or a broader role. That habit defeats least privilege and may not fix the actual problem. Troubleshooting should narrow the layer before changing access.

Practice through both portal and automation

Practice governance in the portal and through automation

The portal is a good place to visualize role assignments, policy compliance, tags, locks, and hierarchy. But governance scales through repeatability. Practice retrieving assignments with Azure CLI or PowerShell and reading how resource IDs encode subscription, resource group, provider, type, and name.

For infrastructure-as-code scenarios, observe that policy assignments, role assignments, tags, and locks can be represented or automated. You do not need to become an automation specialist for AZ-104, but Make sure you understand that governance is more reliable when it can be applied consistently.

A helpful exercise is to create a resource group manually, apply tags and a lock, then reproduce part of the configuration through a script or template. Compare the resulting state rather than focusing only on syntax.

Common traps and a staged study sequence

Common identity and governance traps

Several patterns deserve deliberate review:

• confusing authentication failure with authorization failure;
• assigning permissions at a broader scope than necessary;
• forgetting inherited role assignments;
• assuming removing one direct role removes all effective access;
• treating Azure Policy as a user-permission system;
• treating a lock as a substitute for least privilege;
• assuming tags create security boundaries;
• confusing resource groups with network boundaries;
• ignoring management-group inheritance;
• treating cost budgets as hard spending caps;
• overlooking the difference between resource management and data access.

Create one example for each trap. If you can explain the failure mode, the correct control, and the evidence you would inspect, you are building scenario-ready knowledge.

A hands-on study sequence

A focused identity and governance study block can follow this order:

Stage 1: identity objects

Create users, groups, and an external identity. Modify properties and group membership. Review which changes belong to identity administration rather than Azure resource management.

Stage 2: role assignments and scope

Assign Reader and Contributor at different scopes. Observe inheritance. Remove one assignment and verify whether access remains through another path. Practice interpreting effective access.

Stage 3: governance controls

Create or review a policy assignment, add tags, and apply a resource lock. Predict the result before testing. Compare what each control can and cannot do.

Stage 4: hierarchy

Organize resource groups and subscriptions conceptually under a management group. Decide where a shared policy or role should be assigned. Explain the inheritance effect.

Stage 5: cost management

Create a budget or study its configuration, define an alert threshold, and decide who should receive notifications. Review Advisor recommendations and distinguish recommendation from enforcement.

Stage 6: integrated scenarios

Combine identity, RBAC, policy, locks, tags, and cost requirements into one fictional environment. Add a failure and troubleshoot the correct layer.

The AZ-104 labs can help you turn this sequence into broader cross-domain labs.

Build the governance model from memory

The core idea: governance is layered

The most important lesson is that Azure governance works through layers. Identity establishes who the principal is. Authorization determines what that principal can do. Policy expresses organizational rules about resources. Locks protect important resources from certain management changes. Tags add management context. Resource hierarchy determines scope and inheritance. Cost controls provide financial visibility.

AZ-104 scenarios become much easier when you identify the layer that owns the requirement. If the problem is “who can change this resource,” start with authorization. If the problem is “which regions can resources use,” think policy. If the problem is “prevent accidental deletion despite broad management access,” consider a lock. If the problem is “apply the same rule across several subscriptions,” consider management-group scope.

Study these mechanisms as a coordinated management system rather than a glossary. That approach is closer to real Azure administration, produces better troubleshooting habits, and gives you a durable framework for the identity and governance portion of AZ-104.

Build a one-page governance map from memory

A useful final exercise is to draw the Azure management hierarchy and place each governance control on it from memory. Start with management groups at the broadest organizational level, then subscriptions, resource groups, and resources. Beside the hierarchy, write examples of controls that can be assigned at scope: RBAC roles, policy assignments, and locks. Add tags as resource metadata and budgets or alerts as cost-management tools.

Then choose a fictional company with three subscriptions: Production, Development, and Sandbox. Write five requirements and decide where each belongs. For instance, all subscriptions must use approved regions; only the operations team may administer Production; developers may manage Development resource groups; a shared production resource must not be deleted accidentally; and the Sandbox subscription should notify the owner when spending reaches an internal threshold.

The value of the exercise is not the exact diagram. It is the act of mapping each requirement to the right mechanism and scope. If you choose subscription-level Contributor when a resource-group assignment would satisfy the need, ask why. If you assign the same policy separately three times, ask whether management-group scope would be cleaner. If you use a tag to solve an authorization problem, correct the category error.

This kind of deliberate comparison also exposes whether you are choosing Azure controls by habit or by requirement, which is exactly the distinction that matters in architecture and administration scenarios.

Repeat the exercise a week later with different requirements. If you can produce a coherent design without checking notes, you have moved beyond feature recognition. You are reasoning about Azure governance as an administrator, which is the level of understanding the AZ-104 identity and governance domain is designed to measure.

Final identity and governance checklist

Before moving on, Be ready to explain and apply the following without relying on vague definitions:

• create and manage users and groups;
• reason about licenses and external identities in the correct context;
• explain self-service password reset as an identity-management capability;
• identify principal, role, and scope in an Azure RBAC assignment;
• reason about inheritance and effective access;
• apply least privilege when choosing scope and role;
• distinguish RBAC from Azure Policy;
• explain what resource locks protect and what they do not replace;
• use tags as management metadata rather than security boundaries;
• explain the management purpose of resource groups, subscriptions, and management groups;
• understand how higher-scope assignments can affect child resources;
• use budgets, alerts, and recommendations as cost-management tools;
• distinguish resource management permissions from service data access where relevant.