SC-200 Exam Questions & Answers

This solution also does not meet the requirement. Applying filters to the already-imported worksheet rows in Excel (or attempting to reduce rows in the workbook UI) does not change how Power Query initially samples and infers the JSON schema during the Get & Transform steps. Power Query's schema detection typically happens on a preview/sample of the source data when the query is first evaluated. If the JSON property you need does not appear in that sampled subset, Power Query will not create a column for it even if you later filter the data to include rows that do contain that property. In short, post-export filtering in Excel is not a reliable way to force Power Query to detect and expand missing JSON properties.

The reliable approaches are to increase the number of rows Power Query uses for schema detection (Query Options / Data Load / preview/sample settings) or to explicitly parse each AuditData cell with JSON.Document (or equivalent M functions) and then expand the record fields---these approaches ensure the specific JSON properties are surfaced as columns. Reducing rows via Excel filters does not address the sampling/schema-detection behavior and therefore fails to satisfy the requirement.

In Microsoft 365 Defender advanced hunting, if you want to automatically receive alerts based on a KQL query---such as detecting when a process disables System Restore---you must convert that query into a custom detection rule. According to Microsoft's official documentation, custom detection rules ''run hunting queries on a schedule and create alerts and incidents when results are found.''

In order for the detection rule to function properly and correlate results across devices and incidents, the query must output DeviceId and ReportId. These fields are mandatory for any advanced hunting query that you want to convert into a detection rule because they uniquely identify the device and event instance. Without them, the rule cannot properly generate correlated alerts.

Therefore:

Create a detection rule (A) -- ensures the query runs automatically and alerts are generated.

Add DeviceId and ReportId (E) -- required for detection rule creation and accurate device/event correlation.

Other options are incorrect:

Suppression rule (B) filters alerts, not generate them.

Order by Timestamp (C) is optional for display, not alerting.

DeviceNetworkEvents (D) is unrelated to this process query.

A scheduled query rule in Azure Sentinel is the correct method to detect and generate alerts/incidents based on specific data patterns such as sign-ins from malicious IPs. The scheduled rule can run periodically (e.g., every 5 minutes or hour), execute a KQL query filtering for malicious IPs, and create incidents automatically when matches are found. This satisfies the goal of automatically creating incidents for suspicious sign-ins.

Automated Investigation and Response (AIR) automates investigation and remediation actions for alerts that Defender already detects: it triages alerts, runs investigation playbooks, and can execute remediation (quarantine files, terminate processes, remove persistence) based on the investigation outcome. AIR is powerful for reducing analyst load and quickly remediating detected threats. However, AIR only runs in response to detections/alerts it receives---if the third-party AV completely misses an artifact and no EDR/behavioral detection generates an alert, AIR will not be triggered. In contrast, EDR in block mode is specifically built to catch post-breach detections that the primary AV missed and to remediate them. Therefore, enabling AIR alone does not guarantee protection from artifacts missed by the third-party antivirus; AIR helps remediate once a detection exists but does not itself create the missed detection coverage that EDR in block mode provides.

To create a playbook in Microsoft Sentinel, you must first create an Azure Logic App. Playbooks in Sentinel are built on top of Logic Apps---they define automated workflows that can be triggered by alerts or incidents. Once the Logic App exists, you can connect it to Sentinel via an automation rule or directly from an analytic rule.

A (Azure Function trigger): Used for custom code execution, not for Sentinel automation.

C (Hunting query): Used for threat hunting, not automation.

D (Automation rule): Connects an alert to a playbook but can't exist before a playbook (Logic App) is created.

Answe r: B. an Azure Logic App