A Microsoft Entra tenant can contain thousands of users, groups, devices, applications, and administrators. The difficult part is not creating those objects. It is understanding what each object changes and, just as importantly, what it does not change. A user object gives the directory an identity to authenticate and manage. A group lets administrators treat multiple identities as a set. An administrative unit narrows the scope of certain directory-management roles. Those mechanisms interact, but they are not interchangeable.
For AZ-104, this distinction matters because an Azure administrator is often asked to delegate work without accidentally delegating the whole tenant. The clean mental model is to separate identity, membership, authorization, and administrative scope before deciding which object should carry the design.
Users are identities, but the user object is only one part of access
A Microsoft Entra user object represents a person or, in some cases, an account used for a specific administrative or operational purpose. The object carries properties such as sign-in identity, group memberships, authentication methods, licensing relationships, and directory attributes. Those properties become inputs to other systems, but the existence of the user alone does not grant access to every Azure resource.
Azure resource access is commonly granted through role assignments, application access can be granted through enterprise-application configuration or groups, and conditional access can apply separate sign-in requirements. The user object is therefore the identity anchor rather than a universal permission list.
This broader identity model becomes clearer through identity and access management with Microsoft Entra ID. The important operational lesson is that disabling, deleting, restoring, or changing a user can have consequences across every system that trusts that identity.
Groups are a scaling mechanism for membership and authorization
Groups let administrators assign access or configuration to a collection instead of managing every user individually. That is valuable because individual role assignments are hard to review and easy to leave behind when people change jobs. A well-named group can represent a business role, project team, licensing population, application-access set, or administrative function.
The design still needs discipline. Nested groups, dynamic membership, synchronized on-premises groups, and application-specific groups can make effective access difficult to understand. A user may receive permission through several paths, and removing one assignment may not remove the access if another group still grants it.
Group ownership is also a control. If business owners can add members, the organization should know what access that membership implies. If IT is the only owner, the group may become operationally stale because the people closest to the business change cannot maintain it. Periodic membership review is therefore as important as initial creation.
Administrative units scope administration, not ordinary resource access
Administrative units solve a different problem. They allow an organization to scope supported Microsoft Entra directory roles to a defined portion of the directory. A global company can, for example, delegate user administration for one region without giving the regional help desk the same role over the entire tenant.
The subtle point is that an administrative unit is not simply another security group. It is a container used to scope management. Microsoft currently allows administrative units to contain users, groups, or devices. If a group is added to an administrative unit, the group object falls within that administrative scope, but the group’s members do not automatically become members of the administrative unit. If administrators must manage the individual users as well, those users need to be in the appropriate administrative scope.
This distinction prevents a common design error: using group membership to imply an administrative-unit boundary that the platform does not actually create.
Administrative scope is not the same as an isolation boundary
Another common mistake is assuming that a scoped directory administrator cannot see anything outside the administrative unit. Administrative units primarily restrict the reach of supported role permissions. They do not automatically turn the rest of the tenant invisible, and they do not replace resource-level authorization for Azure subscriptions, applications, or data.
That means a regional help-desk administrator might be permitted to reset passwords for users inside the unit while still being able to browse some directory information outside it through normal user capabilities. If the organization requires stronger separation for especially sensitive identities, the design should evaluate the platform’s restricted-management options and other compensating controls rather than assuming a normal administrative unit provides complete isolation.
The correct question is always: which operation is being delegated, over which object, through which role, and at what scope?
Directory roles and Azure RBAC belong to different authorization planes
Microsoft Entra directory roles govern directory and identity administration. Azure role-based access control governs actions on Azure resources such as subscriptions, resource groups, virtual machines, storage accounts, and other Resource Manager resources. A person can have broad rights in one plane and limited rights in the other.
This is why a User Administrator does not automatically become an Azure subscription Owner, and an Azure Contributor does not automatically gain permission to reset users’ authentication methods. The two systems can use the same identity while authorizing different operations.
Azure role-based access control provides the resource side of that distinction. Candidates moving deeper into identity administration may also encounter SC-300, where Microsoft Entra identity and access responsibilities are central.
Dynamic membership reduces manual work but increases rule dependency
Dynamic groups and dynamic administrative-unit membership can reduce repetitive administration when membership can be derived from reliable attributes. A region, department, device property, or other directory attribute can drive membership without requiring a help-desk ticket for every change.
The trade-off is that the rule becomes a security dependency. If source attributes are inaccurate, delayed, or inconsistently populated, authorization can drift. A user transferred between departments may retain old access until attributes and group evaluation catch up. A badly written rule can expand membership far beyond the intended population.
Teams should therefore treat dynamic rules like production logic: document the source attributes, test edge cases, monitor unexpected membership changes, and understand how quickly membership recalculates after a source change.
Lifecycle events are where identity designs prove themselves
Joiner, mover, and leaver events expose whether users, groups, and administrative scope are designed coherently. A new employee should receive only the memberships required for the role. A transfer should remove obsolete access instead of merely adding new groups. A departure should disable sign-in, revoke relevant sessions, transfer ownership where needed, and remove access through groups and resource roles.
Group-based access helps when group membership is authoritative and reviewed. Administrative units help when delegated administrators need a constrained management area. Neither replaces a lifecycle process. If the source system does not signal changes reliably, stale access accumulates regardless of how clean the directory structure looks.
The organization should be able to answer who owns each important group, why a member belongs, who can change membership, and how quickly departures propagate to downstream applications and Azure resources.
A regional help-desk scenario exposes the differences quickly
Imagine a company with support teams in North America, Europe, and Asia. The European help desk should reset passwords and manage selected group memberships for European employees, but it should not have the same directory authority over executives or staff in other regions. A normal Microsoft Entra group can collect the European employees, but group membership alone does not scope a directory role. An administrative unit can provide that management scope when the supported role and objects fit the scenario.
The design becomes more subtle if the administrative unit contains a group. The regional administrator may be able to manage that group object and its membership, yet that does not automatically grant the administrator user-management rights over every person inside the group. If password reset or authentication-method management is required for those users, the users themselves need to fall within the appropriate administrative scope. This is a small platform detail with a large operational consequence.
Now add an Azure subscription used by the same regional team. The administrative unit still does not grant management rights to virtual machines or storage accounts. Those permissions belong to Azure RBAC. The same person might therefore have a scoped directory role over European users and a separate Azure role over a resource group. Keeping those assignments separate makes both least privilege and investigation easier.
Licensing and feature support can also constrain the design, so administrators should verify requirements before standardizing on administrative units as the delegation model. Architecture should be based on supported behavior, not merely on the visual similarity between a group and a directory container.
Design the directory so effective access can be explained
A strong directory design is understandable under investigation. Administrators should be able to trace why a user can perform an action: direct assignment, group membership, directory role, Azure role assignment, application role, or another explicit path. Administrative units should make delegated responsibilities narrower, not make the model harder to reason about.
Within the Microsoft Certified: Azure Administrator Associate path, Entra users and groups are not introductory trivia. They are the identities and collections on which Azure administration depends. Administrative units add a second dimension—who may administer which directory objects. Keeping identity, membership, resource authorization, and administrative scope separate in the mental model makes the platform’s behavior much easier to predict.
Object naming and documentation also affect operational clarity. A group called “Project-Blue-Users” tells a reviewer less than a group name that indicates the application, permission level, environment, and owning team. Administrative units should likewise reflect a delegation model people can recognize. Clean naming does not create security by itself, but it reduces the chance that administrators add members to the wrong collection or retain obsolete structures because nobody understands what they were for. In a large tenant, understandable structure is a control against administrative error.
