CCNA Defender Cloud Sentinel Questions

Enabling the Azure SQL databases plan at subscription level activates Defender for Cloud's threat detection across every existing and future Azure SQL database automatically, with no per-database configuration. This directly satisfies the stem's requirement to minimise administrative effort, since new databases inherit protection without any further action.

This option correctly treats Microsoft Defender for Cloud's plans as modular components: the CSPM plan at the management group gives every subscription a baseline of continuous security posture assessment, attack-path analysis, and regulatory compliance scoring. Then, workload-specific plans are scoped precisely—Defender for Servers on Subscription A delivers built-in vulnerability assessment (via Microsoft Defender for Endpoint or Qualys) and host-level endpoint detection, while Defender for Azure SQL on Subscription C provides SQL injection protection and anomalous access detection. Leaving Subscription B on CSPM alone is cost-effective and appropriate for a non-production environment that requires monitoring but not those advanced workload-specific defenses.

The Regulatory Compliance dashboard supports manual attestation: for controls Defender for Cloud cannot assess automatically, you upload evidence files and mark them as compliant, which feeds the assessment. This satisfies the scenario's requirement to document manual control evidence within the dashboard.

The Microsoft Entra ID connector uses the Microsoft Graph API to stream both sign-in reports and directory audit logs into Microsoft Sentinel. Ingested data populates tables such as SigninLogs and AuditLogs, enabling detection rules for suspicious logons, MFA failures, and tenant configuration changes. This is the directly appropriate data source for monitoring identity behavior in Microsoft Entra ID.

Attack path analysis is a cloud security posture management (CSPM) capability in Microsoft Defender for Cloud that builds a graph of your cloud resources and identifies chains of misconfigurations, exposed credentials, and weak network controls that could allow an attacker to reach a critical asset. Each path is scored and visualized so security teams can prioritize a small number of fixes that break multiple high-risk attack routes. This feature belongs to the posture-management pillar, not to workload protection.

Microsoft Defender for Containers provides Kubernetes-aware threat detection, monitoring control plane audit logs and node-level runtime activity to surface suspicious events such as privilege escalation inside AKS clusters. Enabling it satisfies the stem's requirement for cluster activity alerts, which generic Defender for Cloud plans or standalone Microsoft Entra ID controls cannot deliver.

Continuous export is a native Microsoft Defender for Cloud feature that streams security alerts and recommendations to an Event Hubs namespace or a Log Analytics workspace in near real time. This is the officially supported integration path for sending security alerts to an external SIEM, because Event Hubs serves as a high-throughput, durable ingestion endpoint that downstream tools like Splunk or QRadar can consume. You enable it per subscription or configure it centrally with Azure Policy, and it guarantees ongoing delivery without per-alert manual action. This satisfies the requirement of ensuring security alerts reach the SIEM continuously.

Microsoft Sentinel is not available in every Azure region. The Log Analytics workspace must reside in a region where the Sentinel solution (Microsoft.SecurityInsights) is supported. If the workspace is in an unsupported region, enabling Sentinel will fail with a region-specific error. This is the only listed condition that directly and necessarily blocks Sentinel deployment, making it the correct answer.

The query excludes only two specific IP addresses, which leaves all other internal or trusted IPs subject to creating an incident when a disabled account signs in. Because disabled-account sign-in events are often generated by old service accounts, scheduled tasks, or users who have not been offboarded, the rule should apply an allowlist of corporate egress ranges or a blocklist/allowlist combination. Without a sufficiently broad safe-IP filter, the rule will repeatedly alert on legitimate activity and drown out genuinely suspicious disabled-account access.

Assigning the Azure Security Benchmark or default Microsoft Defender for Cloud policy initiative at the management group scope ensures that all subscriptions within that management group inherit the policy assignments. This enables continuous assessment and automatic application of security policies to new subscriptions. It is the recommended approach for centralized governance and meets the requirement for automatic policy application.

