MS-102 Practice Question: Implement and manage Microsoft Entra identity and access

Answer analysis

Option-by-option breakdown

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

• ✓

  Decentralized identifiers (DIDs)

  Why this is correct

  Decentralized identifiers (DIDs) are the core of Microsoft Entra Verified ID: they are W3C-standard, globally unique identifiers generated from a public/private key pair and resolvable without a central registry. In Entra Verified ID, issuers and verifiers anchor DIDs to ION (Sidetree on Bitcoin) or use did:web, and the key holder uses the private key to sign Verifiable Credentials. This gives the user a self-owned, portable identity that cannot be revoked or controlled by a single IdP, which is exactly what Verified ID is designed to provide.

• ✗

  SAML 2.0

  Why it's wrong here

  SAML 2.0 is an XML-based single sign-on protocol in which a centralized identity provider authenticates the user and sends an assertion to the relying party. It assumes a pre-existing trust relationship between the IdP and service provider, and the user does not own or control the identifier. In a Verified ID architecture there is no broker IdP; the user's DID signs credentials directly, so SAML's assertion exchange model has no role in decentralized verification.

• ✗

  OAuth 2.0

  Why it's wrong here

  OAuth 2.0 is an authorization framework that issues access tokens to let a client call an API on behalf of a user; it does not define the user's identity or provide cryptographic, self-owned identifiers. Even though Entra Verified ID can use OpenID Connect-based protocols to request Verifiable Presentations, the credential itself is bound to a DID, not to an OAuth access token. Selecting OAuth would be confusing token delegation with the decentralized identity attestation that Verified ID performs.

• ✗

  Federation with Microsoft Entra ID

  Why it's wrong here

  Federation with Microsoft Entra ID centralizes trust by having a tenant-level IdP authenticate users and emit claims for partner organizations, usually via SAML or WS-Fed. That model relies on a pre-existing, organization-controlled identity authority, whereas Verified ID places the user, via their DID, at the center of the trust chain. A federated Microsoft Entra ID trust cannot provide the tamper-evident, user-held verifiable credentials that Verified ID issues, because the federation protocol doesn't involve DID-based signing or decentralized resolution.

Go deeper

Related to this question