Microsoft Security Operations Analyst SC-200 (SC-200) — Questions 226–300

A Near-Real-Time (NRT) rule in Microsoft Sentinel evaluates the triggering query every minute with a maximum lookback of 30 minutes, using streaming analytics to preserve event ordering and timing. This enables you to catch rapid sequences of events—such as multiple failed logons immediately followed by a successful authentication—that would be missed by periodic batch processing. NRT rules are specifically engineered for low-latency, time-sensitive detections while still allowing KQL logic to match the exact pattern.

In Sentinel, the Owner field is nullable, and incidents that have not yet been assigned to an analyst or group will contain a null value rather than an empty string. When you summarize by Owner, null values are grouped into a single bucket, but KQL does not consider a null value equal to null with the equality operator (==); it requires the isnull() function to test for absence. The query likely filters with something like where Owner == null, which evaluates to false for all rows and omits the exact incidents the user intended to count, resulting in zero incidents being returned.

Basic Logs cost less per gigabyte but support only limited querying, so routing verbose, low-value sources such as firewall logs there cuts spend. Analytic Logs retain full KQL and analytics-rule support for high-value security events, meeting both cost and detection requirements.

Microsoft Defender XDR includes a unified incident queue and automated investigation and response, letting security teams manage and remediate incidents across endpoints, identities, email and cloud apps. This built-in incident management capability satisfies the requirement for a Microsoft 365 security solution that manages security incidents.

An alert rule's threshold is set in the 'Alert threshold' field under query scheduling. This defines the minimum number of query results that must be returned for a single run to generate an alert. If, for example, the threshold is 50 and the underlying query currently returns only 20 matching events, the rule will evaluate to 'low' instead of firing and no alert will be created. This can be verified by manually running the rule's query in Log Analytics—if results are present but below the threshold, the misconfiguration is exactly this.

Running the analytics rule's KQL query directly in Log Analytics is the correct first step because it isolates whether the problem lies in the rule logic or in the downstream alert/incident pipeline. By executing the exact query with the same time range and filters, you can see if any rows are returned; if none are, the rule will never fire regardless of its other settings. If the query does return data, then you should examine the rule's alert creation, incident settings, and run history. This approach provides concrete evidence and prevents you from blindly altering configuration.

An automated investigation and remediation rule in Microsoft Defender XDR can define precise conditions to match the legacy application's characteristic behavior, such as specific process names, users, or IP addresses, and then automatically take an action like closing or suppressing the alert. This works directly at the XDR layer, addressing the root cause of the false positive without modifying the underlying detection query or disabling broader threat visibility. It is the intended, scalable approach for recurring harmless patterns, requiring no manual intervention once configured.

EmailEvents carries the core mail flow metadata—sender, recipient, subject, and delivery timestamp—but no attachment details; EmailAttachmentInfo provides AttachmentFileName and references the parent email through NetworkMessageId. Joining these tables on NetworkMessageId lets you count how many times a given attachment name reached a specific AccountUpn, and binning Timestamp every 1h reveals temporal bursts. This is the correct combination because only this pair supplies both the recipient identity and the file name in the same logical context.

True positive is one of the two valid incident classification categories in Microsoft Sentinel. You select this classification when investigation confirms the alert correctly identified a real security threat. Applying True positive is important because it enables accurate reporting on detection effectiveness and helps tune analytics rules for future incidents. It must be paired with the incident status 'Closed' (or 'Resolved') in the classification workflow.

DeviceNetworkEvents records network connection events from onboarded endpoints, including DNS query details and remote addresses. This makes it the primary table for spotting DNS tunnelling patterns such as high-volume or encoded queries to suspicious domains.

Sentinel workspace manager's incident replication feature is the native, built-in mechanism that replicates incidents from multiple workspaces to a central workspace, providing a single pane of glass for SOC triage. It maintains a one-way copy of incident metadata and status in the central workspace, enabling centralized metrics, queries, and automation without altering the original incident. This is the recommended method over custom exports or cross-workspace queries because it is purpose-built for incident aggregation and requires no manual pipeline.

An activity policy is designed specifically to monitor user sign-in and app activity events, and it allows you to define custom behavioral conditions using filters, thresholds, and time windows. For example, you can create a policy that alerts when a user performs more than N file downloads within a set number of minutes, then automatically respond by suspending the user or requiring re-authentication. This matches the requirement for a custom threshold on download volume.

