The Microsoft Security Operations Analyst (SC-200)

To complete the KQL query against the BehaviorAnalytics t able, you need to know the exact column name (for example, the Boolean field that flags a new or first-time country for the sign-in). Microsoft’s standard method to discover table schemas and column names is the Logs (Log Analytics) query window . In this p ane, the left-hand Schema browser lists all connected tables and, when expanded, shows every column name and data type . Selecting a table (e.g., BehaviorAnalytics ) reveals its fields, and the editor provides IntelliSense/autocomplete for columns as you typ e your KQL, making it straightforward to complete a clause like | where < ColumnName > == true .

Security alerts in Azure Security Center (Defender for Cloud), the Azure Activity log, and Azure Advisor do not expose the per-table column schema needed to build KQL filters. Security Center surfaces alerts and recommendations; the Activity log records control-plane operations; and Advisor provides optimization guidance—none of these replace the Logs experience for exploring data schemas.

Therefore, to accurately identify and verify the column required in the where clause for failed sign-ins from a first-time country, you should use the Log Analytics workspace query window , consult the Schema pane for the BehaviorAnalytics table, and leverage the editor’s autocompl ete to insert the correct column name.

As outlined in Microsoft’s official Defender for Of fice 365 documentation, this service provides comprehensive protection against threats targeting Microsoft 365 collaboration tools—such as SharePoint Online , OneDrive for Business , and Microsoft Teams . The marketing team uses SharePoint Online for vendor c ollabora tion and has experienced incidents in which vendors uploaded malicious files. Microsoft Defender for Office 365 specifically addresses this scenario through features like Safe Attachments and Safe Links , which automatically scan uploaded or shared files for malware and block access to harmful content.

When a vendor uploads a file to SharePoint Online, Defender for Office 365 inspects the file in real time within a virtual sandbox environment before allowing users to open or share it. If malware is d etected, the system quarantines or removes the file and notifies administrators. These detection and remediation capabilities prevent infection propagation, protect sensitive marketing data, and maintain compliance with Contoso’s security posture.

By leveraging Defender for Office 365, Contoso’s marketing team can continue external collaboration safely, ensuring that all uploaded files are scanned and validated before internal access—thereby resolving their specific malware-related issue.

According to Microsoft Security Operations documentation, Microsoft Defender for Endpoint is designed to protect endpoint devices—including Windows, macOS, Android, and iOS —against cyberattacks through advanced behavioral analysis, threat intelligence, and automated investigation and remediation. In the given case study, the sales team exclusively uses iOS devices and has previously experienced attacks while exchanging files using third-party applications. These unmanaged file-sharing methods exposed the te am to malware, phishing, and data leakage threats.

By implementing Microsoft Defender for Endpoint on iOS, Contoso can apply unified endpoint protection across all mobile devices. Defender for Endpoint’s mobile threat defense (MTD) capabilities detect mali cious apps, risky network connections, jailbroken devices, and phishing attempts. It also integrates with Microsoft Intune for compliance enforcement and conditional access—ensuring only secure, compliant devices can access corporate resources. This direct ly mitigates the security challenges faced by the sales team while minimizing manual investigation effort through automated response.

Therefore, the issue affecting the sales team (mobile device attacks and unsafe file transfers) can be effectively resolve d using Microsoft Defender for Endpoint .

To remediate active attacks automatically once alerts or incidents are detected, Microsoft Sentinel uses playbooks , which are workflows built on Azure Logic Apps . These playbooks can execute remediation actions—such as isolating a machine, blocking an account, or triggering other security control chang es—without manual intervention. Microsoft’s documentation clearly states that “playbooks in Microsoft Sentinel are based on workflows built in Azure Logic Apps” and that they can “automate and orchestrate your threat response by using playbooks … run a pla ybook on-demand or automatically in response to specific alerts or incidents.”

When an analytics rule in Sentinel triggers an alert or incident, you can attach an automation rule which in turn invokes a playbook (i.e. a Logic Apps workflow) to perform the remediation steps. The automation rule defines the trigger conditions and calls the playbook action as part of its response actions.

Let us evaluate other options:

Azure Automation runbooks (Option A) are powerful for scripting in Azure (e.g., PowerShell o r Python) and can perform remediation tasks, but they are not the native mechanism within Sentinel for orchestrated, alert-driven response workflows.