The rule's KQL query aggregates sign-in logs where the risk level is marked as risky and the location is outside the United States, grouping results by user principal name. When the count of such events exceeds a threshold (for example, more than 3) within the 7-day evaluation period, an alert is triggered. This directly matches the stated detection intent, making it the correct description of the query's behavior.

The query groups alert records by AlertName and Severity using summarize, counts the occurrences in each combination, and applies top to rank those combinations descending by count. This returns the ten most frequent alert-name/severity pairs over the rolling 7-day window, which precisely matches the stated purpose. The inclusion of both fields in the grouping key is essential to the output.

For a scheduled analytics rule, an alert is only created when the KQL query returns at least one row. The most common reason for silence is that the query contains incorrect logic—such as referencing a non-existent table, filtering on misspelled columns, or using a where clause that never evaluates to true—which results in zero matching records. Improper entity mapping does not directly prevent alert generation, but it can cause alerts to lack the required entity fields, which may interfere with incident creation and automation, making it appear as though the rule is failing.

Assigning a policy initiative at the management group scope is the correct centralized approach because all subscriptions and resource groups under that management group inherit the policy assignment automatically. This includes future subscriptions added later, which become compliant without any additional assignment effort. Management group assignments also provide a single point to manage exclusions, remediation, and compliance reporting across the entire organizational hierarchy.

This is correct because it sums the ResponseBodySize of all GetBlob operations in each one-hour bin, converting bytes to gigabytes by dividing by 1,073,741,824 (2^30). This captures the total volume of data downloaded per hour, which is the true signal for a bulk exfiltration scenario. The `where TotalGB > 1` then isolates hours where more than 1 GB left the storage account, aligning with the security team's threshold.

Adaptive application controls are a workload-protection capability in Microsoft Defender for Cloud that uses machine learning to establish a baseline of applications permitted to run on a specific set of Azure or non-Azure VMs. In audit mode, it learns typical running processes; in enforce mode, it blocks untrusted executables and generates security alerts. This feature directly protects the workload plane, distinguishing it from network-layer services like DDoS protection.

Creating a suppression rule for the specific alert type and source IP address is the targeted, recommended solution. Defender for Cloud lets you define a rule on an alert that automatically dismisses future matches based on properties like entity, IP address, or attack evidence, so benign scanning activity from that IP is ignored while all other alerts continue to fire. This reduces alert fatigue without disabling any detection capability.

The Microsoft Defender for Cloud data connector in Microsoft Sentinel is the native integration that ingests security alerts from Defender for Cloud plans into your workspace, and enabling incident creation on that connector activates the built-in analytics rule that automatically generates a Sentinel incident for each incoming alert. This is the intended, supportable path because it requires no custom code or manual effort, and it ensures that Defender for Cloud detection signals flow directly into your SOC incident queue for triage and investigation.

Microsoft Defender for Endpoint, integrated into Microsoft Defender XDR, provides true endpoint detection and response with continuous memory scanning, kernel-level behavioral monitoring, and cloud-driven machine learning. It identifies fileless malware by correlating anomalous process activity, script execution, and in-memory indicators, then automatically contains the host. This capability is precisely why it, not any agent-based scanner, defeats fileless attacks.

Deploying Azure Arc gives on-premises servers an Azure Resource Manager identity, allowing them to be governed with Azure Policy, Defender for Cloud, and Data Collection Rules just like Azure VMs. Azure Monitor Agent, configured via Data Collection Rules, efficiently collects Windows and Linux security events and forwards them to a Log Analytics workspace where Microsoft Sentinel ingests and analyzes them. Sentinel analytics rules detect threats and generate incidents, while automation rules trigger Azure Logic Apps playbooks for consistent, automated remediation. This is the current, fully supported hybrid SIEM/SOAR design that unifies on-premises and cloud security operations.

Correct. In Kusto Query Language (KQL), the union operator merges rows from two or more table expressions, and its workspace('workspace-id') function lets each branch point to another Log Analytics/Microsoft Sentinel workspace. This makes union the fundamental operator for cross-workspace queries: each table reference can be rewritten as workspace('<workspace>').<Table>, and the results are concatenated into a single result set.

