Microsoft Security Operations Analyst SC-200 (SC-200) — Questions 1–75

Creating a custom indicator of compromise (IoC) for the specific file hash, with the action set to Block and remediate, is the precise and recommended response. This indicator is propagated to all devices through Microsoft Defender XDR, preventing the file from executing and automatically triggering remediation of existing copies on any onboarded endpoint. Because the block is scoped solely to that file hash, legitimate applications are preserved, avoiding false positives, and the defense persists for future attempts to execute or download the file.

Anomalous logon location is one of the built-in hunting queries in Microsoft Sentinel, found in the Hunting blade. It uses KQL to analyze sign-in logs, detecting attempts from unexpected geographies or IP addresses, which may indicate compromised credentials or impossible travel. This query is part of Sentinel's predefined hunting pack and is a strong indicator of credential misuse.

The Incident investigation graph is the correct choice because it presents an interactive, visual map of all entities (e.g., IPs, hosts, accounts, and files) related to the incident, along with the edges representing their relationships. This graph helps you quickly identify potential attack vectors and pivot between connected entities to understand the full scope of the incident, fulfilling the SOC team's requirement to see all related entities in one view.

This query correctly isolates the last 24 hours of activity, groups events by each caller (user or service principal) and by one-hour time bins, and then computes the distinct count of Resource values—the full Azure resource IDs—for each group. The filter dcount_Resource > 20 surfaces users that accessed an unusually high number of distinct Azure resources within a single hour, a pattern consistent with an attacker rapidly enumerating the environment to find high-value targets. This approach balances sensitivity and performance, and it directly maps to the MITRE ATT&CK technique T1087 (Account Discovery) or T1526 (Cloud Service Discovery) when run as a scheduled Sentinel analytics rule.

IdentityLogonEvents captures only on-premises Active Directory and AD FS authentication, not cloud sign-ins. Azure Portal logons are recorded in Microsoft Entra ID sign-in logs, surfaced in Microsoft Defender for Cloud Apps through the AADSignInEventsBeta table. Querying the wrong table explains the empty result despite known portal logons.

Microsoft Defender for Endpoint's live response feature provides a remote shell to the non-domain-joined Windows 10 device, where the memory dump can be captured using its built-in commands. This satisfies the remote acquisition constraint without physical access or domain membership.

Isolating affected devices using Microsoft Defender for Endpoint is the correct first step because it immediately blocks all incoming and outgoing communication to and from the compromised host, cutting off the ransomware's ability to spread laterally and communicate with command-and-control servers. This action preserves forensic evidence while containing the attack, and it can be initiated remotely from the MDE console without requiring physical access or disrupting the rest of the network. Full isolation still allows the Defender service to communicate, so security teams can continue to investigate and remediate the endpoint.

Viewing related entities such as IP addresses is a core Sentinel investigation action, letting analysts pivot from an incident to the associated hosts, accounts and addresses on the entity graph. This satisfies the stem's requirement for valid investigation actions, since entity exploration is built into the incident investigation experience.

Checking for access to applications outside a user's historical usage is a high-fidelity indicator of identity compromise because attackers rarely mimic the exact application footprint of the legitimate user. In Microsoft Sentinel, you can use UEBA data or sign-in logs to build a baseline and then alert when a newly logged-on application has no prior events for that user. This type of anomaly is less likely to be a false positive than raw volume-based signals, because it directly reflects the attacker's post-authentication intent.

The non-existence of 'Set-AzSentinelSetting' in the Az module directly explains why the Anomalies setting remains disabled. PowerShell scripts fail when attempting to invoke cmdlets that are not recognised or do not exist within the loaded modules. This scenario indicates the script encountered an execution error because the specified cmdlet for modifying Sentinel settings was not found, preventing the intended configuration change from being applied.

Investigating entities found in the query results is a defining threat-hunting action because it requires pivoting from raw data to the entity pages for users, devices, files, IPs, or mailboxes, then reviewing timelines, related alerts, and correlated events to decide whether the behavior is genuinely malicious. This validation step is what confirms or refutes the original hypothesis and reveals the scope of the threat. Without entity-level investigation, a hunter cannot distinguish a true positive from a benign anomaly or a false positive.

