Entra Groups, Roles, and Access Reviews in Everyday Administration
Identity administration becomes difficult when access is granted one person at a time and then forgotten. A user joins a project, receives a direct role assignment, changes teams, gains another set of permissions, and eventually leaves behind a trail of access that nobody is confident enough to remove. Microsoft Entra groups, Azure roles, directory roles, Privileged Identity Management, and access reviews exist partly to replace that accumulation with an operating model.
The challenge is that these objects are related but not interchangeable. A group organizes identities. An Azure RBAC role authorizes actions against Azure resources. A Microsoft Entra role authorizes administrative actions in the directory and related services. Privileged Identity Management can make certain privileged assignments eligible and time-bound. Access reviews help verify whether access is still justified.
Those distinctions matter for AZ-104 because administrators routinely work at the boundary between Azure resource management and Microsoft Entra identity. A technically correct role assignment can still be operationally weak if nobody owns it, reviews it, or knows why the user has it.
Groups scale access by representing membership, not privilege
A Microsoft Entra group can collect users, devices, service principals in supported scenarios, or other membership relationships depending on group type and configuration. Administrators can then assign applications, licenses, or access to the group rather than repeating the same action for every individual.
The benefit is not only convenience. Groups create an access-management boundary with an owner and a membership lifecycle. If the “Finance-Reporting-Readers” group receives access to an application or resource, the day-to-day question becomes who should belong to that group. That is easier to review than hundreds of unrelated direct assignments.
Group-based access works best when the group has one understandable purpose. A group that exists because “these thirty people all need various things” becomes hard to govern. A group tied to a role, project, application, or resource responsibility is easier to explain and audit.
Ownership is essential. If nobody can decide who belongs in the group, membership becomes permanent by default. Group owners, identity administrators, and business owners need a clear process for additions and removals.
Azure RBAC roles and Microsoft Entra roles govern different control planes
Azure RBAC answers questions about Azure resources: who can read, create, modify, delete, or perform service-specific actions at a management-group, subscription, resource-group, or resource scope. Microsoft Entra directory roles answer questions about identity and directory administration: who can manage users, groups, authentication methods, applications, or other Entra functions according to the role.
The difference is easiest to see with examples. A user can be Owner on an Azure subscription without automatically becoming Global Administrator in Microsoft Entra ID. Conversely, a directory administrator can have powerful identity-management rights without automatically receiving permission to change a virtual network or storage account.
That separation is healthy because the blast radius is different. Cloud infrastructure administration and identity administration are both sensitive, but they should not be bundled merely because the same portal exposes both.
Administrators pursuing deeper SC-300 skills spend more time on the Entra side of that boundary, while AZ-104 remains heavily concerned with Azure resource authorization and governance. Real environments need people who understand where the two meet.
Scope is as important as the role name
Azure RBAC assignments combine a security principal, a role definition, and a scope. A Reader assignment at one resource group is very different from Reader at the management-group level. Contributor on a single application resource group is very different from Contributor across the subscription.
This is where least privilege becomes practical. Before assigning a role, ask what tasks the person must perform and where they must perform them. Then choose the smallest built-in or custom role and the narrowest practical scope that supports those tasks.
Broad scope is sometimes justified. A central network team may need permissions across several subscriptions. A platform automation identity may require management-group deployment rights. But broad assignments should be deliberate because inheritance carries them downward to many resources.
Scope also affects reviews. A person may still need the role but no longer need it at the original scope. Removing an assignment entirely is not the only possible correction; narrowing it can be the right outcome.
Role-assignable groups can simplify privileged administration, but they raise the stakes
Microsoft Entra supports groups that can be assigned to certain directory roles. This can make role management more systematic because administrators govern membership in the group rather than maintaining many direct role assignments.
That convenience makes group membership highly sensitive. Adding someone to a role-assignable group can effectively grant a privileged directory role. Such groups therefore require stronger controls around ownership, membership changes, and the administrators who can modify them.
The broader lesson is that abstraction does not remove privilege. It moves the privilege boundary. When permissions are assigned to a group, the group becomes the object that must be protected.
That is familiar across identity and access management: governance has to follow the mechanism by which access is actually granted, whether that mechanism is a direct user assignment, group membership, eligible role activation, or workload identity.
PIM changes privileged access from permanent possession to controlled activation
Privileged Identity Management can make supported role assignments eligible rather than permanently active. An eligible user activates the role when needed, potentially with controls such as approval, multifactor authentication, justification, limited activation duration, or notification depending on the configuration and licensing.
This reduces the amount of standing privilege in the environment. A person who administers subscriptions occasionally does not necessarily need those permissions active every minute of every day.
PIM does not make privileged access low risk. An activated role is still powerful, and the underlying eligibility must still be justified. It does, however, improve the operating model by adding a lifecycle and evidence around activation.
Teams should distinguish eligible access from emergency access. Break-glass or emergency accounts have a different purpose and should be designed, monitored, and tested accordingly. PIM is for governed privileged workflows, not a substitute for every contingency.
Access reviews turn stale permissions into an explicit decision
Access reviews ask reviewers to confirm whether users still need access to a group, application, or supported privileged role. The power of the feature is not the review screen itself. It is the shift from “access continues unless someone remembers to remove it” to “access is periodically re-justified.”
Reviewers should be chosen based on who can make a meaningful decision. Group owners may understand project membership. Managers may understand whether employees still need access for their jobs. Privileged role administrators may be appropriate for sensitive administrative roles.
A review becomes weak if reviewers approve everyone without evidence. Useful reviews provide enough context to answer the question: sign-in or access activity where available, role or group purpose, user affiliation, and the consequence of removal.
Microsoft Entra access reviews can be recurring, which is especially useful for guest users, sensitive groups, and privileged roles where organizational change would otherwise accumulate stale access quickly.
Some access genuinely belongs to one person or one workload. A direct assignment can be clearer than creating a group with one member. Problems arise when direct assignments become the default for routine team access.
Hundreds of direct assignments scatter the access model across resources. A manager may know an employee changed teams, but there is no single group membership to update. Security teams may be able to report assignments but still struggle to identify which ones are intentional.
A useful pattern is to use groups for stable role-based access, direct assignments for true exceptions, and reviews for both. Exceptions should be documented because anything exceptional becomes hard to distinguish from forgotten access later.
The Microsoft Identity and Access Administrator role is fundamentally about making those access relationships manageable over time, not merely creating accounts and resetting passwords.
Lifecycle events should trigger access changes before periodic reviews do
Periodic reviews are a safety net, not the primary offboarding process. When someone leaves the organization, changes departments, finishes a project, or transfers responsibility, access should change as part of that event.
Group-based access helps because a small number of membership changes can remove several downstream permissions. HR-driven identity lifecycle automation can go further in mature environments. But even without full automation, the organization should define who receives the change signal and who removes or modifies access.
Contractors and guests deserve special attention because their access often has an explicit end date. An account can remain technically valid long after the business relationship has ended if nobody owns the lifecycle.
Guest access also tends to outlive the project context that justified it. A guest may still authenticate successfully even after the external collaboration is no longer active. Reviews that focus on guest membership, sensitive groups, and application assignments can surface those relationships before they become permanent background access.
Access reviews then catch what the event-driven process missed: stale group membership, unnecessary privilege, forgotten exceptions, and users whose responsibilities changed gradually rather than through a formal transfer.
An access report that says “Alice is Contributor” is incomplete. Administrators should be able to answer where, through what assignment path, and why.
The assignment may be inherited from a group at subscription scope. It may be direct at a resource group. It may be eligible through PIM. It may exist because the user temporarily supported a migration six months ago. Each story leads to a different governance decision.
Activity logs, Entra audit logs, role assignment data, PIM history, access review results, and group ownership records provide pieces of that evidence. The organization does not need a perfect identity graph to improve. It needs enough context that privileged access is explainable.
This is where AZ-500 security administration overlaps strongly with identity governance. Security depends not only on authentication controls but on knowing who can change resources and how that privilege is maintained.
Everyday identity administration is mostly about preventing access debt
Access debt accumulates when permissions are easy to grant and socially difficult to remove. Groups, RBAC, Entra roles, PIM, and access reviews provide different tools for controlling that debt.
The cleanest model uses groups where membership represents a stable responsibility, assigns roles at the narrowest useful scope, keeps high privilege eligible or time-bound where appropriate, and reviews sensitive access on a recurring schedule. Direct assignments remain exceptions rather than the default.
For an Azure Administrator, the important habit is to treat every access grant as a lifecycle object. It has an owner, a reason, a scope, a start point, and eventually an end point. The technical assignment is only the beginning.
When identity administration is designed that way, access reviews stop feeling like a periodic cleanup campaign. They become one layer in a system that already expects permissions to change as people, projects, and responsibilities change.