Automation rules are the native orchestration feature in Microsoft Sentinel that let you define conditions and actions executed when an incident meets predefined criteria. By setting the trigger type to 'When incident is created,' the rule fires immediately upon incident generation, and you can configure it to run a playbook, change the incident status, assign ownership, or add tasks. This is the correct and intended mechanism for automatically invoking a playbook at incident creation time.

A playbook in Microsoft Sentinel is an Azure Logic Apps workflow that can perform actions such as updating the incident owner and sending a Teams message. By attaching this playbook to an automation rule, the rule triggers the playbook when incidents meet specific conditions (e.g., creation, severity, or status change), automating the assignment and notification. This is the correct approach because automation rules are designed to run playbooks as incident-triggered actions, and the playbook can use the 'Update incident' action to set the owner.

Activity policies in Microsoft Defender for Cloud Apps evaluate user activity against thresholds, such as mass file downloads from SharePoint Online within a defined period. They generate alerts or governance actions directly on the activity stream, matching the download-volume scenario.

The email entity page is the correct destination because it consolidates the full message record from Microsoft Defender for Office 365, including delivery status, threat name, detection technology, and the recipient-specific URL click verdict. Its Click details section explicitly indicates whether each intended recipient clicked the link, whether the click was allowed or blocked, and the time of the click, which is exactly the evidence needed to assess the impact of a phishing alert. This page is purpose-built for single-message triage and provides near-instant visibility without requiring a custom query or cross-referencing multiple data sources.

authenticationRequirement is a sign-in log property that directly specifies the authentication strength required for the sign-in, such as singleFactorAuthentication or multiFactorAuthentication. In a brute force scenario, checking this field helps you determine whether the attacker only needed a valid password or whether they also had to satisfy an MFA challenge to succeed. This is the right field to inspect because it answers the exact question of which authentication type was used to access the account.

Device isolation via Microsoft Defender for Endpoint immediately cuts network communication while preserving forensic evidence, halting ransomware spread across endpoints. It addresses the active encryption behaviour first, before investigating the MDI service account logins, containing the threat fastest.

This sequence is correct because Microsoft Sentinel is built on top of a Log Analytics workspace; the workspace must be provisioned before Sentinel can be enabled. Enabling Sentinel on each regional workspace first ensures that the data connectors have a valid destination and can immediately begin ingesting and normalizing logs. Once all regional workspaces have Sentinel active, you can configure cross-workspace queries to unify monitoring while preserving data residency, which is the recommended pattern for multi-region deployments.

Microsoft 365 Defender alerts are a legitimate incident source when you have the Microsoft 365 Defender data connector enabled in Sentinel. This connector automatically ingests high-fidelity alerts from Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps. The connector's incident creation setting then creates an incident each time one of these alerts is ingested, plus any related alerts are grouped into the same incident.

The Microsoft Entra ID data connector ingests sign-in and audit logs into Microsoft Sentinel, supplying the identity events UEBA analyses for anomalous behaviour detection. Enabling it is required before UEBA can surface risky sign-in activity.

Defender for SQL is the correct plan because it is the Defender for Cloud plan specifically designed to secure SQL databases, including Azure SQL Database. It provides threat detection for SQL injection attempts by monitoring database query patterns and comparing them against known attack signatures and anomalous activity. This plan also surfaces recommendations like vulnerability assessment findings and configuration weaknesses, making it the direct source for SQL injection alerting against PaaS SQL databases.

Automation rules can invoke playbooks, which are Azure Logic Apps workflows, as an automated response when an incident is created or updated. The run playbook action lets you enrich, notify, investigate, or remediate without manual intervention. Playbooks triggered by automation rules require a connection with the appropriate permissions in the resource group.

Disabling the account and resetting the password immediately contains the active compromise, satisfying the stem's priority of stopping ongoing malicious access before deeper forensic scoping. This neutralises the attacker's session and credentials, preventing further sensitive file exfiltration while investigation continues in Microsoft Sentinel.

Playbooks based on Azure Logic Apps are the execution component that actually performs automated response actions in Microsoft Sentinel. These playbooks represent the procedural logic—such as isolating a compromised host, resetting credentials, or enriching an incident—by calling APIs and orchestrating Azure services. Without a playbook, an automation rule has no substantive task to run, so playbooks are a required foundation for enabling security automation.