Entity behavior analytics in Microsoft Sentinel uses UEBA to build a historical behavioral profile for each user, host, or other entity, including attributes like sign-in times, accessed apps, and resource usage. It then performs peer comparison by grouping entities with similar roles or attributes and statistically identifies when an individual's current behavior deviates from the group's baseline, such as an unusual location or impossible travel. This automated, baseline-driven peer comparison is precisely how UEBA detects anomalies, making it the correct answer.

Microsoft Defender for Cloud Apps governance actions apply remediation directly to connected apps, letting the analyst disable the offending Power Automate flow from within the alert. This stops the exfiltration immediately without leaving the portal, matching the requirement to disable the flow at once.

In Microsoft Sentinel, incident ownership is controlled by the Owner field in the incident details pane; setting it to the senior analyst formally assigns the incident to them, making it appear in their 'My incidents' view and routing any notifications according to the workspace's settings. Updating the owner preserves the incident's original ID, entity links, evidence, and full audit history, which is critical for accurate incident response documentation. This action is the recommended way to escalate an incident for additional review.

Ingesting Microsoft Defender XDR incidents through its official data connector is the supported first-party integration path and the only method that provides bi-directional synchronization natively. After you enable the connector, incidents created in Defender XDR appear in Sentinel and any analyst status update—such as resolved or closed—is written back to Defender XDR, and vice versa, through an automated sync mechanism. This approach preserves the full incident context and correlation across Defender workloads instead of just importing raw alerts.

Isolating the affected device from the network breaks the attacker's ability to use the compromised host to authenticate to other systems via pass-the-hash, effectively containing the lateral movement at the source. This is an immediate containment action that limits the blast radius while preserving process memory and network evidence for forensic analysis. In Microsoft Defender for Endpoint, 'Isolate device' blocks all inbound/outbound traffic except to the Defender service.

An automation rule in Microsoft Sentinel runs when an incident is created or updated and can trigger a playbook that includes an approval action—for example, a Microsoft Teams adaptive card or Outlook email requiring a SOC analyst to click Approve. Only after that approval is received does the Logic App continue to the Defender for Endpoint device-isolation step, ensuring a human has actively confirmed the containment decision. This approach also records every action in the playbook's run history and complies with the SOC's requirement to confirm before isolating.

The 'Isolate device' action in Microsoft Defender for Endpoint disconnects the device from the network except for the Defender for Endpoint service, allowing you to remotely investigate and remediate. This meets the requirement of isolating the device while maintaining a management channel. It is the correct containment action for a compromised device.

Suppression rules are the correct approach because they operate at the alert-dismissal stage rather than the detection stage. In Microsoft Defender for Cloud Apps, you can define suppression based on entity attributes such as user, IP address, or app, so alerts that match the rule are automatically closed or hidden before they reach the analyst. This directly addresses false positives by removing known-benign patterns (e.g., a service account that legitimately performs anomalous-looking bulk downloads) while keeping the underlying policy active for genuinely suspicious activity. Crucially, this does not weaken detection coverage and is fully auditable, making it the recommended operational response to alert fatigue.

The recommended approach is to ingest Defender for Cloud Apps alerts into Microsoft Sentinel using the Defender for Cloud Apps data connector, which normalizes the alerts as Sentinel incidents. Once ingested, a Sentinel automation rule can be created to run when an incident is generated, triggering an Azure Logic Apps-based playbook that posts a formatted message to a Microsoft Teams channel. This pipeline is fully integrated, leverages Sentinel's native threat intelligence and incident management, and can include enrichment steps before the Teams notification is sent.

Hunting queries in the Microsoft Sentinel hunting blade let analysts proactively search logs for indicators such as PowerShell encoded commands, matching the requirement to seek out a known threat actor's techniques rather than wait for an alert.

Isolating the device with Microsoft Defender for Endpoint's device isolation feature is the correct initial response because it severs all inbound and outbound communication except to the Defender service, immediately containing the threat while keeping the device powered on. When forensic preservation mode is enabled, the device remains in a state that preserves volatile evidence and prevents file system changes, allowing security analysts to investigate the compromise, collect artifacts, and remediate without losing critical data—all through a centrally managed, reversible action.

Automation rules in Microsoft Sentinel trigger on incident creation and can set owner, status or severity. Configuring one with a severity condition of High or above automatically assigns matching incidents to the senior analyst tier, removing manual triage effort.

The correct approach is to install the Azure Monitor Agent (AMA) on each server, because it is the current, fully supported agent for sending logs to Azure Monitor and Microsoft Sentinel. You then define a Data Collection Rule (DCR) that specifies which security event logs — such as the Windows Security log, Sysmon, or Linux syslog — are collected and routed to the Sentinel workspace. The DCR can also apply filtering to reduce noise and control which event IDs are ingested, giving you precise and scalable collection.

