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.

• ✗

  Linked Sign-on

  Why it's wrong here

  Linked Sign-on is not an authentication or federation protocol; it only adds a deep link to an application that already has its own identity provider or SSO system. In this mode, Microsoft Entra ID never processes an authentication request or issues a token, so users are redirected to the app's existing login page. This option is wrong because a custom line-of-business app that needs to trust Entra ID as the identity provider requires true federated SSO, not just a portal shortcut.

• ✓

  SAML-based Sign-on

  Why this is correct

  SAML-based Sign-on is correct because it enables true federated single sign-on between Microsoft Entra ID and a custom application that supports the SAML 2.0 standard. Entra ID acts as the identity provider, authenticates the user, and sends a digitally signed SAML assertion to the app's ACS (Assertion Consumer Service) URL, allowing the app to trust the assertion without prompting for credentials again. This is the recommended SSO method for non-gallery enterprise applications, especially older line-of-business apps that lack support for modern OAuth/OIDC protocols.

• ✗

  Password-based Sign-on

  Why it's wrong here

  Password-based Sign-on is a credential-vaulting fallback where an administrator stores each user's username and password in Entra ID and a browser extension replays those credentials into the app's login form. It does not create a federation trust or use token-based authentication, and it requires maintaining a copy of the user's password plus a browser extension on every device. This option is incorrect because a custom app that supports SAML should be integrated via SAML-based SSO to provide a single, secure authentication flow without storing passwords in the identity provider.

• ✗

  OpenID Connect-based Sign-on

  Why it's wrong here

  OpenID Connect is a modern authentication protocol built on OAuth 2.0 that exchanges signed JSON Web Tokens (JWTs) over HTTPS, but it is not the protocol being used when an application is presumably configured for SAML. Selecting OIDC would require the custom app to implement the OIDC authorization code-flow and return an ID token, which many legacy line-of-business applications do not support. While OIDC is a valid SSO mechanism in other contexts, this option is wrong because the correct integration method for this SAML-capable app is SAML-based Sign-on.

Go deeper

Related to this question