Manage a security operations environment →mediumMultiple Choice

SC-200 Manage a security operations environment Practice Question

Exhibit

Refer to the exhibit.

```json
{
  "properties": {
    "displayName": "Suspicious Sign-in Detection",
    "description": "Detects sign-ins from anomalous locations",
    "severity": "Medium",
    "query": "SigninLogs | where RiskLevelDuringSignIn == 'medium' | where Location != 'US'",
    "queryFrequency": "PT1H",
    "queryPeriod": "PT1H",
    "triggerOperator": "GreaterThan",
    "triggerThreshold": 5
  }
}
```

Refer to the exhibit. You are reviewing a Microsoft Sentinel scheduled analytics rule defined in JSON. The rule is intended to trigger an incident when more than 5 sign-ins from anomalous locations occur within an hour. However, the rule is not triggering as expected. What is the most likely cause?

⚠ Common exam trap

The trap here is that candidates may focus on the JSON syntax or rule configuration parameters (like severity type or triggerThreshold) instead of recognizing that the core issue is a KQL query referencing a non-existent column, which is a common data source mismatch error.

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 references a column that does not exist in the SigninLogs table.

The query references a column that does not exist in the SigninLogs table. In Microsoft Sentinel, if a scheduled analytics rule's KQL query references a non-existent column, the query will fail silently or return no results, preventing the rule from triggering an incident. The rule logic depends on the query returning a result set that meets the trigger threshold, and a missing column causes the query to fail or return zero rows.

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 severity is set to 'Medium', but it must be an integer.
Why it's wrong here
The severity property in a Microsoft Sentinel analytics rule is a string-valued enumeration, not an integer. Valid values include 'Informational', 'Low', 'Medium', and 'High', and the API and portal both accept these strings directly. Therefore, setting severity to 'Medium' is valid and cannot be the reason the rule fails.
✓
The query references a column that does not exist in the SigninLogs table.
Why this is correct
The rule fails because the KQL query references a column that does not exist in the SigninLogs table. Sentinel resolves column names against the actual Log Analytics schema, so an unknown column such as a misspelled or guessed field name produces a 'Failed to resolve scalar expression' error when the rule is validated or run. The query must reference a valid column from the SigninLogs schema, such as RiskLevelDuringSignIn or RiskLevelAggregated when evaluating risk level.
✗
The triggerThreshold is set to 5, but it should be a string like '5'.
Why it's wrong here
The triggerThreshold value is a numeric count of query results that the rule requires before generating an alert. In Sentinel's configuration model, this property is an integer, not a string, so the value 5 is correct. Quoting it as '5' would cause a data-type mismatch during validation and would not fix the underlying query error.
✗
The queryFrequency and queryPeriod are set to the same value, which is not allowed.
Why it's wrong here
Sentinel does not prohibit setting queryFrequency and queryPeriod to the same value; the two properties are allowed to be equal. When they are equal, the lookback window starts at the time of the previous run, which can create a gap if data ingestion is delayed. Best practice is to make queryPeriod longer than queryFrequency to account for ingestion latency, but equal values are not the root cause of this failure.

Go deeper

SC-200 Manage a security operations environment Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question