Disabling the account in Active Directory immediately blocks further authentication, stopping the unauthorised access while the account and its activity remain intact for forensic review. Containment first prevents additional damage before broader investigation or remediation.

summarize is the KQL aggregation operator that groups rows by specified columns, such as UserPrincipalName or IPAddress, and computes aggregates like count(), sum(), or avg() across each group. In a scheduled analytics rule, this is exactly what enables threshold detection by producing per-entity event counts that can be compared against a threshold, such as more than 5 failed sign-ins for a single user.

An automation rule triggers on incident creation and launches a playbook, which executes the Logic Apps workflow calling Microsoft Entra ID to disable the compromised account. This satisfies the requirement for automatic response without manual analyst intervention.

IdentityLogonEvents records authentication activity across Microsoft Entra ID and on-premises identity infrastructure, including logon type, application and failure reasons. This makes it the appropriate table for surfacing anomalous or suspicious logon patterns indicative of credential theft.

The location condition is the root cause of the MFA prompt because it is set to include 'All trusted locations,' causing the policy to force MFA even when users connect from the corporate network. To require MFA only on untrusted connections, the policy should either include 'All untrusted locations' or include 'Any location' and then exclude 'All trusted locations.' Excluding trusted locations from the policy's scope ensures that sign-ins from the office aren't challenged, while still protecting access from unknown or risky networks.

Creating a custom role that includes the Microsoft Sentinel Automation Contributor permission is the correct approach because it provides the least-privilege access needed to read, create, edit, and delete automation rules, playbooks, and automation rule actions without granting full control over all Sentinel resources. The Microsoft Sentinel Automation Contributor role (often the built-in role or a custom role based on it) scopes permissions specifically to automation rule management, including the ability to trigger playbooks, while avoiding broader Sentinel management rights. Assigning this custom role only to the security analysts ensures they can perform their required tasks without exposing sensitive configurations or other security operations features. This aligns with Azure RBAC best practices and the principle of least privilege, making it the technically correct solution.

Enabling Microsoft Defender for SQL at the subscription or resource level is the action that activates the SQL-specific threat detection engine, which combines Advanced Threat Protection and vulnerability assessment for SQL Server on Azure VMs. This plan analyzes database telemetry and audit logs to raise alerts for SQL injection, brute-force attacks, and unusual access patterns. Subscription-level enablement ensures all existing and newly provisioned SQL resources are protected, while resource-level enablement scopes the same protections to a particular SQL Server instance.

The Microsoft 365 Defender connector is the data plane that carries M365 Defender alerts, including those from Defender for Endpoint, into Microsoft Sentinel. If this connector is not enabled in Sentinel's content hub and configured with the correct Microsoft 365 Defender workspace setting, no alerts will be streamed to the workspace. Since the symptoms point to missing alerts, verifying the connector's status and configuration is the primary and most direct troubleshooting step.

Disabling the account in Microsoft Entra ID and revoking all sessions immediately cuts off the attacker's access, containing the incident before scope investigation. This neutralises the compromised identity across SharePoint, Defender XDR workloads and conditional access, which is the priority containment step.

Enabling Defender for Servers activates the built-in vulnerability assessment that automatically deploys the Qualys agent extension to supported Windows Server VMs, discovering missing security updates and configuration vulnerabilities without additional licensing. This integration is native to Defender for Cloud, and once the plan is enabled, the assessment runs continuously, surfacing findings in the Security Center recommendations such as "Machines should have vulnerability findings resolved." It does not require manual installation of any separate agent or marketplace product.

Devices are a primary managed entity in Microsoft Defender XDR. In Defender for Endpoint, every onboarded workstation, server, and mobile device is represented in the Device inventory and can be isolated, scanned, excluded from automated investigation, or added to a device group. Because device context drives alert correlation across identity, email, and data protection, the device is a core entity for XDR incident management.

Running a playbook is a supported action for an automation rule: the rule can invoke a Microsoft Sentinel playbook, which is a Logic Apps workflow, as its action and pass contextual data such as incident ID, alert ID, or analytics rule ID to the logic app. This enables automatic investigative and remediation steps such as blocking an IP, checking threat intelligence, or creating a support ticket. The playbook must be configured with the correct permissions, either through the automation rule's managed identity or a service principal, and must have the appropriate Microsoft Sentinel role assignments.

