A Microsoft Sentinel analytics rule needs to detect when Azure OpenAI API calls are made using tokens from accounts that are simultaneously flagged as risky in Microsoft Entra ID Protection. Which Sentinel feature enables correlation across these two data sources?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — b is correct because Microsoft Sentinel allows joining multiple log tables in a single scheduled analytics rule using KQL join operators. The AADRiskyUsers or AADUserRiskEvents tables (from the Entra ID data connector) contain risk-flagged users, and AzureDiagnostics contains Azure OpenAI API calls.
Full explanation below image
Full Explanation
B is correct because Microsoft Sentinel allows joining multiple log tables in a single scheduled analytics rule using KQL join operators. The AADRiskyUsers or AADUserRiskEvents tables (from the Entra ID data connector) contain risk-flagged users, and AzureDiagnostics contains Azure OpenAI API calls. A KQL query can join these tables on the user identity field to detect when a currently risky user is making Azure OpenAI API calls, creating a correlated detection. A is wrong because separate analytics rules generate separate alerts and workbooks provide visualization, not correlated detection logic across data sources. C is wrong because Fusion rules use machine learning to detect multi-stage attacks by correlating specific alert types from Microsoft products; they cannot be configured with custom join logic across arbitrary tables. D is wrong because using a watchlist is a valid approach but is static—it requires manual maintenance of the risky user list, whereas joining against AADRiskyUsers provides real-time risk signal from Entra ID Protection.