CCNA Design security operations, identity, and compliance capabilities Questions

Session policies, part of Conditional Access App Control, route user traffic through Defender for Cloud Apps as a reverse proxy, allowing synchronous inspection of each request and response. The proxy can evaluate conditions like device compliance, user risk, or file sensitivity and then block, allow, or restrict actions — including preventing uploads to unsanctioned apps before the request is passed through. This real-time inline enforcement is exactly what the scenario requires, making session policy the correct choice.

A DLP policy is the correct control because it combines detection of a sensitive info type (credit card number uses patterns plus Luhn checksum validation) with a condition that the content is shared externally, and then enforces a blocking action. When you create a DLP policy in the Microsoft Purview compliance portal, you select the credit card number detector, scope it to Exchange/SharePoint/OneDrive, and set the rule to block access or block sending before the content leaves your tenant. This is the only option that directly prevents unauthorized external sharing while also providing user overrides and incident alerts.

Session controls in Microsoft Defender for Cloud Apps enforce real-time monitoring and control of user sessions via a reverse proxy. They allow organizations to apply granular access policies on cloud apps, such as preventing downloads, blocking access to sensitive files, or requiring step-up authentication. Session controls operate at the data plane level, evaluating user activity as it happens, and are often triggered by Conditional Access policies from Microsoft Entra ID.

Enabling UEBA in Microsoft Sentinel gives threat hunters behavioral baselines for users, hosts, and applications. By leveraging machine learning to detect anomalies such as unusual sign-in patterns or lateral movement, UEBA surfaces high-fidelity leads. This enriches entities in hunting queries with risk scores and behavioral insights, making detection of insider threats or compromised accounts far more effective.

Fusion is a built-in analytics rule in Microsoft Sentinel that leverages machine learning to correlate security alerts from multiple products—such as Microsoft Defender for Endpoint, Defender for Identity, and Defender for Office 365—into a single incident. It is specifically designed to detect advanced multi-stage attacks, including APTs, by analyzing cross-source alert relationships and timestamps. This makes Fusion the correct answer because it uniquely uses ML for multi-source correlation and APT detection.

Microsoft Defender for Endpoint is a foundational component of Microsoft Defender XDR (formerly Microsoft 365 Defender). It delivers endpoint detection and response (EDR), vulnerability management, and attack surface reduction capabilities, sharing signals with the unified XDR pipeline to enable cross-domain threat correlation and automated response.

A retention label is the Purview mechanism that directly enforces retention and deletion behavior on documents, emails, and other content. By creating a retention label with a 7-year retention period and publishing it (or auto-applying it), the organization ensures the record remains immutable and un-deletable during that period, and the label can also trigger a disposition review at expiration. This aligns with regulatory requirements for retaining records. Thus, it is the correct action to preserve the records for the mandated timeframe.

Conditional Access policies are the access-control layer that evaluates the device's compliance state at sign-in. When combined with an Intune compliance policy, the 'Require device to be marked as compliant' grant control forces Azure AD to check the device's compliance status and block access if the device is non-compliant. This is the correct approach because it directly enforces the access requirement for corporate resources, unlike enrollment or configuration policies that only manage settings or enrollment.

Connecting AWS and GCP accounts to Defender for Cloud surfaces those resources in Azure Resource Graph, where Azure Policy can apply the Microsoft Cloud Security Benchmark (MCSB), a unified initiative built on CIS/NIST plus Microsoft controls. This gives continuous compliance assessment and enforcement, like DeployIfNotExists remediation, across all clouds. As a result, every subscription or cloud account is measured against the same baseline, regardless of native cloud tooling—this is the only option that both centralizes and enforces a single baseline.

A Microsoft Purview account is the correct choice because it provides an automated, unified data governance solution that scans and catalogs metadata from all data sources, including on-premises, Azure, AWS, Google Cloud, and SaaS applications. This enables centralized data discovery, classification, lineage, and policy enforcement. Unlike legacy or single-purpose tools, it creates a comprehensive data map for the entire organization.

Endpoint data loss prevention (Endpoint DLP) is the correct choice because it installs an agent on Windows and macOS endpoints that inspects data in real time as users interact with files. It can enforce policies to block the copying of sensitive items, such as those matching sensitive info types or trainable classifiers, to removable USB devices, and optionally show a policy tip to the user. This direct, pre-action enforcement provides the precise control needed to prevent data leakage via USB.

