Azure identity administration requires clear boundaries between Microsoft Entra users, group membership, licensing, account recovery, and scoped Azure resource roles. This AZ-104 guide explores how administrators verify those boundaries using onboarding, external-user access, and self-service password-reset scenarios.<\/p>\n
The access-review examples use fictional employees, contractors and subscriptions so the distinctions can be tested without exposing a real directory or private records. Every role and SSPR outcome described below is a teaching scenario, not evidence that a Microsoft Entra tenant or Azure resource was modified. In practice, reproduce each decision with an authorized test identity before changing permissions in production.<\/p>\n
The AZ-104 Azure Administrator exam expects candidates to manage Microsoft Entra users and groups, guest users, licenses, self-service password reset, and Azure resource access. These duties are related, but they are not one permission system. A user may have permission to sign in to a directory without being able to read a storage blob; a person may manage a resource group but lack permission to change directory-wide authentication settings. The administrator’s responsibility is to establish which identity, role, scope and service actually controls an operation.<\/p>\n
Consider a company with two Azure subscriptions: engineering operates applications, finance reviews spending and external vendors need time-limited access to one project. Establish the employee groups, guest lifecycle and resource scopes before granting permissions. Azure Policy, RBAC and locks<\/a> affect different results: a role may permit an operation, policy may deny an unsupported resource configuration, and a lock may block deletion by an otherwise authorized operator. A vague request to make a user subscription Owner conceals which control actually denied the original action.<\/p>\n Microsoft Entra ID contains users and groups that represent people and administrative groupings, but the right grouping depends on responsibility. A team group used for notifications is not automatically a security group suitable for resource access. Record the group owner, eligibility rules, approval process and expiration\/review policy. An access request such as "the contractor needs Azure" is insufficient. Specify the target subscription or resource group, whether read or write is needed, and how long the assignment should persist.<\/p>\n Create and manage users using the organization’s approved onboarding process. For a new employee, verify identity and department before group assignment. For a transfer, inspect privileges inherited from the former team; simply adding the employee to the new group can leave stale access in place. For departure, disable or remove access, revoke sign-in sessions where appropriate and review credentials or owned service principals that might still be used by workloads. Don’t assume a deleted directory user automatically cleans up every operational secret or delegated application integration.<\/p>\n Different forms of group membership also change the automation story. Static group assignments are managed explicitly. Dynamic membership evaluates configured attributes, which means bad attribute hygiene can cause access changes the application team never intended. Verify available licensing and the group’s actual configured behavior rather than assuming every subscription supports identical dynamic membership features.<\/p>\n A Microsoft Entra license determines which directory features a user can access, while Azure RBAC controls particular resource operations. Neither replaces the other. Microsoft documents licensing prerequisites for self-service password reset and recommends group-based license planning in appropriate deployments. When you choose a directory feature, verify the license entitlement and administrative role requirements for that feature rather than borrowing an assumption from Azure subscription permissions.<\/p>\n For the fictional company, finance analysts might have a group that receives the correct directory licensing and a narrowly scoped Azure Cost Management role. An engineer might need access to an application’s resource group and a distinct identity feature assignment. A person can hold multiple responsibilities, but those should be consciously reviewed instead of bundled into a broad group called "all administrators". Track whether changes were applied and the time they took effect; a group membership or assignment visible in a portal is not proof every downstream token already reflects it.<\/p>\n Self-service password reset (SSPR) can let a user recover an account without requiring a help-desk operator to set the new password manually. That is an identity recovery process with security consequences, not merely a convenience checkbox. Define which population is enabled, which authentication methods are permitted, how registration happens, what help-desk fallback is allowed and how reset events reach audit or security monitoring. Microsoft’s Entra deployment guidance<\/a> describes prerequisites, licensing and the benefit of reviewing password-reset audit events.<\/p>\n For hybrid identity, distinguish a cloud-only SSPR reset from password writeback to on-premises Active Directory Domain Services. Microsoft lists Entra ID P1\/P2 or Microsoft 365 Business Premium for on-premises writeback, and the supported synchronization path still requires deliberate configuration and appropriate permissions. Don’t claim that enabling cloud-side SSPR automatically updates every on-premises directory or application. If the process fails, operators need to distinguish registration failure, unsupported authentication method, account restriction and a downstream synchronization issue before changing access controls.<\/p>\n A responsible SSPR rollout begins with a controlled group, communications and measurement. Test ordinary successful recovery, a user who lacks registered methods, an account with an expired sign-in session and suspicious repeated attempts. Ensure an emergency support path exists without allowing an unverified caller to take over an account through the help desk.<\/p>\n Guest access can be valuable for auditors and contractors, but it introduces a different lifecycle. Identify the sponsoring organization, the allowed project, accepted collaboration method and removal date. A guest may have a directory representation and be invited to a team while still lacking Azure resource access. Conversely, an overly broad Azure role assignment to a guest can grant more than the collaborative task requires. Treat the invitation and the Azure RBAC assignment as separate decisions.<\/p>\n Use group ownership and periodic review to answer practical questions. Who still needs the guest? Has the contract ended? Is the group nested or reused by an unexpected deployment? What happens if the guest’s external identity provider disables the account? Do not rely on a project completion email alone to remove Azure access. Record the review owner and what evidence demonstrates that access was actually rescinded.<\/p>\n Azure resource access follows the management-group, subscription, resource-group and individual-resource hierarchy. Role assignments can be inherited down that hierarchy, but inheritance does not mean a user automatically has the same privileges in unrelated subscriptions. Choose the built-in role that provides the operation actually needed and make the assignment at the narrowest maintainable scope. A monitoring operator may need to view metrics; a deployment automation principal may need to update only the resources in a target group.<\/p>\n If an operation fails unexpectedly, inspect the effective roles for the authenticated principal at the target scope, including assignments inherited from groups and parent resources. An Azure management role is not necessarily a data-plane role that permits reading a particular blob. Azure storage authentication<\/a> may use Microsoft Entra data roles, shared keys or restricted SAS credentials with distinct expiration and revocation behavior. Verify the failure using the intended workload identity; testing with a highly privileged administrator can hide the missing permission that the application actually needs.<\/p>\n A change that fails with an authorization error should not lead to granting Owner everywhere. Capture the exact denied operation, evaluated scope, role assignments and whether the actor signed in with the expected account. Check propagation and current tokens before asserting the directory or Azure RBAC is broken.<\/p>\n Use a synthetic environment with an engineering resource group, a read-only finance resource group and one contractor project. Create mock access records for three people: an employee who needs VM monitoring, a billing analyst who only reads costs and a guest who may read a single project’s documentation. First specify approved actions for each. Next map the group and role assignments that would achieve them. Include a false friend: a broad Contributor role might allow resource changes that a monitoring viewer should not perform.<\/p>\n Now simulate a department transfer for the employee. Remove the old access and add only the reviewed new assignments. Simulate an external guest’s engagement ending. Inspect whether revocation applies at both group membership and Azure resource scopes. For the billing analyst, verify that an assignment chosen for cost visibility does not unintentionally grant the ability to delete a virtual machine.<\/p>\n A negative test should try a data-plane operation not covered by the assigned resource role. Record whether it is denied and which control evaluated it. Test SSPR with an appropriately licensed fictitious user and a fictitious user who lacks enrollment, without any real password-changing action. These are test designs until executed against an authorized tenant.<\/p>\n The assessment skill is operational judgment: given a requested action, identify the principal, license-feature boundary, role type, Azure scope, inherited groups and current effective permissions. Explain whether the corrective action is to change Entra membership, enable supported self-service recovery, assign a narrower resource role, fix a storage data role or remove stale privileges. Demonstrate how to verify the result without giving broad access merely to make an error message disappear.<\/p>\n An identity-and-governance decision should be reproducible: record the actor, directory group, Azure role, assignment scope, approver and review date, then test with the same principal rather than an unrestricted administrator account. A user may sign in successfully but lack the resource data role needed to read a blob; a manager may approve access without possessing permission to change group membership. Compare those outcomes in third-party AZ-104 identity practice<\/a> scenarios and explain which Entra or Azure RBAC control applies, how SSPR changes authentication recovery, and which authorization denial must remain in force. The result is useful evidence for an actual access review, not merely an answer to a multiple-choice question.<\/p>\n","protected":false},"excerpt":{"rendered":" Manage Entra users and groups, SSPR, guest access and Azure RBAC scopes for the current AZ-104 administration objectives.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[124,29,30,47],"tags":[],"class_list":["post-4071","post","type-post","status-publish","format-standard","hentry","category-exam-az-104","category-certifications","category-cloud-computing","category-microsoft-certifications"],"_links":{"self":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/4071","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/comments?post=4071"}],"version-history":[{"count":6,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/4071\/revisions"}],"predecessor-version":[{"id":4601,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/4071\/revisions\/4601"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/media?parent=4071"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/categories?post=4071"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/tags?post=4071"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Organize people before assigning cloud permissions<\/h2>\n
Licensing is a feature boundary, not an Azure role<\/h2>\n
SSPR is a recovery workflow with an audit trail<\/h2>\n
External users need narrower expectations<\/h2>\n
Grant Azure RBAC at the smallest useful scope<\/h2>\n
A worked onboarding and offboarding drill<\/h2>\n
What a reliable AZ-104 identity administrator can explain<\/h2>\n