AZ-305 Practice Question: Design identity, governance, and monitoring solutions

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Federation with the partner's IdP

  Why it's wrong here

  Federation with the partner's IdP is a trust relationship established between your Microsoft Entra tenant and an external organization's identity provider, enabling single sign-on for users from that specific partner domain. It is not designed for transient or individual external users such as freelancers, contractors, or customers who may not belong to a pre-established partner organization, because it requires a formal federation configuration (e.g., SAML or WS-Fed metadata exchange) for each partner. Moreover, it creates a domain-level trust rather than an identity-level invitation, making it unwieldy and insecure for scenarios where you need to grant access to many different external users from various IdPs. Federation with a partner IdP is therefore a valid approach for B2B partnerships but not as a general-purpose solution for bringing any external user's own identity.

• ✓

  Microsoft Entra External ID

  Why this is correct

  Microsoft Entra External ID is the correct approach because it includes B2B collaboration, which allows external users to sign in using their own identities—whether that be a Microsoft account, a Google account, a Facebook account, or any SAML/WS-Fed identity provider—without creating a separate local account in your tenant. It provides self-service sign-up, conditional access policies, and lifecycle management such as just-in-time access and access reviews, making it ideal for large enterprises that need to collaborate with a broad range of external partners, vendors, and customers. External ID also supports cross-tenant access settings for trusted MFA and device compliance from partner tenants, so the user's own identity provider is the authority for authentication while your tenant controls access policies. This is the only option that directly enables external users to bring their own identities without requiring federation prior to the invitation.

• ✗

  Passwordless authentication

  Why it's wrong here

  Passwordless authentication refers to authentication methods like Windows Hello for Business, FIDO2 security keys, and Microsoft Authenticator that replace passwords for users who already exist in your identity directory. It does not solve the core requirement of allowing external users to bring their own identity provider because it is an authentication mechanism, not an identity source or trust mechanism. Even if you enabled passwordless methods, your external users would still need to be represented in your tenant—either as guest users or through synchronization—and the passwordless methods would only be usable if the external user's own IdP supports them, which is not guaranteed. Furthermore, passwordless authentication is primarily designed for your organization's own users and gives no way for external partners or customers to leverage their existing corporate or social credentials.

• ✗

  Identity synchronization

  Why it's wrong here

  Identity synchronization, typically implemented with Microsoft Entra Connect, is used to synchronize user objects from an on-premises Active Directory or other directories into Microsoft Entra ID, creating duplicate accounts for internal users in the cloud. If applied to external users, it would require establishing directory synchronization with each partner organization's directory, which is impractical, creates duplicate identities that need to be maintained and mapped, and fundamentally does not allow external users to use their own IdP—instead, it copies their identity into your tenant. Synchronization also raises significant privacy and corruption-of-authority issues because the partner's IdP would no longer be the single source of truth for that identity, and password credential changes or account lockouts would not propagate in real time. The correct approach is to leave external identities in their own IdP and simply grant access through Entra External ID, which avoids duplication and maintains the external identity lifecycle.

Go deeper

Related to this question