Azure Active Directory Sign-in Logs ingest authentication and authorization events, such as successful and failed user sign-ins, conditional access results, and MFA challenges. Azure Active Directory Audit Logs capture all directory-management activities, including user creation, group membership changes, password resets, and application role assignments. These two complementary connectors provide the full AAD security telemetry needed to monitor both user access and administrative changes in Microsoft Sentinel.

The Vulnerability Assessment solution in Microsoft Defender for Cloud, when set to 'On', auto-provisions a built-in scanner (Qualys or Microsoft Defender Vulnerability Management) to supported machines. This continuously scans for known CVEs, misconfigurations, and security weaknesses, and surfaces findings in the Defender for Cloud recommendations and Secure Score. It is the native, integrated way to meet the requirement of vulnerability assessment across all VMs.

Microsoft Sentinel's UEBA builds entity pages that consolidate a user, device, or other entity's activity into a single pane, including a timeline, related entities, and behavioral analytics. These pages surface investigation insights like anomalous logon patterns, impossible travel, and peer-group deviations, which are automatically generated via machine learning baselines. This gives analysts an entity-centric, visual starting point for investigation, making it the exact feature that matches the question's requirement for timeline and related-entity visualization.

An automation rule in Microsoft Sentinel triggers a playbook—a Logic Apps workflow—that can programmatically add a deny rule to the network security group (NSG) attached to the VM's subnet, blocking the attacker's source IP. This provides immediate and consistent containment without manual intervention, making it the correct response for a high-severity alert requiring rapid network-level blocking.

A primary benefit of automation rules is the 'Run playbook' action, which can be triggered automatically when an incident is created or updated. This enables incident response teams to execute Logic Apps that perform enrichment, containment, or remediation steps without manual intervention. Playbooks can be invoked with the incident as context, making it easy to gather data, block indicators, or send notifications.

This query correctly groups failed sign-ins by IP and 5-minute bin, and filters for >10.

Installing the Defender profile is the correct action because Microsoft Defender for Cloud’s Defender for Containers plan uses a dedicated DaemonSet on each AKS node to collect security signals such as Kubernetes audit logs, node events, and container runtime telemetry. The profile must be explicitly enabled on the cluster; enabling the plan at the subscription level alone does not protect existing clusters. Without this profile, the cluster remains visible in Defender for Cloud but lacks workload-level threat detection.

The integrated vulnerability assessment (VA) solution in Microsoft Defender for Cloud, powered by Qualys, performs agent-based scans of the OS and installed software to identify missing patches, insecure configurations, and known Common Vulnerabilities and Exposures (CVEs). It surfaces these findings as security recommendations and can generate alerts when discovered vulnerabilities align with known attack vectors. For on-premises and hybrid servers, you must first onboard them to Azure Arc and enable the Defender for Servers plan so the VA scanner can report to the cloud workload-protection dashboard.

Each Microsoft Sentinel workspace is functionally a Log Analytics workspace with Sentinel enabled, and the workspace's location determines where all underlying data is stored at rest. Deploying Sentinel in each required region creates separate, region-pinned data stores that fully contain that region's logs, satisfying residency requirements. This also allows rules and workbooks to be scoped to local data, though cross-workspace queries or Azure Lighthouse can still provide a pane-of-glass view for centralized monitoring.

Automation rules in Microsoft Sentinel can trigger playbooks based on incident conditions. The playbook must be created first, then referenced in the automation rule. The condition Severity equals High ensures only high-severity incidents trigger the playbook, and the playbook can access incident entities to populate ServiceNow fields. This is the correct sequence to achieve the requirement.

In Defender for Cloud, each regulatory compliance standard is assigned to a specific scope, such as a subscription or management group, when you enable it. Only resources within that assigned scope are evaluated and reported in the compliance dashboard, and resources in unassigned subscriptions are completely ignored. If the subscription containing the resources is not part of the standard's assignment, those resources will not appear in the compliance view.