Microsoft Purview Audit is the correct solution because it provides a unified audit log that records user and admin activities across Microsoft 365 services, including file access, permission changes, and sign-ins. Organizations can search and export these audit records from the Purview compliance portal or via Office 365 Management Activity API, enabling security teams to investigate incidents and meet compliance requirements. This capability directly addresses the need to audit user activities.

Lifecycle workflows in Microsoft Entra ID Governance automate joiner, mover, and leaver tasks based on events or schedules. A leaver workflow can disable the account, remove group and application assignments, and send notifications to the manager, which matches the requirement to revoke access immediately and notify the manager without help desk involvement.

Entra ID Protection (P2) uses machine learning to continuously evaluate sign-in and user risk, assigning risk levels and enabling Conditional Access to require MFA or block high-risk attempts. Sentinel then ingests these risk detections, along with other identity logs, into a central SIEM that provides long-term retention, advanced hunting through KQL, and analyst workflow for investigation. Together they deliver both the real-time detection and the centralized visibility needed by a global financial services security team.

A Microsoft Intune device compliance policy defines the exact security and configuration standards that a device must meet to be considered compliant, such as requiring encryption, a minimum OS version, no jailbreak/root, or a healthy threat agent score. The policy assigns a compliance state (compliant/non-compliant) for each enrolled device, and that state is then published to Entra ID. This policy is the foundation of device-based access control because it establishes the authoritative criteria that determine whether a device should be trusted.

Playbooks are Azure Logic Apps workflows that can be automatically invoked by automation rules to perform enrichment operations on an incident, such as querying Threat Intelligence platforms like MISP or Microsoft Graph Security API. By pulling threat intel about involved entities (IPs, hashes, domains) and writing those findings back to the incident, playbooks give analysts and automated rules the context needed to rapidly triage and prioritize low-severity incidents without manual querying.

Microsoft Defender XDR unifies signals across the Microsoft 365 ecosystem—Defender for Endpoint, Office 365, Identity, and Cloud Apps—into a single incident queue with automated investigation and response. It correlates kill-chain events across domains, enabling security teams to monitor and respond to threats holistically. This cross-domain correlation and built-in response automation are exactly what is required for organization-wide threat monitoring and response.

A compliance policy in Intune evaluates a device's health attributes—including whether its OS version meets the minimum required for that platform—and simply marks the device compliant or non-compliant. That compliance status is then consumed by a Conditional Access policy as a grant control, which, at the time of every authentication request, rejects access for non-compliant devices (or requires additional steps like re-enrollment or OS update). This combination is the actual enforcement chain: the compliance policy identifies the OS-version gap, and Conditional Access blocks the user's access accordingly.

Sensitive information types detect content patterns such as credit card or national insurance numbers, so Microsoft Purview Information Protection can auto-apply labels without user input. This satisfies the requirement for automatic, content-based labelling rather than manual or default labelling.

A Conditional Access policy is the correct approach because it uses application-based conditions to require MFA selectively for sensitive apps while allowing other apps to use less restrictive authentication. In a hybrid environment, this integrates with on-premises applications via Azure AD Application Proxy or federated trusts, and supports session controls like sign-in frequency. This granularity aligns with the Zero Trust principle of least privilege, unlike tenant-wide or user-wide MFA enforcement.

Requiring multi-factor authentication for all users directly enforces the zero-trust principle of verify explicitly, ensuring every sign-in is validated rather than trusted by network location. It satisfies the stem's identity-strategy constraint by adding a possession factor to credentials, blocking compromised-password attacks that single-factor authentication would otherwise permit.

The 'AgentlessVmScanning' extension cannot be declared as a child property of the Microsoft.Security/pricings resource. In Azure Resource Manager (ARM) and Bicep, agentless scanning for virtual machines is enabled by defining a separate resource of type Microsoft.Security/vmScanners, which holds the scanner configuration such as 'scanningMode' and exclusion tags. Attempting to place it within the pricing resource's properties.extensions array will cause a validation error because that extension is not a valid member of the pricing schema. Therefore, the deployment fails unless the extension is moved to its own top-level resource definition.

Automation rules in Microsoft Sentinel are event-driven orchestration mechanisms that evaluate newly created or updated incidents against configured conditions—such as severity or name—and then execute one or more linked playbooks automatically. Playbooks are Azure Logic Apps that can perform remediation steps like isolation, data collection, or notification, ensuring consistent, immediate response without human involvement. This is the only approach listed that satisfies 'automatically' while honoring incident context, since automation rules trigger exactly when incidents are created or changed.

