AZ-104: Microsoft Entra ID Administration

The current AZ-104 objectives require administrators to create and manage Microsoft Entra users and groups, manage user and group properties, assign licenses, work with external users, and configure self-service password reset. Those tasks are foundational because every later Azure role assignment depends on a usable identity. The AZ-104 exam tests this as practical administration rather than as a generic identity-security survey.

Microsoft renamed Azure Active Directory to Microsoft Entra ID, a change summarized in the existing Microsoft Entra ID naming update. For exam preparation, use the current name and keep the scope precise: AZ-104 is concerned with administering the identities that participate in Azure operations, then connecting them to Azure resource access through RBAC.

Create users and groups with lifecycle in mind

Creating an identity is easy; maintaining it correctly is the administrative challenge. User properties affect sign-in, communication, licensing, and downstream automation. Group design determines whether access can be managed centrally or must be edited repeatedly for individuals. Before creating objects, decide whether the identity is internal or external, whether membership should be assigned manually or by another process, and which attributes other systems depend on.

Groups are especially valuable for Azure administration because a role can be assigned to a group rather than to each user. The identity team can then manage membership while the Azure role assignment remains stable. This separates two responsibilities and reduces the chance that old permissions remain after a person changes jobs.

Naming and ownership matter operationally as well. A group with no clear purpose or owner becomes difficult to review. The exam may not ask for a naming standard, but understanding why group-based administration is preferable helps with least-administrative-effort scenarios.

Manage properties and licenses without confusing them with Azure roles

Microsoft Entra properties describe the identity; Azure roles describe what that identity can do to Azure resources. A license enables access to Microsoft services or features and is not the same thing as a role assignment. Similarly, changing a department or job title does not automatically change Azure permissions unless group membership or an access process uses that property.

When a scenario asks you to enable a product entitlement, think licensing. When it asks who can start, stop, read, or modify an Azure resource, think RBAC. When it asks which users belong to an administrative population, think groups and membership. Solving the control plane first prevents many common distractors.

License management also has operational consequences. Removing a user does not mean every dependent service behaves identically, and a licensing change should be planned around the user lifecycle rather than treated as a cosmetic attribute update.

Handle external users as a separate identity relationship

External collaboration allows people outside the organization to participate without turning them into ordinary internal employees. The administrator still needs to control the guest identity lifecycle, group membership, and Azure access. The fact that an external user authenticates with another organization does not imply that the user should receive broad permissions in your tenant.

For exam scenarios, focus on the least change required. If a partner needs temporary read access to one resource group, inviting an external user and assigning a narrow role may be more appropriate than creating a new internal account or sharing credentials. The exact access requirement still belongs to Azure RBAC after the guest identity exists.

Offboarding is just as important as onboarding. External relationships can outlast projects, so groups and role assignments should make removal understandable and auditable.

Configure self-service password reset as an availability control

Self-service password reset reduces help-desk dependency and gives users a controlled recovery path. From an administrative perspective, the important questions are who is enabled, what registration or verification experience applies, and how the feature fits the organization’s identity process. It is an identity-operations capability, not an Azure resource permission.

A scenario involving a user who cannot access a virtual machine because of an Azure role should not be solved with SSPR unless the actual problem is authentication. Conversely, a user who has the correct role but cannot sign in may have an identity or credential problem. Separate authentication failure from authorization failure before changing access.

That distinction is one of the most useful troubleshooting habits for AZ-104: first prove the identity can authenticate, then evaluate whether it is authorized at the intended Azure scope.

Use groups to simplify Azure access

After identities are created, groups often become the bridge to Azure RBAC. Assigning a built-in Azure role to a group can make access changes safer because administrators modify group membership instead of creating many individual role assignments. This design also makes reviews easier: the role describes what the group can do, while the group describes who currently receives that capability.