Enabling the 'Defender for Containers' plan in Microsoft Defender for Cloud is the fundamental step that activates threat detection, vulnerability assessment, and security recommendations for AKS clusters. This plan must be turned on for the subscription that contains the cluster; once enabled, Defender automatically deploys the necessary components to collect and analyze security signals. Without this plan, no amount of audit logging or agent installation will produce Defender's container-specific protection.

Advanced Threat Protection (ATP) for Azure SQL Server (also known as Defender for SQL) must be enabled at the server level; it activates vulnerability assessment, anomaly detection, and the alerting engine that surface suspicious activities like SQL injection, brute-force attempts, or unusual access patterns. When ATP is on, Microsoft Defender for Cloud automatically collects and displays these SQL-specific security alerts in its alerts pane. Without ATP enabled, no anomaly-based SQL alert will ever appear in Defender for Cloud, regardless of auditing, firewalls, or service endpoints.

Creating an Azure Policy assignment using a built-in definition such as 'Deploy Log Analytics agent to Windows VMs' automatically installs the agent on both existing and future VMs in the assigned scope via a deployIfNotExists effect. This approach centralizes governance at the subscription or management group level, requires only a Log Analytics workspace ID as a parameter, and continuously enforces compliance without human intervention.

The Microsoft Graph API provides a unified REST endpoint for Microsoft 365 services, including Outlook mail, enabling Sentinel playbooks to execute remediation actions such as soft-deleting or purging malicious emails from a user's mailbox. Since Sentinel's Logic Apps connector supports HTTP requests to Graph API with proper OAuth authentication, it is the appropriate mechanism for mailbox-level threat remediation within an automated incident response workflow. Unlike PowerShell or other APIs, Graph API is directly consumable from a playbook and is designed for cross-service automation.

The Microsoft Entra ID connector for Microsoft Sentinel relies on diagnostic settings that must be explicitly enabled in Microsoft Entra ID to route sign-in logs to a Log Analytics workspace. If these settings are absent or misconfigured, sign-in log ingestion fails even though the Sentinel connector itself appears connected, which precisely matches the reported symptom. You must verify that the diagnostic setting streams AuditLogs and SignInLogs to the same workspace that Sentinel uses, and that the workspace ID matches the one selected in the connector.

Automation rules in Microsoft Sentinel can trigger on incident creation and evaluate conditions such as the analytics rule name, severity, or tags. They can then assign an owner and add a comment. This directly meets the requirement to assign a specific owner and add a comment when an incident is created from a particular analytics rule.

Automation rules run independently of playbooks and can trigger responses directly when an incident is created, satisfying the requirement for automated response actions. They support conditions on analytics rules, severity, and entity mappings, and can execute playbooks, assign owners, or change status without manual intervention.

Microsoft Sentinel uses Kusto Query Language (KQL) for log queries and analytics. KQL is designed for querying large datasets in Azure Monitor and Log Analytics, and it supports filtering, aggregation, and time-based queries. The analyst can use KQL to search sign-in logs, such as SigninLogs, and filter by IP address and time range.

The deployIfNotExists effect first evaluates the existence condition—here, checking whether a security contact with a non-empty email already exists. Because that condition is true, the policy skips the deployment template entirely, leaving the existing security contact unchanged. As a result, the policy is compliant and no modification occurs to the already-provisioned contact.

Microsoft Defender for Cloud provides a dedicated email notifications configuration where you can specify email addresses and choose which severity levels trigger notifications. This is the direct and intended way to receive email alerts for high-severity findings. It also allows notifying subscription owners and security contacts. This meets the requirement without additional services.

Correct: Required to enable the connector.

Regulatory compliance standards in Microsoft Defender for Cloud are the correct choice because they directly map security recommendations to specific compliance frameworks, such as SOC 2, PCI DSS, and ISO 27001. This feature provides a dashboard where you can track your organization's compliance posture against each standard, with controls and corresponding recommendations that need remediation. It allows you to prioritize recommendations based on regulatory audit deadlines and requirements, which aligns with the compliance team's need to map recommendations to regulations.