Anomaly detection policies in Defender for Cloud Apps use behavioral analytics and machine learning to baseline normal user activities and trigger alerts for deviations, including impossible travel, unfamiliar sign-in properties, and multiple failed sign-ins. These policies are specifically tailored to identify suspicious location-based behavior, such as sign-ins from geographically distant locations in a short time span, making them the correct choice for alerting on unusual user location patterns.

Isolating affected devices with Microsoft Defender for Endpoint is the immediate containment step. Device isolation severs network connections, including inbound and outbound traffic, preventing ransomware from spreading laterally while still allowing the security team to collect forensics via the MDE sensor. The error message displayed to the user can be customized, but the action itself blocks SMB, RDP, and other communication channels.

The AWS S3 bucket is the core storage location where AWS CloudTrail writes all of its JSON log files. The Microsoft Sentinel AWS connector is built specifically to read these log objects from the S3 bucket, parse the CloudTrail records, and send them to the Log Analytics workspace. Without this bucket there would be no source for the connector to ingest, making it an essential requirement.

A device compliance policy in Microsoft Intune is the correct mechanism because it defines the rules that a device must satisfy to be considered compliant, including required OS versions, encryption, password complexity, and threat-level results from Mobile Threat Defense. Once assigned, the Intune service evaluates each device against those rules, assigns a remediation status, and reports the compliance state to Microsoft Entra ID for Conditional Access to block non-compliant devices.

Configuring automated investigation and response (AIR) in Microsoft Defender for Endpoint enables the security solution to automatically run playbooks when alerts are triggered. These playbooks investigate the scope of the threat, contain the attack (e.g., isolating devices, blocking processes), and remediate the issue without manual intervention. AIR is the only listed option that directly addresses the requirement for automated response, because it integrates detection, investigation, and containment into one workflow.

Session policies can block data exfiltration in real time.

This is the correct answer. The KQL rule filters for EventID 4625 (failed logon) and performs a summarize count() by Account over a 5-minute sliding window, alerting when an account's failure count exceeds 10. More than 10 failed logons for the same account within 5 minutes is a strong indicator of an automated brute-force attack, where an attacker tries many password variations against a single user account. The aggregation by Account ensures the alert is specific to one targeted account rather than distributed across users.

The 'Require device to be marked as compliant' grant control is correct because Intune compliance policies evaluate the device's configuration, health, and security posture. In Conditional Access, this control blocks access unless the device meets the specific compliance criteria defined in Intune, such as encryption, patch level, and threat detection. It ensures a device-level trust boundary before granting access to corporate resources, making it the appropriate device compliance control.

A device compliance policy in Intune can require TPM 2.0 as a compliance rule, and when paired with a Conditional Access policy that requires the device to be marked as compliant, it actively blocks access for non-compliant devices at the time of the resource request. This works as an ongoing access gate, re-evaluating compliance signals on every authentication, so devices missing TPM 2.0 are denied access immediately. That is exactly the intended mechanism for enforcing hardware security baselines on Windows 10 endpoints.

Purview provides sensitivity labels.

Privileged Identity Management (PIM) in Microsoft Entra ID is the service that provides just-in-time (JIT) privileged role activation. PIM allows an eligible user to activate a role for a limited time, optionally requiring approval, multi-factor authentication (MFA), and justification, and it records the activation in the audit log. This directly matches the requirement to create a workflow for role activation that includes human approval, thereby making PIM the correct answer for controlling privileged access activation.

A Conditional Access policy in Microsoft Entra ID that includes the 'Require device to be marked as compliant' grant control is the direct integration point with Intune compliance. During authentication, Entra ID evaluates the device's compliance status and blocks sign-in if the device is non-compliant or not enrolled in Intune. This policy is the actual enforcement layer that translates the Intune compliance assessment into an access decision, making it the correct solution to block access from non-compliant devices.

Microsoft Purview eDiscovery (Premium) is the correct tool because it combines robust content search with legal hold capabilities across Microsoft 365 workloads. A case can use keyword queries (including regex for credit card numbers) to locate Teams messages, and a litigation hold can then be applied to the user's Exchange mailbox—where Teams chat messages are actually stored—as well as to Teams site data. This satisfies both the need to find every instance of credit card numbers and the need to preserve that content immutably for eDiscovery.

