An Azure administrator can manage an entire subscription yet be unable to create a Microsoft Entra user. Conversely, a directory administrator can create an account yet lack permission to deploy a virtual machine. Azure identity tasks and Azure resource access are governed by different roles and scopes. This distinction sits at the center of the current Microsoft AZ-104<\/a> identity-and-governance domain.<\/p>\n Consider onboarding a contractor who must read one resource group for two months. The company also wants to manage permanent employees’ group membership, license assignments, and password recovery. Document the tenant, user type, relevant group, license entitlement, directory role, Azure role, and exact resource scope before clicking the portal. None of those items automatically implies the others.<\/p>\n The AZ-104 objectives<\/a> specifically include users, groups, licenses, external accounts, self-service password reset, Azure roles, and governance. A convincing lab should include both allowed and denied outcomes and identify which authorization layer caused each result.<\/p>\n Create a small directory administration plan rather than several unrelated sample accounts. Define identity source, naming rules, ownership, intended lifespan, membership approval, and offboarding. Cloud-only accounts and synchronized identities may have different authoritative fields. If a hybrid property’s source is on-premises, editing the cloud-facing representation may not be the supported long-term way to change it.<\/p>\n A security group can receive a scoped Azure role so new team members gain only the intended resources. A Microsoft 365 group can serve collaboration needs but is not a universal replacement for each authorization requirement. Dynamic membership and group-based licensing have additional availability and entitlement considerations. Confirm group type, permitted licensing, and resulting assignments rather than relying on similar-looking names.<\/p>\n Offboarding is a useful failure test. Remove a guest from the authorized group, review direct role assignments, check application access, and understand potential token-cache or membership-propagation delays. Record actual timing instead of asserting an instant outcome on every connected service. Preserving an audit record may be more appropriate than deleting the entire directory object.<\/p>\n Entra licensing enables supported identity capabilities, while resource access determines permitted actions against Azure infrastructure. A licensed user may still have no subscription permissions. A contributor to a resource group does not automatically have the Entra role to administer account licenses. Model the two as separate checks in the onboarding spreadsheet.<\/p>\n Test both direct and group-based license assignment in a tenant that actually supports the intended feature. Review enabled service plans, conflicting entitlements, capacity and assignment results. A successful assignment message is evidence that a licensing operation occurred; it does not prove a subsequent application sign-in or Azure resource operation will succeed.<\/p>\n When a feature is unavailable, inspect the current entitlement and API\/product prerequisites before assigning a more privileged directory role. Extra permission cannot substitute for unsupported licensing, just as buying a license cannot repair a missing role assignment. This separation makes troubleshooting safer and faster.<\/p>\n A B2B guest invitation is a collaboration mechanism, not blanket trust. Define who can invite people, relevant cross-tenant policies, acceptable partner organizations, invitation redemption, and the access duration. Create a controlled guest test using no real customer data. An invited identity may appear in the directory before it has accepted the invitation or received any resource access.<\/p>\n After redemption, distinguish sign-in from authorization. A guest might authenticate correctly but be denied by Azure RBAC or a data-plane permission; a different guest might fail a cross-tenant restriction before any resource request is evaluated. Inspect the actual failure stage, tenant selection, relevant logs, group membership, and role assignment scope.<\/p>\n An offboarding test should remove intended collaboration access without inventing a global security guarantee. Check membership, direct role assignments, application shares, and residual approval state. A contractor who no longer needs a project should not retain subscription-wide privileges merely because an earlier administrator used the wrong scope.<\/p>\n Self-service password reset is a recovery workflow that depends on population scope, supported authentication methods, registration and policy configuration. Hybrid synchronized identities may additionally require supported password writeback. Define what the lab is meant to prove for a cloud-only user and avoid assuming a reset automatically propagates into an unrelated on-premises environment.<\/p>\n Use one registered test account and a second lacking required methods. Capture the successful sequence for the first and the supported recovery or administrative process for the second. Separate security-information registration, self-service reset, and help-desk reset: each has a different authentication and audit context.<\/p>\n A user who lost a phone still needs identity proofing before an authenticator is replaced. Do not relax verification merely to make the demo work. Evaluate whether legitimate recovery is possible without letting an attacker register a new factor for somebody else’s account.<\/p>\n An Azure RBAC assignment<\/a> combines the principal, role definition and scope. Test it with a support group that should read one resource group without modifying a sibling group or granting itself a more privileged role. Because assignments can be inherited, inspect the management-group and subscription ancestors before concluding that a resource group’s local role list explains effective access.<\/p>\nTreat user and group administration as a lifecycle<\/h2>\n
Distinguish licenses from permissions<\/h2>\n
Invite external users under explicit collaboration policy<\/h2>\n
Configure SSPR with safe recovery assumptions<\/h2>\n
Connect directory identity to resource and workload authorization<\/h2>\n