DeviceNetworkEvents is the correct source because it records every network connection attempt and established session at the device level, including the remote IP address, remote port (e.g., 3389 for RDP), protocol, and the process that initiated the connection. This table directly surfaces the outbound or inbound network flows that constitute lateral movement over RDP, enabling an analyst to trace which endpoint connected to which target and when. Unlike other event tables, DeviceNetworkEvents preserves both direction and destination details, which are essential for reconstructing lateral movement paths.

Microsoft Defender for Cloud's overview page is the correct destination because it aggregates security posture across all enrolled subscriptions in a single pane. It displays the overall secure score, the number of active recommendations, and actionable security alerts, all filtered by the current management-group or subscription scope. This gives a security administrator an immediate, at-a-glance measure of the organization's cloud defense posture.

Automated investigation and response (AIR) is a built-in capability of Microsoft Defender XDR that self-executes security investigations triggered by alerts, applying algorithms to examine evidence like files, processes, and network communications. It automatically takes corrective actions, such as isolating devices or blocking malicious indicators, and records findings for analysts. AIR reduces alert fatigue by containing threats with minimal human intervention.

This query correctly links the user's interactive logon on a device to subsequent outbound RDP traffic to port 3389 from that same device. The timestamp filter ensures the network event occurred after the logon, proving the user (or attacker) established an interactive session before initiating the remote desktop connection. This temporal and device-based correlation is the essential pattern for detecting lateral movement via RDP.

The rule flags encoded PowerShell outside System32, but legitimate 32-bit processes launch from SysWOW64, which the path exclusion omits. Adding SysWOW64 to the exclusion list removes those benign executions, addressing the false positives described in the stem.

Running a script via Azure Arc to disable the network interfaces is a network-based containment action that immediately cuts off all inbound and outbound traffic on the server. By using the Azure Arc 'Run Command' or a custom script extension, the server's NICs are brought down, which blocks data exfiltration, lateral movement, and command-and-control communication with the attacker's infrastructure. This preserves the machine in its current state for forensic analysis while the fileless malware is isolated from the rest of the network. It is an effective first response because it neutralizes the attacker's ability to communicate without disabling management channels.

To enable Microsoft Copilot for Security to access Sentinel incident data, you must integrate the Microsoft Defender XDR tenant (which serves as the identity and data plane) with Copilot for Security. This integration establishes the required permissions and data flow, allowing the Copilot to retrieve and analyze security signals from Sentinel. Without this tenant-level integration, Copilot cannot authenticate to Sentinel workspaces or access their incidents, even if other components are correctly configured.

Domain controllers generate the Security events, but AMA forwards them over HTTPS to the Log Analytics ingestion endpoint. If outbound connectivity to the required URLs is blocked, events silently fail to reach LAW-Security despite correct DCR configuration.

Automation rules in Microsoft Sentinel can be configured to trigger on alert creation and use conditions such as alert name or severity to automatically assign incidents to a specific team via the "Assign owner" action. This satisfies the stem’s constraint of routing incidents based on alert type without requiring manual triage or separate playbook logic.

Microsoft Defender for Endpoint's automated investigation leverages behavioral analytics and threat intelligence to immediately scope a ransomware incident, identifying all affected files, processes, and user accounts in parallel while containing the threat. Because it executes investigation playbooks automatically and can trigger containment actions such as device isolation or indicator blocking, it is faster than manual triage and preserves forensic context for the incident graph. Initiating automated investigation is the recommended first step in Defender for Endpoint because it converts a suspected outbreak into a scoped, machine-readable set of evidence.

To assign incidents to teams based on a team name, you can first configure custom details in the analytics rule to extract the team name from the alert into a custom property on the incident. Then, in the automation rule, you can create a condition that checks this custom detail and set the incident owner accordingly. This approach works because automation rules can only evaluate incident properties, so custom details bridge the gap when the team is not a standard incident field.

Incorporating threat-feed indicators of compromise lets queries match observed malicious artefacts—IP addresses, domains, file hashes—against telemetry already ingested in Microsoft Sentinel, satisfying the stem's requirement for effective hunting queries. This converts external threat intelligence into concrete detection logic, surfacing known adversary infrastructure without waiting for an alert to fire.

