Respond to security incidents →mediumMultiple Choice

SC-200 Respond to security incidents Practice Question

Exhibit

Refer to the exhibit.
```json
{
  "properties": {
    "displayName": "Phishing Incident Response",
    "triggers": [
      {
        "type": "Alert",
        "conditions": [
          {
            "field": "alertName",
            "operator": "Equals",
            "value": "Phishing email delivered"
          }
        ]
      }
    ],
    "actions": [
      {
        "type": "RunPlaybook",
        "playbookId": "/subscriptions/.../playbooks/QuarantineEmail"
      }
    ]
  }
}
```

Refer to the exhibit. You are configuring an automation rule in Microsoft Sentinel. The JSON snippet defines an automation rule. What is the expected behavior of this rule?

⚠ Common exam trap

Watch out — candidates often confuse the trigger condition (alert creation vs. incident creation) and assume the rule directly performs an action like sending an email or modifying severity, when in fact the rule only triggers a playbook that performs those actions.

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

✓

It runs a playbook to quarantine an email when a specific alert is generated

The automation rule is triggered when a specific alert is generated (as defined by the trigger condition), and it runs a playbook that contains logic to quarantine an email. In Microsoft Sentinel, automation rules can be configured to trigger on alert creation and execute a playbook, which in this case performs the quarantine action.

Answer analysis

Option-by-option breakdown

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

✗
It creates an incident when a phishing email is detected
Why it's wrong here
Automation rules do not create incidents; they act on an existing alert or incident after it is generated. In Microsoft Sentinel, incident creation is performed by the analytics rule based on its alert grouping and incident configuration, not by an automation rule. This rule triggers on an alert, so it can only execute a playbook and cannot instantiate a new incident.
✗
It sends an email to the security team when an incident is created
Why it's wrong here
Microsoft Sentinel automation rules lack a native 'send email' action; email notifications require a playbook with a connector such as Outlook or Teams. In this exhibit, the rule's only action is running the 'Quarantine' playbook, and no email dispatch is configured. Therefore, this description falsely attributes an email action that does not exist in the rule definition.
✓
It runs a playbook to quarantine an email when a specific alert is generated
Why this is correct
The rule's trigger is set to a specific alert name and its action is to invoke a playbook, which is exactly how automated response works in Sentinel. When that alert fires, the rule automatically runs the Quarantine playbook, which likely uses a Microsoft 365 or Defender connector to isolate the offending email. This matches the exhibit: the automation rule reacts to the alert, not to an incident, by executing a playbook.
✗
It modifies the incident severity when a playbook runs
Why it's wrong here
Changing incident severity is a distinct automation rule action labeled 'Change severity', but the exhibit shows no such action for this rule. Further, the rule triggers on an alert, and incident severity modifications are only relevant when the trigger is incident creation or update. The playbook execution is the outcome, not a trigger, so severity is never modified by this rule.

Go deeper

SC-200 Respond to security incidents Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question