Azure Functions (Option C) are serverless compute for custom code, but you would have to build and integra te orchestration logic manually; they are not the out-of-box SOAR component in Sentinel.

Azure Sentinel livestreams (Option D) is not a recognized remediation automation component—it is irrelevant in this context.

Therefore, the correct solution to remedia te active attacks (triggering automated actions in response to alerts/incidents with minimal manual effort) is to use Azure Logic Apps (via Sentinel playbooks) as the orchestration engine. Logic Apps are the documented foundation of Sentinel’s automation r esponse capabilities.

Roles in Microsoft Sentinel are designed for least privilege. The Azure Sentinel Responder role allows analysts to view, assign, update, and dismiss incidents , change status/severity, and add comments—exactly the actions a Tier-1/Tier-2 analyst needs for day-to-day triage. Azure Sentinel Reader is view-only and cannot change incident state. Azure Sentinel Contributor is broader than needed (it includes creating/editing analytics rules and other configuration). Logic App Contributor pertains to playbook authoring, not incident handling. Therefore, to let a new analyst assign and dismiss incidents while honoring least privilege, assign Azure Sentinel Responder .

In a Microsoft 365 E5 subscription with a hybrid Azure AD environment , monitoring changes to privileged Active Directory grou ps (like Domain Admins ) is handled by Microsoft Defender for Identity . The “Modifications of sensitive groups” report provides visibility into all changes made to sensitive AD groups such as Domain Admins , Enterprise Admins , and Schema Admins .

According to Microsoft Defender for Identity documentation:

“The Modifications of sensitive groups report identifies all changes to highly privileged groups, including additions and removals of members. It helps detect potential privilege escalation and insider threat s.”

This report displays all relevant group modification activities within a defined time range (for example, the last 30 days), fulfilling the requirement.

✅ Correct answer: C. the Modifications of sensitive groups report in Microsoft Defender for Identit y

In Microsoft 365 Defender , the Collect investigation package action allows a security analyst to remotely gather forensic evidence (logs, running processes, network info, registry data, etc.) from a device for deeper analysis.

This capability is supported on both Wind ows and Linux devices onboarded to Microsoft Defender for Endpoint.

The other options serve different purposes:

Run antivirus scan: triggers a malware scan, not evidence collection.

Initiate Automated Investigation: starts automated threat response but not direct evidence collection.

Initiate Live Response Session: opens an interactive session, but the question specifically asks for package collection via the portal.

✅ Correct Answer: C. Collect investigation package

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 a n 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.

The goal is to automatically execute the Azure Logic App ( app1 ), which is known as a Playbook in Microsoft Sentinel, in response to a newly created alert.

The Playbook (Logic App): An Azure Logic App used for security response in Microsoft Sentinel is called a Playbook. It is a workflow that must start with a trigger, typically the Microsoft Sentinel incident or Microsoft Sentinel alert trigger.

The Trigger Mechanism (Automation Rule): To run a playbook automatically when an alert or incident is created, you must use a Microsoft Sentinel Automation Rule .

Required Flow: The Logic App ( app1 ) acts as the action to be performed, but it must be called by an automation component. The recommended and modern approach for linking automated actions (playbooks) to alerts and incidents in Microsoft Sentinel is via Automation Rules .

The sequence of operations is:

The Azure AD Connector ingests data into the Microsoft Sentinel workspace.

A corresponding Analytics Rule (Option C) detects a threat in that data and generates an Alert . This alert usually leads to the creation of an Incident .

The Automation Rule (Option D) is configured to:

Trigger: When an incident is created (or when an alert is created).

Condition: Filter for the specific alert or incident (e.g., where the Analytic Rule Name is the one that detects the Azure AD threat).

Action: Select the Run playbook action and specify app1 .

While an Analytics Rule (C) generates the initial alert, the Automation Rule (D) is the specific component that takes that alert/incident as input and performs the action of launching the Logic App (playbook) automatically. The ability to invoke playbooks directly from Analytics Rules (the " Alert automation (classic) " method) is deprecated in favor of using Automation Rules, making the Automation Rule the correct and contemporary first step for this requirement.