Azure Logic Apps are the correct platform for Sentinel playbooks because they provide a low-code workflow engine with native connectors to Microsoft Defender, Teams, ServiceNow, and hundreds of other services. Logic Apps are triggered by Sentinel incidents and alerts through dedicated connectors, allowing automated investigation and response actions. They support both consumption and standard hosting plans and are the only compute service that integrates natively with Sentinel automation rules.

Automation rules in Microsoft Defender for Cloud can trigger Logic Apps based on alert severity, resource type, and other conditions. This directly satisfies the requirement for automatic, no-touch execution. The rule evaluates new alerts and invokes the playbook, which can then perform remediation steps such as isolating the storage account or notifying the SOC.

The Windows Security Events via AMA connector is the correct choice because Azure Monitor Agent (AMA) is the modern agent that collects Windows Event Logs, including the Security channel, using a Data Collection Rule (DCR). This connector streams events such as successful/failed logons, process creation, and privilege use directly into Sentinel's WindowsEvent table, making it the current standard for this source. Unlike the legacy Log Analytics agent, AMA provides a single agent for both Log Analytics and extension-based workloads, with more granular filtering and network-friendly control.

Automation rules in Microsoft Sentinel are condition-based triggers that fire on incident creation, and they can invoke a playbook (an Azure Logic Apps workflow). The playbook can use an HTTP or webhook action to create a ticket in your external ticketing system, making this the correct outbound integration path. Unlike the other options, this is an active, automated mechanism that sends data out of Sentinel.

Microsoft Defender for Servers is the only plan that includes Just-in-Time VM access, which locks down inbound management ports by default and lets defenders request temporary, time-bound access through Defender for Cloud. The feature works by automatically configuring and updating NSG rules to allow a specific source IP and port pair for a defined window, then reverting to close the port. This makes Defender for Servers the correct choice for a security team seeking JIT capabilities for their virtual machines.

Microsoft Defender for Cloud provides multicloud CSPM via its connector feature: in the Azure Portal, you enable the AWS connector (using a CloudFormation template and cross-account role) or GCP connector (using a service account) to on-board your entire cloud environments. Once connected, Defender for Cloud continuously pulls resource configuration and workload telemetry using AWS Config/AWS Security Hub and GCP Cloud Asset Inventory, then applies built-in security standards (e.g., CIS, NIST, Azure Security Benchmark) to generate recommendations and compliance scores across AWS, GCP, and Azure. This native multicloud connector also enables advanced threat protection features such as attack path analysis and cloud security explorer, making it the only listed option that fulfills multicloud CSPM.

For Defender for Cloud to assess a subscription, the Microsoft.Security resource provider must be registered at the subscription level, as this registration is what allows the service to query Azure Resource Manager for resource metadata and configuration. When the provider is unregistered, Defender for Cloud cannot perform any resource discovery, so no security recommendations, regulatory compliance controls, or secure score data are generated for that subscription. Registration is typically performed automatically when a user first opens Defender for Cloud in the portal, but it can also be done programmatically via Azure CLI (`az provider register --namespace Microsoft.Security`) or PowerShell. An unregistered provider explains both the absence of data and why the user perceives that security posture is completely missing.

The regulatory compliance dashboard in Microsoft Defender for Cloud is the correct tool because it provides a continuous, standards-based assessment by mapping Azure Policy initiatives to controls from frameworks such as Azure CIS, PCI DSS, ISO 27001, SOC 2, and even custom standards. It shows a compliance percentage per standard, lets you drill down to non-compliant resources and controls, and tracks compliance history over time. You can select which standards to assess in the compliance policies settings, giving you exactly the detailed compliance status needed.

The continuous export feature in Microsoft Defender for Cloud natively streams security alerts and recommendations to an Azure Event Hubs namespace, allowing near real-time integration with an external SIEM or log management tool. You configure it under Environment settings for a subscription or a management group, and it supports filtering for specific alert severities or recommendations. Because this is built in, it handles batching, schema, and transport without custom code, making it the correct method for continuous alert export.

