A security engineer builds a Microsoft Sentinel analytics rule that queries AzureDiagnostics for Azure OpenAI API calls and joins with SigninLogs to identify cases where a user accesses Azure OpenAI within 5 minutes of a suspicious sign-in. The KQL query has performance issues with high query times. Which KQL optimization should be applied first?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — b is correct because the most impactful KQL performance optimization for join queries across large tables is filtering each table to the relevant time range before performing the join. Using the 'ago()' function to filter AzureDiagnostics and SigninLogs to only the lookback window (e.g., last 24 hours) dramatically reduces the data volume that must be processed in the join, which is the most common cause of slow Sentinel analytics rule queries.
Full explanation below image
Full Explanation
B is correct because the most impactful KQL performance optimization for join queries across large tables is filtering each table to the relevant time range before performing the join. Using the 'ago()' function to filter AzureDiagnostics and SigninLogs to only the lookback window (e.g., last 24 hours) dramatically reduces the data volume that must be processed in the join, which is the most common cause of slow Sentinel analytics rule queries. A is incorrect because replacing join with union does not achieve the same correlation purpose; union appends rows from both tables rather than matching records across them. C is incorrect because 'hint.shufflekey' optimizes join performance for high-cardinality keys in large datasets, but the primary optimization should be reducing data volume through time filtering before applying join strategy hints. D is incorrect because 'take 1000' limits the result set arbitrarily after processing, not the input data volume; it would produce incorrect/incomplete results and would not meaningfully improve query performance on large input tables.