The playbook is correctly triggered but fails because it references 'alertRuleId' as the IP address. In Sentinel alert payloads, alertRuleId is merely the identifier of the analytics rule that generated the alert, not a network entity. The IP address must be extracted from the 'Entities' collection of the incident, specifically from an entity with type 'IP' (e.g., Entities.IP.address). Passing a non-IP string to a block action causes input validation failure, so the playbook cannot block the address.

Office 365 audit logs capture Exchange mailbox rule creation and modification events, including Set-InboxRule operations that forward mail externally. Querying this source in Microsoft Sentinel surfaces users who configured external forwarding, matching the exfiltration hunt.

Automation rules in Microsoft Sentinel can trigger playbooks based on incident conditions, including tags. You can create a rule that evaluates the incident's tags and, if the 'Compromised User' tag is present, runs the specified playbook. This is the correct method to automatically execute a playbook when an incident with a specific tag is created. It provides the required automation without manual intervention.

Microsoft Defender for SQL is the specialized plan that secures Azure SQL Database, Azure SQL Managed Instance, and SQL Server on Azure VMs/on-premises through Defender for Cloud. It combines advanced threat protection with SQL injection detection, anomalous access-pattern alerts, and vulnerability assessments at the database layer. This is the only plan among the choices that is designed to protect a SQL database and surface database-specific recommendations.

In Microsoft Sentinel, the 'Owner' field (also displayed as 'Assigned to' in the incident details) identifies the single user who is currently responsible for investigating and managing the incident. When a user's name appears in this field, it means that user has been assigned the incident, either manually through the 'Assign owner' button or automatically via an automation rule. This assignment is used for tracking ownership, routing work, and reporting on investigation progress, and it is the direct answer to the question of who is handling the incident. Therefore, a user in that field indicates the incident is assigned to that user for investigation.

join is correct because the KQL join operator correlates rows from two tabular expressions on one or more equality conditions (keys), returning rows that contain columns from both sides. For example, joining SigninLogs with AADAuditLogs on UserId or IP address lets you see a logon event and the subsequent activity side by side, which is exactly the kind of key-based matching needed when hunting across heterogeneous data sources. You can control the output with join kinds such as innerunique, inner, leftouter, and rightouter to tailor the hunt to your hypothesis.

Windows Security Events via AMA stream logon events such as 4624, 4625 and 4672, which expose brute-force, pass-the-hash and privilege-escalation patterns. Ingesting these satisfies the credential-theft detection requirement by feeding Sentinel analytics rules that correlate suspicious authentication behaviour on Windows hosts.

Automation rules in Microsoft Sentinel include a built-in action that updates the incident severity field. This action can be triggered conditionally, for example when an incident is assigned a MITRE technique or when entity analytics raise the risk score. Because severity directly drives triage priority in the SOC queue, being able to auto-adjust it based on changing context is a core incident-response action, making this a correct answer.

An automation rule can be triggered on incident creation and invoke a playbook built in Azure Logic Apps. The playbook queries the Microsoft Sentinel API (security insights 'Incident' resource) to retrieve all active incidents, counts the open assignments per analyst, determines the analyst with the fewest open incidents, and then updates the incident owner using an action such as 'Entity Incident Management' or an HTTP call to the API. This provides dynamic, workload-aware assignment that static configuration cannot.

An automation rule with an incident creation trigger can invoke a playbook that uses Logic Apps and the Microsoft Entra ID connector or Graph API to read the incident's user entity and retrieve their directory role assignments. The playbook can then call the 'Update incident' action to set the severity to a higher value if the user holds a privileged role, such as Global Administrator. This approach is purpose-built for incident lifecycle management and provides real-time, agentless enrichment without altering detection logic.

DeviceRegistryEvents is the correct answer because it is the dedicated advanced hunting table for registry changes, recording event types such as RegistryValueSet, RegistryKeyDeleted, and RegistryValueDeleted. Each event includes the affected RegistryKey, RegistryValueName, RegistryValueData, and the initiating process with its command line. This schema allows the analyst to directly link a specific registry modification to the process that performed it, which is the core requirement of this investigation.

Mapping entities correctly ties alerts to the right accounts, hosts and IP addresses, so Microsoft Sentinel correlates activity accurately and stops unrelated events triggering the rule. This directly reduces false positives by ensuring entity-based logic matches genuine incidents.

