MS-102 Deploy and manage a Microsoft 365 tenant Practice Question
You are the Microsoft 365 administrator for a company with a hybrid identity configuration using Microsoft Entra Connect. The company has a custom domain 'contoso.com' federated with Active Directory Federation Services (ADFS). All users are synced from on-premises Active Directory. The security team wants to implement Microsoft Entra ID Protection to detect risky sign-ins. However, they are concerned that federated authentication bypasses some risk detection capabilities. You need to ensure that Microsoft Entra ID Protection can evaluate risk for all sign-ins, including federated ones. What should you do?
⚠ Common exam trap
Many candidates think adding claims (Option C) or changing the trust configuration (Option B) can compensate for the architectural limitation, but only moving the authentication flow to Microsoft Entra ID (Option A) gives Entra ID Protection the raw sign-in data it needs for real-time risk evaluation.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Switch from federated authentication to Pass-through Authentication (PTA) or Password Hash Sync (PHS).
Microsoft Entra ID Protection relies on signals such as IP addresses, device information, and sign-in patterns to calculate risk. In a federated setup with ADFS, the authentication happens on-premises, and Microsoft Entra ID only receives a token—not the raw sign-in details needed for real-time risk evaluation. Switching to Pass-through Authentication (PTA) or Password Hash Sync (PHS) ensures that the authentication process flows through Microsoft Entra ID directly, allowing Entra ID Protection to capture and analyze all sign-in events, including those from federated users.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Switch from federated authentication to Pass-through Authentication (PTA) or Password Hash Sync (PHS).
Why this is correct
With federated authentication, Microsoft Entra ID redirects authentication to ADFS, so Microsoft Entra ID never performs or observes the actual password validation and cannot compute sign-in risk for that exchange. Switching to Pass-through Authentication (PTA) or Password Hash Sync (PHS) makes Microsoft Entra ID the authentication authority: PTA validates against on-prem AD through an agent, while PHS validates against synced hashes. Because the token is issued by Microsoft Entra ID after credential verification, Identity Protection can evaluate risk before the user receives access.
- ✗
Configure the federated trust in Microsoft Entra ID to use the new claims.
Why it's wrong here
Editing the claims used in the federated trust — for example, adjusting the Issuer, signing certificate, or name ID format — only alters the trust metadata and token format. The actual password check is still performed by ADFS on-premises, and Microsoft Entra ID continues to accept the resulting token without having seen the credential verification. Thus the authentication flow remains unchanged and Identity Protection still lacks the pre-authentication telemetry it needs.
- ✗
Configure ADFS to send the ipaddr and xms_ep claims to Microsoft Entra ID.
Why it's wrong here
Configuring ADFS to emit the ipaddr and xms_ep claims to Microsoft Entra ID simply attaches the user's IP address and endpoint metadata to the token after a successful on-premises login. These claims are post-authentication artifacts and do not expose the credential validation event to Microsoft Entra ID; they also do not replicate the rich signal feed Identity Protection requires (such as leaked credentials or brute-force attempts). Since the initial password check still happens at ADFS, the risk evaluation is not enabled.
- ✗
Enable Microsoft Entra application proxy to publish ADFS internally.
Why it's wrong here
Microsoft Entra application proxy is a reverse proxy that publishes on-premises web apps to external users through Microsoft Entra ID; it does not alter the authentication flow for the primary directory sign-in. Even if ADFS is behind Application Proxy, users still authenticate at the on-premises ADFS endpoint (or via an intermediate page) and Microsoft Entra ID still receives an already-issued token. Therefore, enabling Application Proxy has no effect on where credentials are validated and does not move the risky authentication inside Microsoft Entra ID.
Go deeper
Related to this question
Learn chapter
Exchange Mobile Device Policies (OWA)
Key term
Security
Security in IT is the practice of protecting systems, networks, and data from unauthorized access, damage, or theft.
Key term
Risk
Risk is the possibility that an event or action will negatively affect an organization's ability to achieve its goals, often measured in terms of likelihood and impact.
About these practice questions
One of 712 original MS-102 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This MS-102 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the MS-102 exam.