Automation rules in Microsoft Sentinel are designed to handle incident management tasks such as assignment, tagging, and status changes. They can trigger on incident creation and update, and support conditions based on analytics rule name, severity, and entities. This meets the requirement with minimal effort, as no custom logic or playbooks are needed.

Defender for Servers provides advanced threat detection for VMs, including process-level monitoring and behavioral analytics. The Azure Monitor Agent, when deployed via the plan, installs the required extensions (such as the Defender for Endpoint sensor) to collect and analyze security events. Without this plan and agent, process execution events may not be captured, and alerts will not be generated.

The workspace() expression in KQL—e.g., union workspace('Contoso-Sentinel').SecurityEvent, workspace('Fabrikam-Sentinel').SecurityEvent—lets you query tables across multiple Log Analytics workspaces in a single query. This is the Azure-native mechanism designed for Microsoft Sentinel multi-workspace scenarios and works without duplicating data or adding an extra ETL layer. It also supports resource-id based references, so you can query Sentinel workspaces that data is retained in while preserving the full context of the original table schema.

Enabling the 'Servers' plan (Microsoft Defender for Servers) and turning on the 'Vulnerability assessment for machines' setting activates the built-in Microsoft Defender Vulnerability Management (MDVM) scanning capability. This integration automatically discovers installed software, missing OS patches, and configuration vulnerabilities across Azure and hybrid VMs without requiring you to manually deploy a separate VA scanner on each machine. The resulting recommendations are surfaced in Defender for Cloud, directly satisfying the requirement to assess VMs for missing updates with minimal administrative overhead.

Defender for Cloud's identity recommendations rely on the per-user MFA state in Microsoft Entra ID, which is a distinct flag set at the user level independent of any Conditional Access policies. Even when an organization has robust Conditional Access requiring MFA for all users, the per-user MFA property may still be 'Disabled', causing the recommendation to flag accounts as non-compliant. This is why the recommendation persists even when there is no actual MFA bypass, making this the correct explanation.

When auto-provisioning is enabled in Microsoft Defender for Cloud, the Log Analytics agent is automatically installed on existing and newly created Azure VMs. For new VMs, the agent extension is deployed as part of the VM provisioning process, ensuring that security data like event logs, performance counters, and audit records are collected without manual intervention. This agent installation is the core behavior of auto-provisioning and is the correct interpretation of the setting in the exhibit. The agent forwards data to the configured Log Analytics workspace for analysis by Defender for Cloud.

Sign-in attempts against a disabled account return error code 50057 (user account disabled), which means the directory explicitly prohibits authentication. When multiple such attempts come from the same IP address, it signals a coordinated credential-stuffing or brute-force effort targeting a specific disabled account. Because a disabled account has no legitimate use, every attempt is unequivocally anomalous and represents a high-priority threat, especially if the IP shows other malicious activity.

Entity pages in Microsoft Sentinel are a UEBA feature that aggregates an entity's activity into a timeline, showing behavior over time, related alerts, and anomalies. This allows analysts to quickly assess an entity's risk and contextualize investigations. UEBA specifically contributes anomaly-prone behavior insights and peer-group comparisons to these pages.

The Incident investigation view in Microsoft Sentinel opens an interactive graphical map that presents the incident's related alerts, entities, and activities as linked nodes. This tool enables you to trace relationships between hosts, IP addresses, accounts, and security events, revealing the attack path through entity timeline and expansion queries. It is precisely the correlation capability that helps analysts explore how individual alerts combine into an attacker's sequence of actions.

Fusion (machine learning) rules are specifically built for detecting multi-stage attacks by correlating alerts from multiple products, such as Microsoft Defender for Endpoint, Defender for Identity, Defender for Office 365, and Defender for Cloud. The engine uses scalable machine learning algorithms to analyze incoming alerts, identify patterns that match known kill-chain sequences, and automatically fuse them into a single actionable incident with a story of the attack. This goes beyond simple alert aggregation: Fusion evaluates the timing, context, and relationships between alerts to produce high-fidelity incidents with low false-positive rates. Because the scenario requires detecting a multi-stage attack that spans various alert sources, Fusion is the correct choice.

