SC-100 Practice Question: Design security operations, identity, and compliance capabilities

Answer analysis

Option-by-option breakdown

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

• ✓

  Configure incident creation in the analytics rule properties

  Why this is correct

  The analytics rule's 'Incident settings' tab (in the rule wizard or via API) controls whether alerts generated by that rule are automatically turned into incidents, and whether related alerts are grouped into a single incident based on entity or alert properties such as account, host, or IP. This is the correct and intended mechanism because incident creation and grouping are natively executed by the rule itself at alert generation time, ensuring the grouping logic is atomic with the rule's detection and does not require separate orchestration. To reduce noise, you set the rule to create incidents and choose an entity-based grouping key (e.g., 'Group alerts by entities into a single incident') or alert property, which Microsoft Sentinel then uses to merge correlated alerts into one incident before any automation or response.

• ✗

  Use a workbook to aggregate alerts

  Why it's wrong here

  Workbooks are interactive reporting canvases that query Log Analytics workspaces via KQL and display the results as charts, tables, or tiles. They are read-only visualizations: they render existing data but cannot trigger a write operation such as creating an incident in Microsoft Sentinel. While a workbook could highlight a high volume of alerts or correlate them in a visual, it does not perform incident lifecycle actions, so it cannot aggregate or reduce the number of incidents generated.

• ✗

  Use a playbook to create incidents

  Why it's wrong here

  Playbooks (Azure Logic Apps or Power Automate workflows) can indeed create incidents by calling the Microsoft Sentinel API or using the Azure Sentinel connector, but they run in response to an incident trigger or alert trigger. If you use a playbook to create incidents from raw alerts, you are bypassing the analytics rule's built-in incident creation and grouping, meaning each alert likely becomes a separate incident or you must implement your own correlation logic in the workflow. This approach is inefficiency and unsupported as a primary grouping mechanism because the playbook runs after alerts are generated, not at the point of detection, and it lacks the native incident grouping context that analytics rules provide.

• ✗

  Create an automation rule to group alerts

  Why it's wrong here

  Automation rules are executed on incidents that already exist in Microsoft Sentinel, not on raw alerts. They can perform actions like changing incident status, assigning owners, adding tags, or running a playbook, but they cannot group alerts into incidents because they operate at the incident level after the incident has been created. Grouping must happen at the analytics rule stage (via the rule's alert-to-incident setting) or, in some advanced scenarios, by using logic within an alert action, but automation rules are fundamentally the wrong layer for that operation.

Go deeper

Related to this question