Microsoft Purview Information Protection (IP) enables automatic classification and labeling by using sensitivity labels that can be applied based on content. Through built-in sensitive information types (e.g., credit cards, PII), trainable classifiers, or exact data match, service-side auto-labeling can scan documents and emails in Exchange Online, SharePoint Online, and OneDrive, then apply appropriate labels and optional encryption. This directly satisfies the need to automatically classify and label sensitive data, and it is the correct solution for the requirement.

Microsoft Entra Connect is the primary, purpose-built tool for synchronizing on-premises Active Directory identities to Microsoft Entra ID. It replicates user, group, and device objects, and supports password hash synchronization, pass-through authentication, and federation integration. As the successor to DirSync and Azure AD Sync, it's the standard first-party solution for hybrid identity, and it is the correct choice when a straightforward, sanctioned sync mechanism is required.

The policy's conditions combine all users with a sign-in risk level of high, and its grant control is block. Because no exclusions or other risk levels are scoped, every user is denied access whenever Microsoft Entra ID detects high sign-in risk.

The Microsoft Defender for Identity connector is the dedicated data connector designed to import MDI alerts into Microsoft Sentinel. It leverages the Microsoft 365 Defender data export model, pulling MDI-generated security alerts so they can be correlated with other Sentinel data. This is the only connector in the list whose native purpose is to ingest MDI alert telemetry, making it the correct choice for this scenario.

An automation rule is the correct answer because it provides the incident-level response engine within Microsoft Sentinel. It evaluates configurable conditions (such as severity, tag, or entity properties) and then executes actions automatically—including triggering a playbook, changing incident status, assigning an owner, or adding tasks—without human intervention. Because it runs on every matching incident at creation or update, it directly implements the required automated response to Sentinel incidents.

The query groups high-severity alerts by CompromisedEntity and then filters the resulting aggregation to retain only entities with an `AlertCount > 5`. This directly identifies entities—such as users, hosts, or accounts—that have been hit by more than five high-severity alerts, indicating a pattern of repeated targeting. The `summarize` operation plus the having clause on the aggregated count is classic for detecting brute-force or persistent attack victims.

Compliance Manager ships with a pre-built PCI DSS v3.2.1 or v4.0 assessment template that maps each requirement to customer actions and Microsoft-managed controls. Opening that assessment shows per-control status (e.g., Completed, In progress, Not started), implementation and testing evidence, ownership, and corrective actions. This is the direct, supported UI for monitoring PCI DSS compliance posture, and the status reflected is exactly what an auditor would expect to see.

Microsoft Sentinel can ingest sign-in logs from Azure AD Application Proxy. An analytics rule with a KQL query can detect the brute-force pattern, and when triggered, a playbook can call the Azure AD API to add the IP to a Conditional Access block list for one hour, effectively blocking the attacker.

An auto-labeling policy in Microsoft Purview is designed to automatically evaluate content against sensitive info types like 'Passport Number' and apply the corresponding sensitivity label without user interaction. By targeting OneDrive locations, the policy continuously scans files, and when a match is found, it assigns the label and can enforce encryption or protection. This directly fulfills the requirement because classification happens automatically based on content inspection, not on user discretion or manual workflow.

AIR can block indicators of compromise.

Microsoft Entra B2B collaboration is the correct choice because it allows external users to access apps with their own existing identities, and its self-service sign-up feature lets partners initiate access by providing their details without requiring a pre-configured federation trust. B2B collaboration creates guest accounts in your tenant, supports integration with various identity providers including Microsoft Entra ID and Google, and is designed specifically for business-to-business partnerships. This satisfies both the self-service and existing-credential requirements of the scenario.

Conditional Access policies only evaluate sign-ins for identities explicitly included in the assignments. With no users or groups assigned, the policy is enabled yet never applies, so high-risk users sign in unimpeded despite the configured risk condition.

Verify explicitly is the foundational Zero Trust principle that mandates every access request be authenticated, authorized, and encrypted based on all available data points, including user identity, device health, location, and data sensitivity. It eliminates any implicit trust derived from network location or previous interactions, requiring continuous validation for each transaction. This principle ensures that access is granted only after a thorough, real-time assessment, making it the correct core principle for Zero Trust.

A Conditional Access policy targeting the sensitive application with the 'Require hybrid Azure AD joined device' grant control blocks every device lacking that join state, satisfying the hybrid-only constraint at authentication time. Combined with a compliance requirement, it enforces both conditions before a token is issued.