The Incident timeline is the correct feature because it provides a chronological, visual view of all alerts, bookmarks, and related activities associated with a specific incident. This timeline lets analysts quickly reconstruct the attack sequence, correlate events, and understand the full scope of the incident in one place. It is the primary view used during incident triage and investigation in Microsoft Sentinel.

Defender for Containers is the Microsoft Defender for Cloud plan specifically built for AKS and can also cover Kubernetes distributions in Azure Arc-enabled environments. It combines control plane threat detection from Kubernetes audit logs, workload runtime protection via a daemon set, and vulnerability assessment for images from any registry, making it the correct choice for protecting containerized workloads. Enabling this plan on the subscription provides consolidated coverage for both the orchestration layer and the containers themselves.

Connecting Microsoft 365 data sources is essential because Microsoft Sentinel hunting queries must run against ingested telemetry from these connectors. Office 365 and Entra ID provide audit logs, sign-in logs, and email/Teams activity, and Defender for Cloud Apps adds SaaS shadow IT and session data. Without these sources, KeyVault events, IdentityInfo, and other UEBA-dependent tables remain empty, so hunting for malicious user behavior is impossible.

Log Analytics workspaces enforce ingestion rate limits (for example, 500 MB per minute or a 100 GB per-day cap depending on the pricing tier). When the combined volume from all sources exceeds these thresholds, the platform throttles ingestion and drops or truncates the excess data, which can result in partially written JSON records that appear as malformed logs. This specifically explains why a high data volume scenario would produce parsing or truncation errors without any authentication or connectivity issues.

A custom policy initiative requires at least one policy definition and an initiative definition that references those policies. The initiative definition is a JSON document containing metadata, parameters, and an array of policy definition IDs, all grouped for a shared compliance goal. Without both elements, there is no logical grouping to assign or evaluate in Azure Policy. Therefore, this pair is the minimal and correct set of components needed to create a custom initiative.

Microsoft Entra ID audit logs record sign-in and directory change activity, and Microsoft Sentinel ingests them through the Entra ID data connector. They surface authentication anomalies and privilege changes, giving threat hunters a native identity-based data source for correlating suspicious account behaviour across the environment.

A custom Azure Policy initiative is the correct mechanism because an initiative bundles multiple policy definitions, including built-in Azure Security Benchmark definitions and your own custom definitions, into a single assignable unit. When assigned at the subscription or management group scope, it evaluates resources against both the benchmark's built-in controls and your additional custom rules. This satisfies the requirement to assess the environment against two combined sets of controls simultaneously.

Suspending the account prevents further access immediately.

Microsoft Entra ID sign-in logs are the authoritative source for user authentication events, containing details such as sign-in time, IP address, location, conditional access policies, MFA result, and risk detection—all essential for analyzing a sign-in anomaly. Microsoft Defender for Endpoint device events provide host-level telemetry like process execution, network connections, and attack behavior, allowing the analyst to correlate the sign-in activity with what is happening on the device used to authenticate. Together, these sources let you establish whether the sign-in is truly abnormal and whether the device itself is compromised, enabling a data-driven investigation.

The Office 365 connector is a first-party, built-in data connector in Microsoft Sentinel. It ingests audit logs from Exchange Online, SharePoint Online, Microsoft Teams, and other Microsoft 365 workloads through the Microsoft 365 Management Activity API, and you enable it by simply connecting an Office 365 tenant on the connectors page. This is one of the standard, valid connectors.

Setting the action to 'Block' instructs Defender for Cloud Apps to deny the request at the reverse proxy when the download is attempted, effectively preventing the file from being transferred. Enabling 'Notify user' with a customized message displays an interactive notification that the user must read and acknowledge, which warns the user and leaves an audit record of the acknowledgment. This combination of a hard block and an acknowledged, personalized message meets both the download-prevention and user-notification requirements.

Blocking known malicious IP addresses at the firewall is a direct and immediate containment action that severs the network communication path between the compromised environment and the attacker's command-and-control (C2) infrastructure. By applying egress and ingress rules to deny traffic to these IPs, you cut off remote commands, data exfiltration, and potential malware downloads, thereby limiting the adversary's operational control without disrupting normal business traffic.