Avoid using one giant administrative group for unrelated responsibilities. Storage operators, network operators, and readers may need different built-in roles and different scopes. Group design should follow operational responsibility closely enough that membership has a clear meaning.

If a user unexpectedly has access, inspect nested membership and inherited assignments rather than assuming the visible direct assignment is the whole story.

Keep Conditional Access in the right exam context

Conditional Access is an important Microsoft Entra security capability, but the current AZ-104 identity objective specifically lists users, groups, licenses, external users, and SSPR, while Azure resource authorization is covered through built-in roles and role assignments. That means you should understand Conditional Access as surrounding identity-security context without replacing the blueprint items with a broader identity exam syllabus.

This distinction matters when choosing study depth. Spend the most time on the tasks Microsoft explicitly measures, then understand adjacent Entra controls well enough not to confuse authentication policy with Azure resource authorization. A Conditional Access policy can affect whether a sign-in is permitted; it is not the mechanism that grants Contributor on a resource group.

The same discipline prevents overstudying advanced identity topics that belong more naturally to dedicated security and identity certifications.

Troubleshoot sign-in and access in the correct order

When a user reports “I cannot access Azure,” break the statement down. Can the user sign in? Is the account enabled? Is the user or group correctly represented in the tenant? Is the expected license relevant to the task? Is the user a member of the group that receives the Azure role? At what scope is the role assigned? Each question tests a different layer.

Do not fix uncertainty by granting a broader role. First inspect the effective assignment and group membership. Overprivileging may make the symptom disappear while creating a security problem and hiding the original configuration mistake.

The Microsoft certifications contains certifications that go much deeper into identity security, but AZ-104 rewards an administrator who can keep tenant identity tasks and Azure resource access cleanly separated.

Practice with lifecycle scenarios

Create practice cases for a new employee, a contractor, a partner guest, a user changing departments, and a departing administrator. For each person, decide which identity object changes, which group memberships change, and whether any Azure role assignment needs to be edited directly. This makes the relationship between Entra administration and Azure RBAC concrete.

Then add failures: the user can sign in but cannot modify a resource, the user cannot complete password recovery, the partner is in the tenant but has no Azure permissions, or a former team member still has access through a group. Solving these cases builds exactly the layered reasoning AZ-104 scenarios demand.

Plan bulk administration and repeatable identity changes

Administrative efficiency matters when the tenant contains many users and groups. Repetitive portal edits are difficult to review and easy to perform inconsistently, so administrators should be comfortable with repeatable methods such as PowerShell, Microsoft Graph tooling, or other supported automation when the task calls for bulk changes. AZ-104 does not require memorizing every command, but it does expect familiarity with administrative tooling and with the idea that large-scale changes should be controlled and reproducible.

Bulk work should still respect the same lifecycle rules as one-off changes. Before adding hundreds of users to a group, confirm the group’s access meaning. Before assigning licenses in bulk, confirm the intended population and whether exceptions exist. Automation magnifies mistakes as efficiently as it performs correct work, so validate the input set and test a small sample when the consequence is broad.

A useful exam clue is “least administrative effort.” Group-based assignments and repeatable automation can satisfy that requirement while preserving clear ownership. The easiest click path for one user is not always the best administrative design for an organization.

Keep identity recovery separate from resource recovery

Self-service password reset is about restoring a user’s ability to authenticate. It does not restore deleted Azure resources, repair a network path, or grant permissions. This sounds obvious, but scenario questions often place several failures close together and rely on the candidate to identify which layer is actually broken.

If a user can authenticate but receives an authorization error on a storage account, inspect Azure roles and scope. If a user cannot sign in after forgetting a password, investigate identity recovery. If the user can sign in and has the role but cannot reach a private endpoint, investigate networking. Keeping those boundaries explicit prevents broad and risky “fixes” that change the wrong control.

Practice by labeling each incident as authentication, authorization, licensing, membership, or network reachability before choosing an Azure action. The classification step is usually more valuable than memorizing a portal sequence.