Custom log tables in Microsoft Sentinel have a fixed schema defined at creation (via DCR, custom log API, or saved as a table). When the incoming log records contain fields that do not match this defined schema — such as a different column name, wrong data type, or extra fields that are not in the table — the Log Analytics ingestion pipeline validates each record and rejects the entire record during parsing. This causes the logs to be silently dropped before they can be indexed, so you see missing custom log data even though connectors and workspace health are normal.

A brute force attack on user accounts is the correct classification because high-risk sign-ins reflect patterns such as repeated failed password attempts, impossible travel across many accounts, or logins from known malicious IPs—all hallmarks of password guessing or credential stuffing. Sentinel analytics rules that aggregate risk signals from Microsoft Entra ID Protection will generate a single incident when multiple users experience elevated sign-in risk, which matches a coordinated brute-force or password-spray attack rather than a targeted compromise.

An automation rule triggers a playbook on incident creation, and the playbook calls Defender for Endpoint and Microsoft Entra ID actions to isolate devices and disable accounts. This satisfies the containment requirement without manual intervention.

The Alerts tab is the correct location because it aggregates all individual security alerts that Microsoft 365 Defender correlation logic has grouped into the incident. This tab provides a unified, chronological list of detections from workloads such as Defender for Endpoint, Defender for Office 365, and Defender for Identity, including each alert's severity, status, and investigative priority. Analysts use this tab to identify the full attack chain and determine which alerts warrant immediate action, making it the authoritative alert list for the incident.

The lookup operator enriches a fact table by pulling values from a dimension-style table based on equality of specified keys, using left-outer semantics that preserve the left side's row count and only add columns. This is essential in threat hunting for attaching authoritative context—such as user names, asset owners, or threat-intel tags—to raw events without the risk of row multiplication. Unlike join, lookup is optimized for dimension-style, one-to-many enrichment and is a common choice when the goal is to decorate events with descriptive attributes.

The investigation graph in Microsoft Sentinel renders entities such as IP addresses, users and hosts as connected nodes, exposing relationships and lateral movement paths visually. This satisfies the requirement to visualise entity relationships during incident investigation, unlike log queries or workbooks.

Adding the VPN IP range to Defender for Cloud Apps trusted IP addresses suppresses impossible-travel detections originating from those addresses, since the engine treats trusted ranges as known-good locations. This directly addresses the confirmed false positive caused by VPN egress, preventing recurrence for this user without disabling the detection policy itself.

Scheduled analytics rules are the correct vehicle for matching sign-in events against a custom threat intelligence watchlist. In a scheduled rule’s KQL query, you can use the _GetWatchlist() function or a watchlist alias to join SigninLogs with known malicious IPs, generating alerts whenever a match occurs. This is a straightforward, deterministic indicator-based detection that fits scheduled-rule logic perfectly.

In Defender for Cloud Apps, investigation involves reviewing the app's cloud app catalog risk score, which includes factors such as data sharing, authentication methods, and compliance certifications, alongside actual user activity like sign-in events, file access, and IP addresses. This allows security analysts to differentiate unsanctioned but benign applications from those posing genuine threats such as credential theft or data exfiltration. By correlating risk factors with usage patterns, an analyst can make an informed governance decision—whether to sanction, alert, or block—without interrupting business continuity.

The workspace() expression in Kusto Query Language allows you to reference a table in another Log Analytics workspace by appending the workspace resource ID or name to the table name, such as `union workspace('workspace1').SignedInLogs, workspace('workspace2').SignedInLogs`. This enables a single KQL query to span multiple Microsoft Sentinel workspaces, which is exactly the capability you need to search for threats or aggregate data across all your workspaces.

A Microsoft Sentinel playbook, powered by Azure Logic Apps, can directly interact with Microsoft Entra ID to manage user accounts. By calling the Microsoft Graph API within the playbook, specifically the Users endpoint to update a user's properties, the `accountEnabled` attribute can be set to `false`. This precise technical mechanism allows the playbook to automatically disable the user account in Microsoft Entra ID, directly fulfilling the requirement to block the user's account upon a high-severity incident.

The correct choice is DeviceNetworkEvents because this table captures outbound network connection attempts and established connections, recording the destination IP, port, protocol, and the initiating process's ID and name. In a ransomware investigation, this table reveals the process that communicates with attacker-controlled infrastructure, enabling the analyst to map lateral movement or identify the ransomware's beaconing behavior. Unlike process creation logs, this table specifically correlates each connection to the process that made it, which is essential to confirm the malicious process's network activity.