Sentinel automation rules must specify a valid trigger type: 'Microsoft.SecurityInsights/Alert' for alert-triggered rules or 'Microsoft.SecurityInsights/Incident' for incident-triggered rules. The exhibit shows 'Microsoft.SecurityInsights/AlertRule', which is not a recognized trigger type in the automation rule schema, so the rule will not fire as intended. This invalid trigger type is the actual defect preventing the rule from working.

AzureActivity data is regional; the West Europe VM's activity logs are only written to a workspace in that region unless explicitly streamed. Routing them into the East US workspace ensures the analytics rule can correlate all evidence for the incident.

An automation rule in Microsoft Sentinel is the correct mechanism for incident-driven response: it evaluates incidents the moment they are created, matches configured conditions (e.g., severity, entity, tactic), and immediately executes a playbook. This is event-driven, consistent, and removes the need for analyst intervention, aligning with the scenario's requirement to automate incident-created actions.

The correct answer is to assign the built-in Azure Policy initiative that deploys Microsoft Defender for Cloud configuration, such as the 'Microsoft Defender for Cloud' initiative, to the root management group or subscription scope. This initiative uses DeployIfNotExists and Modify effects to automatically enable the Defender plans, configure data collection, and remediate any drift. Because policy inheritance flows to all child scopes, every new subscription is continuously assessed and brought into compliance without manual or scheduled intervention, providing a fully governed, auditable enforcement mechanism.

DeviceNetworkEvents is the correct table for C2 hunting because it specifically records network connection attempts, including source and destination IP addresses, ports, protocols, and remote URLs. Unlike file or process events, this table lets you directly search for outbound connections to known malicious or suspicious infrastructure, which is the core signature of command-and-control communications. Without this telemetry, you cannot definitively identify the network egress point to a C2 server.

The Anomalous Azure Operations rule is a built-in Microsoft Sentinel analytics rule that uses machine learning to analyze AzureActivity logs and flag unusual operations within an Azure subscription, such as atypical role assignments, resource deployments, or modification of critical settings. Unlike other anomaly rules, it specifically targets the Azure control plane and is driven by the AzureActivity data connector. This rule is the correct choice for a threat hunter seeking to uncover abnormal Azure subscription operations.

Just-in-Time VM access in Microsoft Defender for Cloud allows you to control inbound traffic to management ports (RDP/SSH) by enforcing approved source IPs and time windows. When an incident occurs, you can configure JIT to deny all inbound traffic to the VM, effectively isolating it from the network while the VM remains powered on for forensic collection. This non-destructive containment preserves the VM's memory, disk, and logs for investigation, unlike deletion or shutdown.

Ransomware communicates with C2 servers for key exchange.

Calling the Microsoft Graph API to set the user's accountEnabled property to false is the correct method because this property controls whether the user can authenticate. A PATCH request to /users/{id} with body {"accountEnabled": false} immediately disables the account across Microsoft 365 services, effectively blocking the user's access. This approach is also what documented playbooks for automated response recommend.

Defender for SQL is the correct cloud security plan for protecting SQL Server workloads, whether they run as Azure SQL Database, Azure SQL Managed Instance, or SQL Server on an Azure VM or on-premises server connected via Azure Arc. It includes vulnerability assessment, data discovery and classification, and advanced threat protection that generates alerts for SQL injection and unusual access patterns. Because the question asks about enhanced security features for a hybrid infrastructure involving SQL, this plan directly covers both cloud and on-premises database layers.

Cannot manage automation rules.

Connectors are the integration layer that enables Sentinel to ingest threat intelligence, alerts, and other data from external sources, and also to take outbound actions across connected systems like ServiceNow, Teams, or Azure Active Directory. In the SOAR context, connectors provide the input triggers and output actions that playbooks rely on to orchestrate response workflows beyond Sentinel's native data. Without connectors, automated response would be limited to internal Sentinel data, making them an essential component of the SOAR architecture.

Automation rules in Microsoft Sentinel respond to incident creation events, and can filter on the alert's product source being Microsoft Defender for Endpoint. Triggering the playbook this way runs the MDE API memory dump collection automatically, satisfying the requirement without manual intervention.

Microsoft 365 Defender (formerly Microsoft Defender for Endpoint) provides built-in email notification settings under Incidents & alerts, allowing you to configure email alerts for new incidents or updated severity levels. These notifications are sent directly by the Defender platform itself, using its internal alert engine to trigger the email—no external workflow or additional licensing is required. This option correctly explains the source of the email in question because Defender has native, out-of-the-box alert notification capabilities that deliver standardized incident updates to specified recipients.

