SC-200 Manage a security operations environment Practice Question
Exhibit
Refer to the exhibit. ```kusto SecurityAlert | where TimeGenerated > ago(24h) | where AlertName == "Suspicious sign-in" | extend UserPrincipalName = tostring(Entities[0].AccountUpn) | where UserPrincipalName !endswith "@contoso.com" | project TimeGenerated, AlertName, UserPrincipalName ```
Refer to the exhibit. You have a KQL query in a Microsoft Sentinel analytics rule. The rule is not generating incidents even though there are 'Suspicious sign-in' alerts from non-contoso.com users. What is the most likely issue?
⚠ Common exam trap
A common mix-up: candidates assume all security alerts are stored in a single 'Alert' table, but Microsoft Sentinel separates alerts into multiple tables (e.g., 'SecurityAlert', 'AlertEvidence', 'SigninLogs') based on the source service, and the exam tests your knowledge of which table corresponds to which alert type.
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
✓
The query is querying the wrong table. 'Suspicious sign-in' alerts may be in a different table.
The query is likely querying the 'Alert' table, but 'Suspicious sign-in' alerts from non-contoso.com users are generated by Microsoft Defender for Identity or Microsoft Entra ID Protection and stored in the 'SecurityAlert' table (or 'AlertEvidence' in the new schema). The rule's query must reference the correct table to retrieve these alerts; otherwise, no matching records are found, and no incidents are created.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The 'extend' line is incorrectly parsing the entity.
Why it's wrong here
This explanation is incorrect because the KQL syntax within the extend operator is valid; it properly uses parse_json to access the target entity from the JSON property bag. Entity extraction from ExtendedProperties may require defensive handling, but in this query the parsing is not the cause of failure. The real problem lies upstream: the query is pointing at the wrong log table, so even perfect parsing returns no relevant alerts.
- ✓
The query is querying the wrong table. 'Suspicious sign-in' alerts may be in a different table.
Why this is correct
This is the correct issue. 'Suspicious sign-in' alerts are typically surfaced through Microsoft Sentinel's SecurityAlert table or through identity protection logs such as SigninLogs, and these records are not guaranteed to exist in the table referenced by this query. Querying the wrong table means the where and extend clauses are applied to a schema that lacks the alert evidence or uses different field names, resulting in no matching rows. Confirming the table name against the alert product's data connector is the necessary first troubleshooting step.
- ✗
The 'where' clause using !endswith is incorrect.
Why it's wrong here
The !endswith operator is a legitimate KQL string operator that determines whether the source string does not end with the given value; its use is syntactically and semantically acceptable here. It performs a case-insensitive match and excludes rows whose RunbookName ends with the specified value. While null values in the column would make the operator return false rather than true, that is a data-quality concern, not an incorrect operator choice. Hence, this option misidentifies a valid filter as the root cause.
- ✗
The query does not filter by AlertName correctly.
Why it's wrong here
This option fails because the query already contains an appropriate equality filter against the AlertName column. An equality check on AlertName is the standard way to select a specific Sentinel alert type, and no syntax error or misplaced wildcard exists in this predicate. Even if the query returns fewer rows than expected, the alert-name filter is not the culprit; the absence of suitable alert records in the table being queried would explain the empty result. Thus, this objection is not a valid explanation for the query's failure.
Go deeper
Related to this question
About these practice questions
This SC-200 question is part of Courseiva's 1,303-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.