SC-200 Practice Question: A security team wants to automatically block an…

Answer analysis

Option-by-option breakdown

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

• ✗

  Create an automation rule that triggers a playbook directly.

  Why it's wrong here

  Automation rules do not trigger playbooks directly; they are event-driven and only execute when an incident is created or an alert is generated, with playbooks invoked as actions inside the rule. Saying 'trigger a playbook directly' omits the necessary trigger condition (incident or alert creation) and the fact that the playbook is the remediation mechanism, not the trigger itself. To block an IP, you must also specify that the playbook uses the Azure Firewall connector to add a deny rule, which this option fails to include, making the response incomplete and non-actionable.

• ✗

  Create a scheduled analytics rule that runs a playbook.

  Why it's wrong here

  Scheduled analytics rules are query-based detectors that run on a user-defined frequency (e.g., every 5 minutes) and generate alerts or incidents, but they have no mechanism to execute a playbook or any other automated response action. Playbooks can only be launched by automation rules in response to alert/incident creation, by a manual trigger from the Sentinel portal, or from a Logic App's own triggers—not directly from the analytics rule itself. Therefore, this approach is invalid because it confuses detection scheduling with response automation and would fail to block the IP.

• ✓

  Create an automation rule that triggers on incident creation and runs a playbook that uses the Azure Firewall connector to add a rule.

  Why this is correct

  This is the correct architecture because it uses an automation rule with an incident-created trigger, which fires automatically when an incident is raised, and that rule runs a playbook as its action. The playbook—an Azure Logic App—uses the Azure Firewall connector to create a network or application rule in an Azure Firewall policy that denies inbound or outbound traffic from the offending IP address. This method is event-driven, near-real-time, and uses the proper Sentinel automation path, verifying that the automation rule's action is to invoke the playbook, which then performs the actual blocking via the firewall.

• ✗

  Configure a Logic App to poll Sentinel alerts and block IPs.

  Why it's wrong here

  A Logic App polling Sentinel alerts introduces latency and lacks the real-time, event-driven response required for automatic IP blocking in Azure Firewall. This approach is tempting because Logic Apps are a common tool for orchestrating manual or scheduled remediation workflows, such as generating tickets or sending notifications after alert triage. It would be correct for a scenario where immediate blocking is unnecessary and a human-in-the-loop approval step is acceptable.

Go deeper

Related to this question