Conditional Access allows MFA policies to be scoped specifically to administrative roles (e.g., Global Administrator, Privileged Role Administrator), applying risk-based and device-compliance conditions at sign-in. This provides granular control over when and where MFA is enforced, which is essential for privileged access because stolen admin credentials become insufficient without a second factor. Unlike blanket security defaults, this can also exclude break-glass accounts while still securing all other admins.

The Windows Security Events via AMA connector uses the Azure Monitor Agent to collect Windows operating system security events, including common Event IDs such as 4624 (successful logon) and 4625 (failed logon), from both Azure VMs and Arc-enabled on-premises servers. Because it relies on AMA, it provides a single, consistent agent for hybrid environments and supports data collection rules to filter specific security event IDs. This direct, native collection path makes it the correct choice for the scenario.

In Microsoft Entra Conditional Access, when both user risk and sign-in risk are specified as conditions, they are evaluated together using AND logic. The policy only applies when the user risk is medium or high and the sign-in risk is high simultaneously, so both conditions are required to trigger access controls. This matches the policy configuration exactly.

Automation rules are the native Sentinel feature that lets you set incident properties—including owner—based on conditions like severity, tags, or rule name, and they execute automatically when an incident is created or updated. This is a built-in action with no external dependencies, so it runs reliably, quickly, and with minimal configuration, making it the correct solution. You can specify a user or group as owner, and the rule will apply that assignment when the incident matches your custom conditions.

Intune's retire action performs a selective wipe: it deletes only the organization's managed data, such as corporate email, VPN and Wi-Fi profiles, app configs, and protected app containers, then unenrolls the device. It deliberately preserves personal photos, personal apps, and other user data, making it the correct choice for BYOD when you must remove company information without damaging the user's private content.

Conditional Access policies are the core enforcement mechanism for zero trust in Azure AD. They combine conditions such as user or group membership, location, device state, and sign-in risk with grant controls like requiring MFA, a compliant device, or a hybrid Azure AD joined device. These policies enforce real-time verification for every access attempt, ensuring that access is granted only when all configured conditions and controls are satisfied, aligning with the zero trust principle of 'verify explicitly'.

Defender for Cloud Apps presents discovered apps in the Shadow IT dashboard, where an admin can mark an app as unsanctioned to actively block it. Unsanctioning is the native CASB control point that works with the Conditional Access App Control (reverse proxy) or app connectors to terminate sessions and prevent access to the app for all users. This is the exact feature designed to govern newly discovered unsanctioned cloud applications, and it works even for apps that are not federated with Microsoft Entra ID.

Enabling the Microsoft Copilot for Security plugin for Sentinel is the direct, secure integration that lets Copilot query and interact with Sentinel data using natural language. When enabled, a security analyst can ask Copilot questions like 'summarize the most recent high-severity alerts' or 'show all open incidents involving user X,' and Copilot translates that into KQL queries against Sentinel's underlying Log Analytics workspace. This plugin explicitly bridges Copilot to Sentinel, providing incident summaries, guided investigations, and context-aware responses, which is exactly what the organization needs to leverage Copilot as a SIEM interface.

Conditional Access enforces the compliance signal from Intune at authentication time, so only devices meeting your compliance policy obtain a token for Exchange Online. This directly satisfies the requirement that solely compliant devices reach corporate email, blocking unmanaged or non-compliant endpoints.

The User reported messages settings in the Microsoft 365 Defender portal (under Email & collaboration > Policies & rules > Threat policies) let you specify where messages reported by users via Outlook, Outlook on the web, or the built-in Report Message button are sent. You can direct these submissions to an internal mailbox, Microsoft, or both, and configure alert notifications so the security team is immediately informed when a user submits a message. This directly satisfies the requirement to make reports visible and actionable.

Configuring an automation rule with an action to send an email notification is the correct approach in Microsoft Sentinel for alerting on incident creation. Automation rules are specifically designed to handle incident lifecycle events (created, updated, etc.) and can perform one or more actions immediately, without needing an external logic app. The 'Send Email' action directly sends an email to a specified recipient, using configured SMTP or Microsoft 365 settings, and can include incident details in the body. This method is natively supported, requires minimal setup, and ensures timely notification whenever an incident meets the condition (e.g., high severity).

A Conditional Access policy is the modern, context-aware mechanism in Microsoft Entra ID for enforcing MFA. It can precisely target specified users, groups, or applications, and evaluate conditions such as geographic location (via named locations), trusted IPs, device state, and sign-in risk. Because Conditional Access is included with Entra ID P1, it directly satisfies the requirement to enforce MFA based on location without requiring any additional licensing.