Changing the WAF policy mode to detection makes the gateway evaluate every managed and custom rule and log all matches to the WAF diagnostic logs, but it stops enforcing blocking actions. You can then correlate the rejected requests with the exact rule ID and request details in Log Analytics, confirming whether this is a false positive. Once you've identified the offending rule, you can add exclusions or tune rule actions and switch the policy back to prevention mode.

This is correct. The workbook's time range filter might be set to a broader range (e.g., last 7 days) while the query uses a 24-hour filter. If the query does not correctly use the time parameter, it may return no results when the dashboard filter is applied.

SQL database auditing tracks database events and writes them to an audit log in Azure Storage, Log Analytics, or Event Hub. Reviewing these logs lets you see the exact queries, the principal/user, the source IP address, and the timestamp of the suspicious activity, confirming whether the Defender alert is a genuine attack and revealing its origin. This is the direct and immediate way to validate an alert from Microsoft Defender for Cloud.

Deploying one Microsoft Sentinel workspace per region satisfies data residency because each workspace is a Log Analytics workspace that ingests and stores logs within its own geographic boundary. Cross-workspace querying with the 'workspace()' expression or Azure Resource Graph lets security analysts run a single KQL query that references multiple workspaces, correlating threats without moving data out of its resident region. Sentinel's built-in UEBA and analytics rules work on each workspace, while cross-workspace views preserve centralized hunting.

CSPM generates recommendations to improve security.

From an incident, clicking 'Run playbook' opens a side panel where you can select an enabled playbook, which then executes with the Incident trigger. This manual trigger is essential for ad-hoc response, testing, or remediation tasks that require human judgment, and it passes the full incident context—including alerts, entities, and metadata—to the playbook. It is a valid, documented way to launch a playbook on demand.

A Sentinel playbook is an Azure Logic Apps workflow that is designed explicitly to run automated responses in conjunction with Sentinel incidents and alerts. When you create a playbook, you can add a Microsoft Entra ID connector that uses the Microsoft Graph API to perform actions such as disabling a user or updating the accountEnabled property of the target identity. The playbook can be attached to an automation rule that fires on an incident, making it the correct, supported way to automatically disable a compromised account.

Enabling the 'SQL servers on machines' plan in Microsoft Defender for Cloud is the prerequisite that activates threat detection for Azure Arc-enabled SQL Server instances. This plan, part of Defender for Cloud's enhanced security features, turns on SQL-specific alerts, vulnerability assessments, and advanced threat protection for on-premises and multi-cloud SQL servers. Without this plan enabled, no SQL server security alerts will be generated regardless of other configurations, so this is the required first step.

This is the correct action because JIT VM access is a feature specifically included in Microsoft Defender for Servers Plan 2. When you enable Defender for Servers Plan 2, Defender for Cloud automatically activates JIT and allows you to create just-in-time policies on supported VMs. The JIT feature locks down VM management ports (e.g., SSH 22 and RDP 3389) via NSG rules and opens them temporarily only after approval, with a configurable maximum access duration. Without this plan—or with only Defender for Servers Plan 1—JIT is not available, so enabling Plan 2 is the required step.

Microsoft Sentinel UEBA builds a baseline of each user's historical behavior, including sign-in patterns, resource access, and geographic locations, using machine learning. When a user's activity deviates significantly from their own established baseline, UEBA flags it as an anomaly with a risk score. This historical individual baseline is a core mechanism of UEBA, distinguishing it from simple rule-based alerting.

Correct: Policy assignment at management group scope applies to all subscriptions under it.

The Windows Security Events connector using the Azure Monitor Agent (AMA) is the correct choice because it collects Windows Event Log entries, including security events such as successful and failed logon attempts (Event IDs 4624, 4625) from Azure VMs. AMA is configured with a data collection rule (DCR) that specifies which event IDs to send to the Log Analytics workspace where Microsoft Sentinel can analyze them. This is exactly the native, supported path for OS-level sign-in monitoring on Windows virtual machines.