mediumMultiple Choice
SC-200 Practice Question: A security analyst is using Microsoft 365…
A security analyst is using Microsoft 365 Defender advanced hunting to investigate a phishing campaign. The analyst wants to find emails that were delivered to users (DeliveryAction != 'Blocked') and contained a specific malicious URL (e.g., 'https://malicious.com'). The EmailEvents table contains delivery information, and the EmailUrlInfo table contains URL details. Which KQL query correctly joins these two tables to find the desired emails?
⚠ Common exam trap
The trap should not claim that leftouter join includes all delivered emails after a Url filter; the filter removes them. The real trap is selecting an incorrect join key (Name or SenderFromDomain) from options C/D.
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
✓
EmailEvents | where DeliveryAction != 'Blocked' | join kind=inner EmailUrlInfo on NetworkMessageId | where Url == 'https://malicious.com'
It uses an inner join on NetworkMessageId, which is the proper key. However, Option B also produces the desired result: the leftouter join retains all delivered emails, but the `where Url == 'https://malicious.com'` predicate excludes rows where no matching URL was found (since null Url does not equal the target). Thus B's result set is identical to A's. Options C and D join on incorrect keys. In practice, inner join is more efficient, but B is not logically wrong.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
EmailEvents | where DeliveryAction != 'Blocked' | join kind=inner EmailUrlInfo on NetworkMessageId | where Url == 'https://malicious.com'
Why this is correct
This query is correct because it uses an inner join on NetworkMessageId, the unique identifier for a single email message in both EmailEvents and EmailUrlInfo. Filtering DeliveryAction != 'Blocked' first limits the result set to messages that were delivered or otherwise not prevented, then the inner join ensures only events with a matching URL record in EmailUrlInfo survive. Finally, the where clause on Url after the join safely filters for the exact malicious URL without risking null values that would appear with an outer join.
- ✗
EmailEvents | where DeliveryAction != 'Blocked' | join kind=leftouter EmailUrlInfo on NetworkMessageId | where Url == 'https://malicious.com'
Why it's wrong here
This query fails because the `Url` field is in the `EmailUrlInfo` table, but the `where` clause filters on it *after* the `leftouter` join. A `leftouter` join preserves all records from `EmailEvents` even if there's no match in `EmailUrlInfo`, meaning `Url` could be null. This option is tempting as it correctly identifies the need to join `EmailEvents` and `EmailUrlInfo` and uses a `leftouter` join, which is often useful for finding events that *might* have associated URL information.
- ✗
EmailEvents | where DeliveryAction != 'Blocked' | join kind=inner EmailUrlInfo on Name | where Url == 'https://malicious.com'
Why it's wrong here
Using Name as the join key is fundamentally flawed because Name is not a unique identifier for an email message and does not exist in both tables as a reliable relation to URL data. In EmailEvents, Name may refer to a user mailbox or other non-message attribute, not the message ID, so joining on it would incorrectly pair unrelated email events with URL records or produce many-to-many matches. Even with an inner join, the wrong key means the query will not accurately identify the specific email containing the malicious URL, leading to both false positives and missed matches.
- ✗
EmailEvents | where DeliveryAction != 'Blocked' | join kind=inner EmailUrlInfo on SenderFromDomain | where Url == 'https://malicious.com'
Why it's wrong here
Joining on SenderFromDomain equates all emails coming from the same sender domain, which is far too coarse a relationship to associate a URL with a specific message. This key would match every EmailEvents record from that domain against every EmailUrlInfo record from that domain, creating a cross-product-like result where a URL from one email appears associated with unrelated emails. NetworkMessageId is the only field that uniquely maps a specific email event to its specific URL entities, so joining on domain invalidates the query's ability to pinpoint the actual malicious email.
Go deeper
Related to this question
About these practice questions
One of 1,303 original SC-200 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 SC-200 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 SC-200 exam.