SC-200 Practice Question: Order the steps to configure a Microsoft Sentinel…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Define the query logic, then set the schedule, then set the alert threshold, then configure incident creation and automated responses.

  Why this is correct

  This is the correct order because in the Microsoft Sentinel analytics rule creation wizard, you first define the query that will be run, then set how often it runs (schedule), then define the threshold that triggers an alert, and finally configure how alerts are grouped into incidents and what automated responses are triggered.

• ✗

  Define the query logic, then set the schedule, then configure incident creation and automated responses, then set the alert threshold.

  Why it's wrong here

  This is incorrect because the alert threshold must be set before configuring incident creation, as the threshold determines which query results generate alerts. Without the threshold, incident settings would be based on incomplete rule logic.

• ✗

  Set the alert threshold, then define the query logic, then set the schedule, then configure incident creation and automated responses.

  Why it's wrong here

  Setting the alert threshold before defining the query logic inverts a hard dependency: the threshold condition is applied to the rows returned by the KQL query, so you cannot know what count or value should trigger an alert until the query's data set and filters are specified. In the 'Set rule logic' pane, the query is entered first, then scheduling and threshold are tuned against that query's actual output. A threshold set first would be arbitrary and would likely cause false positives or no alerts because there is nothing yet being evaluated.

• ✗

  Configure incident creation and automated responses, then define the query logic, then set the schedule, then set the alert threshold.

  Why it's wrong here

  Configuring incident creation and automated responses before defining the query logic is invalid because incident grouping, alert details, and Automation rules operate on properties (Account, Host, IP, etc. through entity mapping) that are only populated after the query identifies matches. The wizard exposes 'Incident settings' after 'Alert rule logic' precisely because fields like grouped entity identifiers and alert severity are derived from the rule's query result set. Without a query, you would have no schema to map entity fields or design Automation rules that filter on alert conditions.

Go deeper

Related to this question