MS-102 Deploy and manage a Microsoft 365 tenant Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Create a new enterprise application from the 'Non-gallery application' option in Azure AD

  Why this is correct

  In Azure AD, when a third-party SaaS application supports SAML 2.0 but is not pre-configured in the gallery, the correct first administrative action is to select "Create a new application" and choose "Non-gallery application" from the Azure AD Enterprise applications blade. This action provisions a dedicated service principal in your tenant that accepts SAML requests and provides the Azure AD identifier, reply URL, and certificate required to complete SAML SSO configuration on the SaaS vendor's side. This templates the identity provider relationship before you can assign users or test SSO.

• ✗

  Configure Azure AD Connect to sync on-premises users

  Why it's wrong here

  Azure AD Connect is an identity synchronization tool that replicates on-premises Active Directory objects—users, groups, and password hashes—into Azure AD. It does not create or register an enterprise application, nor does it establish the SAML trust between Azure AD and an external SaaS provider. While syncing users may eventually be necessary if those users need access, the initial step for integrating any SAML application is always to create the corresponding enterprise application in Azure AD, not to alter the sync topology.

• ✗

  Add the application in the Microsoft 365 admin center under 'Integrated apps'

  Why it's wrong here

  The Microsoft 365 admin center's "Integrated apps" section is designed for managing Office 365 add-ins, Teams apps, and app permissions within the Microsoft 365 ecosystem, not for configuring enterprise SAML federation. A third-party SAML SaaS app must be registered in the Azure AD Enterprise applications console, because that is where the SAML endpoints, signing certificate, and user assignment are stored and managed. Using the admin center will only handle OAuth or delegated permissions scenarios, and it will not create the required service principal for SAML SSO.

• ✗

  Create a custom role in Azure AD for the application

  Why it's wrong here

  Custom roles in Azure AD are administrative role definitions that grant delegated permissions to manage directory resources; they determine what a user can administer, not how the application authenticates. Creating a custom role for a specific application is unrelated to SAML SSO configuration and is only necessary if you want to delegate admin access to that app's management to other administrators. Even then, you would create the enterprise application first, then optionally build a role around managing it.

Go deeper

Related to this question