Custom detection rules in Microsoft Defender XDR leverage Advanced Hunting Kusto Query Language (KQL) queries to continuously monitor event data across email, endpoints, identities, and cloud apps. When the query returns results, the rule triggers an alert and can also create an incident, enabling bespoke detection logic beyond built-in detections. This is the native detection engine for Defender XDR, distinct from SIEM-based rules.

Automation rules in Microsoft Sentinel can trigger on incident creation, evaluate conditions such as analytics rule name or entity, and run a playbook or change incident status. Running a playbook that closes the incident and leaves a comment records the automated action in the incident timeline, giving the required audit trail while removing low-fidelity noise before analysts see it.

The Defender for Cloud data connector ingests security alerts from connected workloads into the Microsoft Sentinel workspace as raw events. However, incidents are not created automatically from these alerts; you must configure an analytics rule (typically a Microsoft security rule of type 'Microsoft Defender for Cloud') to transform the relevant alerts into incidents with assigned severity, status, and ownership. This two-step flow is the only way to get the expected incident-creation behavior from Defender for Cloud alerts.

Multi-factor authentication (MFA) requires users to prove identity with at least two distinct factors—typically a password, a device-bound key, and biometrics—so that a stolen password alone cannot unlock access. In the Zero Trust model, MFA operationalizes 'verify explicitly' by forcing each authentication attempt through a nontrivial identity check. Although MFA alone does not comprise full Zero Trust, it is a mandatory baseline that reduces the impact of credential theft and phishing.

This policy assigns the target to 'All cloud apps' and sets the user risk condition to 'Medium or High,' then applies the 'Block' grant control. As a result, any sign-in with a user risk level of medium or higher is denied across every application, while low-risk sign-ins are unaffected. The combination of a broad application scope and a risk threshold yields a global block for medium and high risk users.

Editing the role's activation settings to require approval enforces a documented authorisation step before any privileged role becomes active. This directly satisfies the stem's demand that every activation trigger an approval workflow, with the approval recorded in PIM for compliance auditing.

The Investigation graph in Microsoft Defender XDR is purpose-built for visually exploring the entities involved in an alert or incident. It dynamically maps nodes such as users, devices, IP addresses, and mailboxes, along with edges representing their connections, letting you investigate scope and expand the investigation. This interactive relationship mapping is exactly what the scenario requires, unlike automation or reporting tools.

Applying a CanNotDelete resource lock on the Log Analytics workspace is the only option that actively blocks any delete operation on the workspace and all its child resources, including diagnostic settings. This lock enforces a deny at the Azure Resource Manager level, overriding even elevated RBAC permissions unless a matching delete lock is removed first. As a result, it provides a robust, unbreakable-by-default safeguard that directly prevents the diagnostic settings from being deleted.

Trainable classifiers are machine learning models in Microsoft Purview that analyze content using contextual, semantic, and visual signals to identify data types that do not rely on fixed patterns. They can be trained on seed documents unique to your organization, allowing them to classify content that lacks standardized formats, such as intellectual property or internal forms. This makes them the correct answer for a ML-driven classification approach.

Defender for Identity alerts are normalized into the SecurityAlert table when Sentinel's data connectors ingest them from Microsoft 365 Defender or Azure ATP. This table uses a unified schema for all security alerts, so filtering by the provider or product name (such as 'Azure Advanced Threat Protection') isolates only Defender for Identity detections. Querying SecurityAlert is the correct approach because it is the standard Sentinel table for pre-correlated, high-fidelity security findings, not raw telemetry or audit logs.

Microsoft Sentinel is a cloud-native SIEM and SOAR that centralizes security telemetry from Azure, AWS, and GCP via native connectors, such as AWS CloudTrail/Security Hub and the GCP Pub/Sub-based connector, into a single Log Analytics workspace. It empowers analysts to run KQL-based hunt queries across all clouds, create custom analytics rules for multi-cloud attack detection, and use Automation rules and Logic Apps playbooks to orchestrate response. This provides true unified incident management and automated remediation across heterogeneous environments, far beyond what individual cloud security tools offer.

MDA discovers apps used in the organization.

Advanced Hunting is the XDR-native KQL query interface spanning the unified Defender XDR data schema, including endpoint, email, identity, and cloud app tables. By saving an advanced hunting query as a custom detection rule, Defender XDR continuously evaluates cross-domain signals and generates alerts, making it the correct mechanism for correlating evidence from multiple sources.