A city SOC builds Microsoft Sentinel analytics for impossible travel on Entra IDs used by remote inspectors. What monitoring practice is that?
Select an answer to reveal the explanation.
Short Explanation
Remote inspectors bouncing continents in an hour is a Sentinel job—write the impossible-travel analytics on their Entra IDs. Using Conditional Access to alert on impossible travel is enforcement, not the Sentinel detection you're after. Put the rule in the workspace.
Full Explanation
Building Microsoft Sentinel analytics for impossible travel on Entra IDs used by remote inspectors is municipal identity-threat monitoring. Impossible travel detections flag sign-ins that appear from geographically distant locations in timeframes that are physically implausible, a common signal for credential theft or token replay against field staff accounts. Authoring and deploying these analytics in Sentinel—fed by Entra ID sign-in logs and customized for municipal patterns (inspector baseline travel times, scheduled leave, normal work hours)—gives the city SOC a repeatable detection that is tuned to the organization's risk rather than a generic template.
Configuring Entra ID Conditional Access policies to alert on impossible travel on Entra IDs is access enforcement in Entra ID, not the Sentinel detection-authoring practice described; it controls access at sign-in time but does not author Sentinel analytics that monitor for geographically impossible sign-ins. Tuning Sentinel UEBA entity profiles to baseline impossible travel on Entra IDs for inspectors is supporting behavioral context, not authoring impossible-travel analytics; UEBA baselines normal inspector sign-in behavior to enrich detections, it does not itself create the geographically impossible sign-in detection rule the question describes. Building Sentinel workbooks to visualize impossible travel on Entra IDs for inspectors over time is a reporting and visualization task, not detection authoring; workbooks display query results but do not generate the impossible-travel alerts that constitute the monitoring practice in question. Purpose-built municipal detections, authored once and reused, are more reliable and audit-friendly than manually re-investigating every alert.
Exam caveat: Impossible travel baselines must account for time zones, seasonal staff rotations, and inspector commute patterns. Detections tuned to the wrong baseline waste analyst time.
Operational check: Identify inspector user accounts that legitimately work across regions; extract their sign-in locations and time deltas; create a tuned impossible-travel rule scoped to those patterns; run retro for 30 days to confirm it detects the target scenario without false positives; and document the geofence radius and time threshold that make sense for civic use.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.