This is correct because it uses the !in operator with a dynamic array literal containing the trusted IP addresses, which properly excludes any events initiated from either 10.0.0.1 or 10.0.0.2 while still capturing all other IPs performing Global Administrator role assignments. The dynamic array syntax is the proper KQL way to represent a list of values for membership testing.

Running a playbook that invokes the Microsoft Defender for Endpoint 'Isolate device' action is the correct containment response because it actively disconnects the endpoint from the corporate network while preserving a connection to the MDE cloud service for management and forensics. This action terminates all network traffic to and from the device (except low-level MDE communication), immediately stopping data exfiltration and command-and-control traffic. In Sentinel, this playbook can be triggered automatically or manually and is the only listed option that provides a network-level isolation layer.

A session policy in Microsoft Defender for Cloud Apps operates via reverse-proxy conditional access app control, giving you real-time, action-level visibility and enforcement. By setting the 'block download' action alongside other file-related controls, the policy inspects every HTTP transaction and can block a download request while still allowing viewing or other cloud-app activities. This is the only option here that directly targets downloads as a discrete action rather than toggling all-or-nothing access to the application.

The summarize operator aggregates log data, allowing you to count failed logons grouped by IP address within a five-minute bin. This produces the per-IP threshold needed to trigger the anomalous failed-logon alert in Microsoft Sentinel.

Saved custom KQL queries in the Hunting blade let analysts run reusable, scheduled or ad hoc searches across Sentinel's Log Analytics workspace, directly satisfying the requirement for a valid threat-hunting method rather than relying solely on automated analytics rules.

HackTool is the correct classification because detection ID 2147723152 corresponds to a known hacking utility, which Defender categorizes under the HackTool threat type. These tools are commonly used for privilege escalation, credential dumping, or lateral movement, and their detection is based on file signatures and behavior analytics. The alert's ID directly maps to this family, confirming the verdict.

Resetting the account's password invalidates the compromised credentials that an attacker may be using, and enabling MFA adds a second authentication layer that blocks unauthorized re-entry. This is the required remediation step before restoring the account because it directly addresses the known compromise of the identity itself. Without this step, any restoration action would leave the account vulnerable to immediate re-compromise, as existing tokens or cached credentials could still be leveraged.

The correct first step is to open the incident in Microsoft Sentinel and review its details to verify the alert is a true positive. This means checking the incident's severity, status, entities, MITRE ATT&CK tactics, and the raw data or logs that triggered the analytics rule, then correlating it with other alerts on the same resource to confirm the activity is genuinely malicious. Only after this validation should you decide whether to contain, investigate, or escalate, because taking response actions on an unverified false positive can cause unnecessary damage.

Windows Security Events are natively supported through the 'Windows Security Events via AMA' or legacy 'Windows Security Events' connector, which uses the Log Analytics agent (or Azure Monitor Agent) to collect security event logs from Windows machines. This built-in, first-party connector requires no custom development and is a standard source for detecting threats, making it one of the two correct answers.

A playbook is an Azure Logic Apps workflow and can include the Microsoft Teams connector, which enables sending an adaptive card to a designated Teams channel and using the approval action to wait for a Yes/No response from a user. This directly delivers a human-in-the-loop checkpoint that blocks subsequent steps until the approver decides, satisfying the need for approval in the incident response process. Once the response is collected, the playbook can branch to different actions based on the outcome, making it the correct mechanism for this requirement.

Threat intelligence can indicate if the IP is known malicious.

Validating the alert by checking the user's recent activity is the correct first step because it confirms whether the alert corresponds to a genuine security event, such as anomalous sign-ins, impossible travel, or suspicious mailbox activity in Microsoft Defender. By reviewing the user's sign-in logs and other evidence, you can determine the alert's true positive or false positive status, which guides all subsequent containment and remediation decisions. This triage approach aligns with incident response best practices, ensuring you act based on evidence rather than assumptions and avoiding unnecessary disruption to the user.

The built-in Anomalous Sign-in Location rule template in Microsoft Sentinel is the most direct solution. It uses Microsoft Sentinel's UEBA (User and Entity Behavior Analytics) to baseline user behavior and flag sign-ins from unusual geographic locations or IP addresses. This template is ready to enable, requires no custom KQL, and automatically maps entities and generates alerts that feed into incidents—exactly what is needed for investigating sign-in anomalies.