This is correct because Sentinel integrates with Azure Logic Apps to create playbooks—workflows that can perform actions like sending email via the Office 365 Outlook connector. An automation rule can be configured with a condition for high-severity incidents and an action to run a playbook, which automatically executes the email-sending workflow when an incident is created. This provides the fully automated notification mechanism required, with no manual steps.

A Microsoft Sentinel analytics rule must be deployed using either 'Microsoft.OperationalInsights/workspaces/scheduledQueryRules' (for scheduled rules) or 'Microsoft.SecurityInsights/alertRules' (the Sentinel-native provider). The template declares 'Microsoft.OperationalInsights/workspaces/savedSearches', which only stores a KQL query in the Log Analytics workspace and does not trigger any alert or incident logic. Because the resource type is wrong, nothing appears under the Analytics Rules blade in Sentinel; this is the root cause of the deployment's apparent failure.

EmailEvents is the correct choice because it is the primary Microsoft 365 Defender advanced hunting table that stores email message-level metadata, including the sender (From), recipient (To), subject, delivery status, and critical identifiers like NetworkMessageId and InternetMessageId. When investigating an email-related incident, this table provides the authoritative record of the email's header and routing details, enabling correlation of delivery and threat actions.

Using the 'Block' governance action in Defender for Cloud Apps immediately terminates the flagged session via the session proxy and prevents new access from that session, while the full activity log is preserved for forensic review. This action is applied manually from the user or activity page and takes effect instantly, unlike policy-based controls. It is the appropriate granular containment that stops only the suspicious session without disabling the user account.

Microsoft Defender for Endpoint supplies the device telemetry that Sentinel's advanced hunting and C2-related tables query. Without onboarding, those devices emit no events, so the KQL query returns nothing despite the malicious IPs being active.

Applying a time filter (e.g., where Timestamp between datetime(...) and datetime(...)) restricts the query to only the relevant time range, which directly reduces the number of records scanned. Kusto queries are highly optimized for time-based sharding, so narrowing the window lets the engine skip entire extents that fall outside the filter. This is the most effective first step because it reduces I/O and CPU cost at the source, before any other processing or aggregation occurs.

The incident page in Microsoft Sentinel provides fields for owner (Assign to) and status (New, Active, Closed). Setting the owner to the specific analyst and changing the status to Active assigns the incident and moves it into the active workflow, making it appear in their queue. This directly fulfills the requirement to assign and activate the incident for the analyst.

With 'Single alert per run' and grouping enabled, the rule generates one alert per scheduled run, and the alert grouping engine then combines all alerts produced during the 1-hour grouping window into a single incident. This prevents duplicate incidents for recurring detections within that window, consolidating related alerts so analysts investigate one incident instead of many. It also preserves the ability to see the full scope of activity within the incident.

EmailEvents is the correct table because it stores the metadata for every email message processed by Microsoft 365, including the InternetMessageId header that uniquely identifies a particular message. Querying on InternetMessageId lets an analyst retrieve every row for that message, and each row contains RecipientEmailAddress, so aggregating those rows lists all recipients of the phishing email. This table also includes subject, sender, and delivery status, making it the central starting point for email incident investigation.

This is correct because Azure AD returns ResultType 50057 specifically when a user attempts to sign in with an account that has been disabled by an administrator. The KQL query filtering on this ResultType will surface every such attempt, regardless of whether the provided password is accurate. Disabled accounts cannot authenticate at all, so these events represent a clear account-state failure rather than a credential mismatch.

An automation rule with the 'Assign incident' action runs on incident creation, setting the owner to the senior analyst on duty. This directly satisfies the automatic assignment requirement, as analytics rules detect incidents but cannot assign ownership themselves.

Defender for Cloud continuously assesses hybrid workloads against security baselines using Azure Policy and industry benchmarks to identify misconfigurations such as open management ports, unencrypted data stores, or weak network security group rules. It also aggregates missing update data from Azure VMs and Azure Arc-enabled on-premises servers, integrating with update management services to produce prioritized, actionable recommendations. These recommendations help administrators remediate posture gaps in a centralized portal.

Automation rules in Microsoft Sentinel evaluate incident creation and can invoke a playbook conditionally. Scoping the trigger to incidents whose alert product is Defender for Cloud Apps ensures the suspend-user playbook runs automatically on those incidents.