Microsoft Security Operations Analyst SC-200 SC-200 Questions 76–150 | Page 2/3

MCQeasy

Your organization uses Microsoft Sentinel for security operations. You need to ensure that critical alerts are automatically assigned to the appropriate SOC tier for investigation. What should you configure in Microsoft Sentinel?

A.Create a playbook that assigns the incident to a user

B.Use a watchlist to map alert types to owners

C.Configure an analytics rule to set the owner

D.Create an automation rule that sets the incident owner

AnswerD

Automation rules can automatically assign incidents to owners or groups.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically assign incidents to specific owners based on conditions like severity or alert type. This ensures critical alerts are routed to the appropriate SOC tier without manual intervention, directly meeting the requirement.

Exam trap

The trap here is that candidates often confuse the capabilities of analytics rules (which generate incidents) with automation rules (which handle post-creation actions like owner assignment), leading them to incorrectly select Option C.

How to eliminate wrong answers

Option A is wrong because a playbook that assigns an incident to a user is an over-engineered solution; automation rules are designed for simple owner assignment without the need for a Logic App. Option B is wrong because watchlists are used for correlating data or enriching alerts, not for assigning incident ownership. Option C is wrong because analytics rules define alert conditions and generate incidents, but they do not have a setting to configure the incident owner; owner assignment is handled post-creation by automation rules or playbooks.

Full explanation →

MCQmedium

A company uses Microsoft Defender for Cloud to manage security posture. The compliance team needs to continuously monitor resources against the CIS Microsoft Azure Foundations Benchmark and receive a consolidated score across all subscriptions. Which Defender for Cloud feature should they use?

A.Secure Score

B.Regulatory compliance dashboard

C.Adaptive application controls

D.File Integrity Monitoring (FIM)

AnswerB

The Regulatory compliance dashboard in Defender for Cloud is specifically designed to track and manage compliance against selected standards like CIS and ISO. It works by assigning built-in Azure Policy initiatives that embed the audit requirements of each standard, then continuously evaluating your resources against those policies and displaying pass/fail results for each compliance control. This directly provides the capability to manage security against a particular compliance standard, so it is the correct answer.

Why this answer

The Regulatory compliance dashboard in Microsoft Defender for Cloud provides continuous monitoring of resources against specific compliance standards, such as the CIS Microsoft Azure Foundations Benchmark, and aggregates a consolidated score across all subscriptions. This feature maps Azure Policy initiatives to compliance controls, showing pass/fail status and a compliance score, which directly meets the compliance team's requirement for ongoing assessment and a unified score.

Exam trap

The trap here is that candidates often confuse Secure Score with regulatory compliance scoring, but Secure Score is a general posture metric based on Microsoft's security recommendations, not a dedicated compliance benchmark score like CIS.

How to eliminate wrong answers

Option A is wrong because Secure Score measures an organization's overall security posture based on security recommendations, not specific compliance with the CIS Microsoft Azure Foundations Benchmark; it does not provide a consolidated compliance score for a particular regulatory standard. Option C is wrong because Adaptive application controls are a workload protection feature that uses machine learning to define allowlists for running applications on Azure VMs, unrelated to compliance monitoring or scoring. Option D is wrong because File Integrity Monitoring (FIM) examines changes to files and registries on VMs for security incidents, not for assessing compliance against a benchmark like CIS.

Full explanation →

Multi-Selectmedium

Which TWO actions can you perform using Microsoft Sentinel automation rules? (Select two.)

Select 2 answers

A.Create a task on an incident

B.Run a playbook on an incident

C.Create an incident automatically

D.Create a new automation rule

E.Send an email notification

AnswersA, B

Automation rules can add tasks to incidents.

Why this answer

Microsoft Sentinel automation rules can create tasks on incidents. This allows you to automatically assign investigation steps or remediation actions to specific personnel, ensuring consistent incident response workflows.

Exam trap

The trap here is that candidates often confuse automation rules with playbooks, assuming automation rules can directly send emails or create incidents, when in fact they only orchestrate actions that may be executed by playbooks or other components.

Full explanation →

MCQmedium

A SOC analyst wants to automate a response in Microsoft Sentinel such that whenever an incident is created containing a specific user entity (e.g., compromised user), a playbook runs that disables the user in Microsoft Entra ID. Which condition should be configured in the automation rule?

A.When incident is created, and the incident contains a user entity.

B.When alert is generated, and the alert contains a user entity.

C.When incident is created with severity high, then run the playbook.

D.When playbook is triggered manually from the incident details page.

AnswerA

Automation rules in Microsoft Sentinel are evaluated when an incident is created, and they support conditions on incident properties and entity types. Selecting the trigger 'When incident is created' combined with a condition that the incident contains a User entity scopes the rule precisely, so the playbook runs automatically for every relevant incident. This is the correct way to automate a response because it directly matches the stated requirement of an incident-time trigger with a user entity filter.

Why this answer

The automation rule must trigger on incident creation and evaluate whether the incident contains a specific user entity to run the playbook that disables the user in Microsoft Entra ID. This ensures the playbook only executes when the relevant entity is present, aligning with the requirement to automate a response based on a compromised user entity.

Exam trap

The trap here is that candidates may confuse alert-level triggers (Option B) with incident-level triggers, or assume severity (Option C) is sufficient without considering entity-specific conditions, leading to over-triggering or missing the precise automation requirement.

How to eliminate wrong answers

Option B is wrong because automation rules in Microsoft Sentinel trigger on incidents, not directly on alerts; alerts are ingested into incidents, and the rule must be set at the incident level. Option C is wrong because it specifies a severity condition (high) without requiring the user entity, which would cause the playbook to run for all high-severity incidents regardless of whether a compromised user entity exists. Option D is wrong because manual triggering from the incident details page does not automate the response; the requirement is for an automated response when an incident is created.

Full explanation →

MCQeasy

An SOC analyst wants to quickly enable detection for when a user account is added to the Global Administrator role in Microsoft Entra ID using a built-in analytics rule template in Microsoft Sentinel. Which type of analytics rule template should the analyst use?

A.Scheduled

B.Microsoft Security

C.Fusion

D.Machine Learning (ML)

AnswerA

The 'Scheduled' analytics rule template is correct because it periodically executes a KQL query against Microsoft Entra ID audit data (AuditLogs or AzureADAuditLogs) to detect deterministic events, such as a user being added to the Global Administrator role. You control the schedule and query, enabling immediate detection without dependency on external signal correlation. This direct query-and-alert pattern is exactly how the built-in Global Admin role addition template works.

Why this answer

The analyst should use a Scheduled analytics rule template because the detection for when a user account is added to the Global Administrator role in Microsoft Entra ID requires querying the AuditLogs table at a regular interval. Scheduled rules allow you to define a KQL query that runs on a schedule (e.g., every 5 minutes) and generates alerts based on the results. This is the only built-in rule type that supports custom log queries for specific activities like role assignments.

Exam trap

The trap here is that candidates often confuse 'Microsoft Security' rules (which handle alerts from other Microsoft services) with the ability to create custom detections from raw logs, but only Scheduled rules allow you to write your own KQL query against tables like AuditLogs.

How to eliminate wrong answers

Option B (Microsoft Security) is wrong because Microsoft Security rules are pre-built templates that generate alerts from Microsoft security products (e.g., Microsoft Defender for Cloud, Microsoft 365 Defender) and do not allow custom KQL queries against raw logs like AuditLogs. Option C (Fusion) is wrong because Fusion rules use advanced machine learning to correlate multiple alerts into incidents based on kill-chain analysis, not for detecting a single, specific event like a role assignment. Option D (Machine Learning (ML)) is wrong because ML rules are designed for behavioral anomaly detection using custom ML models, not for deterministic detection of a known event like adding a user to a privileged role.

Full explanation →

MCQmedium

During a threat hunt, a security analyst uses Microsoft Sentinel and identifies a series of failed logon attempts from a single IP address targeting multiple user accounts. The analyst wants to create a scheduled analytics rule that generates an alert when the same IP address fails to logon to more than 10 different accounts within 5 minutes. Which KQL operator should be used to count distinct accounts per IP?

A.count()

B.summarize count() by Account

C.distinct Account

D.dcount(Account)

AnswerD

dcount provides an approximate distinct count of accounts, suitable for performance.

Why this answer

Dcount(Account). The dcount() function performs an approximate distinct count, which is efficient for large datasets and suitable for counting distinct accounts per IP. Option A (count()) counts all events, not distinct accounts.

Option B (summarize count() by Account) counts events per account, not distinct accounts per IP. Option C (distinct Account) returns unique account values but does not provide a count.

Full explanation →

MCQhard

A SOC analyst wants to detect when a user signs in from a device that has never been used by that user before. The analyst plans to use Microsoft Sentinel with the SigninLogs table. Which KQL approach correctly identifies sign-ins from devices not previously associated with the user within the last 30 days?

A.Join the SigninLogs table with itself to find the earliest sign-in per user and device, then filter for those that match the earliest timestamp

B.Use the _GetWatchlist function with a custom watchlist of known user-device pairs

C.Use the BehaviorAnalytics table which already identifies new devices

D.Apply the 'where DeviceId != '' and DeviceId startswith "device-"' filter to ensure the device is new

AnswerA

The correct logic is to derive the earliest sign-in timestamp for each user-device pair using `summarize arg_min(TimeGenerated, *) by UserId, DeviceId` and then join that summary back to the original SigninLogs table on the same user, device, and timestamp. This self-join effectively identifies only the first occurrence of a sign-in for that combination, so any row in the original table that matches the earliest timestamp for its pair is a new-device sign-in. This approach uses historical data already in the table and does not require external lists or pre-computed analytics, making it a fully self-contained and accurate detection.

Why this answer

It uses a self-join on the SigninLogs table to identify the earliest sign-in per user-device pair within the last 30 days. By filtering for rows where the sign-in timestamp matches the earliest timestamp, the query isolates sign-ins from devices that have never been used by that user before, effectively detecting first-time device usage.

Exam trap

The trap here is that candidates may assume a watchlist or pre-built table like BehaviorAnalytics is the easiest solution, but Microsoft Sentinel requires raw log analysis with KQL self-joins to dynamically detect first-time device usage without manual maintenance.

How to eliminate wrong answers

Option B is wrong because the _GetWatchlist function requires a pre-built watchlist of known user-device pairs, which is a manual, static approach that does not dynamically detect new devices within the last 30 days. Option C is wrong because the BehaviorAnalytics table provides pre-computed behavioral insights but does not directly contain raw sign-in logs or device-level data to identify new devices per user; it relies on underlying tables like SigninLogs for such analysis. Option D is wrong because filtering by DeviceId != '' and DeviceId startswith 'device-' does not identify new devices; it merely excludes empty or non-matching device IDs, and the prefix 'device-' is not a standard Azure AD device ID format.

Full explanation →

MCQmedium

A large enterprise uses Microsoft Defender for Cloud with all enhanced security plans (e.g., Defender for Servers, Defender for SQL) enabled on a management group. The security team wants to automatically enable these plans on new Azure subscriptions that are created under this management group. Which approach is the most efficient and scalable?

A.Use an Azure Policy definition that enforces the Microsoft Defender for Cloud pricing tier (Standard) at the management group scope.

B.Manually enable the plans for each new subscription when it is created.

C.Create an Azure Automation runbook that runs on a schedule and enables plans for all subscriptions under the management group.

D.Use Azure Blueprints to define the Defender for Cloud settings in the blueprint definition.

AnswerA

Azure Policy's built-in 'Configure Microsoft Defender for Cloud plans to be enabled' definition, assigned at the management group, uses the DeployIfNotExists effect to update the pricing tier of every subscription under that scope. Because policy inheritance is evaluated continuously, any subscription created later is non-compliant until remediated, and the policy engine will automatically enable the Defender plans without human intervention. This provides declarative, continuous enforcement that scales across the entire enterprise.

Why this answer

Azure Policy can be assigned at the management group scope to enforce the 'Standard' pricing tier for Microsoft Defender for Cloud on all current and future subscriptions. This ensures that when a new subscription is created under that management group, the policy automatically evaluates and remediates the subscription to enable the required Defender plans, providing a fully automated, scalable, and governance-driven approach without manual intervention or custom scripting.

Exam trap

The trap here is that candidates often confuse Azure Blueprints (which apply settings only at deployment time) with Azure Policy (which provides continuous enforcement and automatic remediation), leading them to choose the Blueprints option despite its lack of ongoing compliance and scalability for new subscriptions.

How to eliminate wrong answers

Option B is wrong because manually enabling plans for each new subscription is not scalable, introduces human error, and violates the principle of automated governance at scale. Option C is wrong because an Azure Automation runbook running on a schedule introduces latency, requires custom code and credential management, and does not provide real-time enforcement or compliance reporting like Azure Policy does. Option D is wrong because Azure Blueprints are deprecated in favor of deployment stacks and do not provide continuous enforcement of Defender for Cloud pricing tiers; they only apply settings at deployment time and do not automatically remediate drift or new subscriptions after the blueprint assignment.

Full explanation →

MCQmedium

A SOC team uses Microsoft Sentinel. They need to correlate syslog events from on-premises firewalls with Microsoft Entra ID sign-in logs to detect VPN-based intrusions. The correlation requires joining two tables (Syslog and SigninLogs) on a common field (IP address) and running on a 10-minute schedule. Which type of analytics rule should the analyst configure?

A.Scheduled query rule

B.Near-real-time (NRT) rule

C.Fusion rule

D.Anomaly rule

AnswerA

Scheduled query rules are the correct choice for correlating Syslog with other data sources because they accept fully custom KQL queries that can join, union, or aggregate multiple tables. You can schedule the query to run at any interval and define alert logic that matches your correlation criteria, such as joining Syslog and CommonSecurityLog on hostname or source IP. The alert generated includes the full query results, enabling analysts to investigate both sides of the correlation directly from the incident.

Why this answer

A scheduled query rule is correct because the requirement involves joining two tables (Syslog and SigninLogs) on a common field (IP address) and running on a 10-minute schedule. Scheduled query rules are designed for complex, multi-table correlations that run at fixed intervals (e.g., every 10 minutes) and can aggregate or join data across tables, making them ideal for this VPN intrusion detection scenario.

Exam trap

The trap here is that candidates often confuse NRT rules with scheduled rules, but NRT rules cannot perform multi-table joins, which is explicitly required by the question's correlation of Syslog and SigninLogs.

How to eliminate wrong answers

Option B is wrong because near-real-time (NRT) rules run every minute with a 1-minute lookback and cannot join multiple tables; they only support a single table query. Option C is wrong because Fusion rules are based on Microsoft's built-in machine learning correlation of multiple alert types, not custom user-defined joins on syslog and sign-in logs. Option D is wrong because anomaly rules use machine learning to detect unusual patterns in a single data source over time, not cross-table joins on a fixed schedule.

Full explanation →

MCQeasy

A security analyst is investigating a phishing incident in Microsoft 365 Defender. They need to view the original email's sender, delivery action, and any automated remediation steps taken. Which entity page should the analyst open?

A.User entity page

B.Device entity page

C.Email entity page

D.IP entity page

AnswerC

The email entity page is the definitive source for email-related investigation in Microsoft 365 Defender, offering the full message envelope: sender and recipient addresses, message ID, subject, and the deliver action—such as delivered, blocked, or quarantined—along with any automated remediation steps, including zero-hour auto purge (ZAP) or soft deletion. Because a phishing incident centers on the email itself, this page directly exposes the evidence needed to trace the message's path and confirm the incident's scope, making it the correct choice for such investigations.

Why this answer

The Email entity page in Microsoft 365 Defender (part of Microsoft Defender XDR) is specifically designed to provide a comprehensive view of an email message, including the original sender, delivery action (e.g., delivered, quarantined, blocked), and any automated remediation steps (e.g., zero-hour auto purge, soft delete). This page aggregates data from Exchange Online Protection (EOP) and Microsoft Defender for Office 365, making it the correct choice for investigating phishing incidents.

Exam trap

The trap here is that candidates may confuse the User entity page with email investigation because user accounts are often involved in phishing, but the User entity page lacks the specific email message-level details (sender, delivery action, remediation) that only the Email entity page provides.

How to eliminate wrong answers

Option A is wrong because the User entity page focuses on user-related activities, sign-ins, and alerts, but does not expose the original email's sender, delivery action, or remediation steps for a specific message. Option B is wrong because the Device entity page is used for investigating device-level threats, such as malware or suspicious processes, and has no context for email-specific attributes like sender or delivery action. Option D is wrong because the IP entity page provides information about network traffic and IP reputation, but it cannot show the original email's sender or automated remediation steps taken on a message.

Full explanation →

MCQmedium

A SOC analyst wants to leverage Microsoft Sentinel's User and Entity Behavior Analytics (UEBA) to detect anomalous sign-in attempts where a user signs in from a country outside their typical pattern. The analyst needs to create an analytics rule that queries the necessary UEBA data. Which Sentinel table should the rule's KQL query primarily reference to evaluate geographic anomalies?

A.SigninLogs

B.BehaviorAnalytics

C.IdentityInfo

D.AADUserRiskEvents

AnswerB

BehaviorAnalytics is the dedicated table where Sentinel's UEBA writes the results of its ML-based behavioral modeling, including weekly baseline scores, geographic anomaly indicators, device trust levels, and time-activity patterns. It exposes rich columns such as UsersInsights, DevicesInsights, and ActivityInsights, each containing structured flags and confidence scores for anomalies like impossible travel or unusual geo-zone sign-ins. Because this table is purpose-built for enriched behavioral evidence, it is the correct target when an analyst needs geographic anomaly detection computed by UEBA.

Why this answer

The BehaviorAnalytics table in Microsoft Sentinel is specifically designed to store UEBA output, including normalized user behavior data such as historical geo-location patterns and anomaly scores. By querying this table, the analyst can directly access pre-computed anomalies for sign-in location deviations without needing to perform complex baseline calculations on raw SigninLogs.

Exam trap

The trap here is that candidates often assume raw sign-in logs (SigninLogs) are sufficient for UEBA-based detection, not realizing that Microsoft Sentinel's UEBA pre-processes and enriches the data into the BehaviorAnalytics table, which is the authoritative source for anomaly queries.

How to eliminate wrong answers

Option A is wrong because SigninLogs contains raw Azure AD sign-in events but lacks the pre-computed behavioral baselines and anomaly scores that UEBA provides, requiring the analyst to manually build and maintain a baseline for geographic patterns. Option C is wrong because IdentityInfo stores user profile and attribute data (e.g., job title, department) but does not contain sign-in activity or behavioral analytics. Option D is wrong because AADUserRiskEvents logs risk detections from Azure AD Identity Protection (e.g., leaked credentials, impossible travel) but does not expose the UEBA-derived geographic anomaly scores or the normalized behavior records found in BehaviorAnalytics.

Full explanation →

MCQmedium

Your SOC team uses Microsoft Sentinel with multiple workspaces across regions. You need to implement a solution that allows analysts to query all workspaces from a single location without moving data. Which feature should you configure?

A.Use cross-workspace queries with workspace() expressions in KQL.

B.Export data to Azure Data Explorer and query there.

C.Create a single Log Analytics workspace and have all data sources send logs there.

D.Configure Azure Lighthouse to manage all workspaces.

AnswerA

Cross-workspace queries allow querying multiple workspaces without moving data.

Why this answer

Cross-workspace queries using the `workspace()` expression in KQL allow analysts to query multiple Log Analytics workspaces from a single query context without moving or centralizing the data. This is the native Microsoft Sentinel feature designed for multi-workspace environments, enabling seamless querying across regions while keeping data in its original workspace.

Exam trap

The trap here is that candidates often confuse Azure Lighthouse (cross-tenant management) with cross-workspace querying, but Lighthouse does not provide the KQL-level query capability needed to query data across workspaces from a single query.

How to eliminate wrong answers

Option B is wrong because exporting data to Azure Data Explorer requires moving data out of Log Analytics, which contradicts the requirement of querying without moving data, and adds latency and cost for data transfer. Option C is wrong because creating a single Log Analytics workspace would require all data sources to send logs to that one location, which violates the requirement of keeping data in multiple workspaces across regions. Option D is wrong because Azure Lighthouse provides cross-tenant management capabilities but does not enable querying across multiple workspaces from a single KQL query; it only allows managing resources across tenants, not querying data across workspaces.

Full explanation →

MCQmedium

A security analyst wants to identify all users who received a phishing email that contained a known malicious URL. The analyst has the URL. Which advanced hunting table should the analyst query first to find the emails that contained this URL?

A.EmailEvents

B.EmailUrlInfo

C.EmailAttachmentInfo

D.EmailPostDeliveryEvents

AnswerB

EmailUrlInfo is the correct table because it is specifically designed to store each URL extracted from an email, along with the corresponding NetworkMessageId. By filtering EmailUrlInfo on the known malicious URL, you obtain the NetworkMessageId(s) of all emails that contained that link, which can then be joined to EmailEvents to retrieve the recipient list. This table is the authoritative source for URL-to-email correlations in Advanced Hunting.

Why this answer

The EmailUrlInfo table in Microsoft Defender XDR contains records of URLs extracted from email messages, including the specific URL and the email's unique identifier (NetworkMessageId). By querying this table for the known malicious URL, the analyst can retrieve the NetworkMessageIds of all emails containing that URL, which can then be joined with the EmailEvents table to identify the recipients. This is the most direct and efficient first step because EmailUrlInfo is purpose-built to map URLs to email messages.

Exam trap

The trap here is that candidates often jump to EmailEvents thinking it contains all email details, but they forget that URL content is stored in a separate table (EmailUrlInfo) and must be queried first to identify the specific emails.

How to eliminate wrong answers

Option A is wrong because EmailEvents contains metadata about email delivery (sender, recipient, subject, delivery action) but does not include the actual URL content; it cannot be queried directly to find emails containing a specific URL. Option C is wrong because EmailAttachmentInfo stores information about email attachments (file names, hashes, sizes) and is used for malware or attachment-based threats, not for identifying URLs within the email body. Option D is wrong because EmailPostDeliveryEvents tracks actions taken on emails after delivery (e.g., user clicks, admin moves, ZAP actions) and does not contain the original URL content from the email.

Full explanation →

MCQeasy

Your organization uses Microsoft Defender for Endpoint. You need to ensure that when a high severity alert is generated, an automated investigation is launched immediately. What is the correct configuration?

A.Create a custom indicator in Microsoft Defender for Endpoint.

B.Use advanced hunting to create a custom detection rule.

C.In Microsoft Defender for Endpoint, set up an alert suppression rule.

D.In Microsoft 365 Defender, configure automated investigation and response settings to automatically investigate alerts.

AnswerD

The automated investigation settings allow you to set the automation level for different alert groups, including high severity.

Why this answer

Microsoft 365 Defender's automated investigation and response (AIR) capabilities allow you to configure automatic investigation for alerts of specific severity levels. By enabling this setting for high severity alerts, Defender for Endpoint will immediately launch an investigation when such an alert is generated, without requiring manual intervention.

Exam trap

The trap here is that candidates often confuse custom detection rules (advanced hunting) or custom indicators with the ability to trigger automated investigations, when in fact the correct configuration is a simple toggle in the automated investigation and response settings within Microsoft 365 Defender.

How to eliminate wrong answers

Option A is wrong because custom indicators (IOCs) are used to define entities like files, IPs, or domains for detection, alerting, or blocking—they do not control automated investigation launch behavior. Option B is wrong because advanced hunting custom detection rules create custom alerts based on KQL queries, but they do not configure the automatic investigation trigger for existing high severity alerts. Option C is wrong because alert suppression rules are designed to suppress or hide alerts based on criteria, not to initiate automated investigations.

Full explanation →

MCQmedium

A security analyst is investigating a potential malware outbreak using Microsoft 365 Defender advanced hunting. The analyst wants to find all devices where a file with a specific SHA256 hash was first created and then later deleted, which may indicate a cleanup attempt. Which query pattern on the DeviceFileEvents table is appropriate?

A.DeviceFileEvents | where SHA256 == "<hash>" | summarize Actions = make_set(ActionType) by DeviceId | where Actions has_all ("FileCreated", "FileDeleted")

B.DeviceFileEvents | where SHA256 == "<hash>" and ActionType == "FileDeleted" | project DeviceId

C.DeviceFileEvents | where FileHash == "<hash>" | summarize Actions = make_set(ActionType) by DeviceId | where Actions has "FileCreated"

D.DeviceFileEvents | summarize by DeviceId, ActionType | where ActionType in ("FileCreated", "FileDeleted")

AnswerA

This query correctly identifies devices by first filtering DeviceFileEvents to only rows where SHA256 equals the known malicious hash. The summarize operator then groups by DeviceId and uses make_set(ActionType) to build an array of every file action observed for that file on each device. The subsequent where clause with has_all ensures that both 'FileCreated' and 'FileDeleted' appear in that array, verifying the file was created and later deleted on the same device. This precisely matches the requirement to find devices exhibiting both lifecycle events for the same file hash.

Why this answer

It first filters by the specific SHA256 hash, then uses `make_set(ActionType)` to collect all actions per device, and finally checks that both 'FileCreated' and 'FileDeleted' appear in the set. This precisely identifies devices where the file was both created and later deleted, indicating a potential cleanup attempt.

Exam trap

The trap here is that candidates may confuse the column name `SHA256` with `FileHash` (which does not exist in DeviceFileEvents) or forget to filter by the specific hash before summarizing, leading to false positives from unrelated file operations.

How to eliminate wrong answers

Option B is wrong because it only looks for 'FileDeleted' events, missing the requirement that the file must have been first created on the same device. Option C is wrong because it uses `FileHash` instead of `SHA256` (the correct column name in DeviceFileEvents) and only checks for 'FileCreated', not both actions. Option D is wrong because it summarizes by DeviceId and ActionType without filtering by the specific hash, returning all devices with any create/delete actions rather than those related to the target file.

Full explanation →

MCQhard

Your organization uses Microsoft Defender for Cloud to monitor hybrid workloads. You need to ensure that security alerts from on-premises servers running Windows Server 2022 are forwarded to Microsoft Sentinel. The servers are not yet onboarded to Azure Arc. What should you do first?

A.Install the Azure Monitor Agent on the servers.

B.Deploy Azure Policy to enable Defender for Cloud on the servers.

C.Onboard the servers to Azure Arc and enable Defender for Cloud.

D.Install Microsoft Defender for Endpoint on the servers.

AnswerC

Arc provides the identity and management needed for Defender for Cloud to monitor on-prem servers.

Why this answer

On-premises servers must first be onboarded to Azure Arc to establish a management identity and connectivity with Azure. Without Azure Arc, Defender for Cloud cannot apply its security policies or forward alerts to Microsoft Sentinel. Enabling Defender for Cloud on the servers after Arc onboarding allows security alerts to be collected and forwarded to Sentinel.

Exam trap

The trap here is that candidates often assume installing an agent (AMA or MDE) is sufficient to forward alerts to Sentinel, but Microsoft requires Azure Arc as the foundational onboarding step to bring non-Azure servers into the Azure management plane before Defender for Cloud can generate and forward security alerts.

How to eliminate wrong answers

Option A is wrong because the Azure Monitor Agent (AMA) can collect telemetry but does not enable Defender for Cloud's security alert generation or forwarding to Sentinel; AMA is a data collection agent, not a prerequisite for Defender for Cloud integration. Option B is wrong because Azure Policy can enforce configurations only on resources already managed by Azure; without Azure Arc, the on-premises servers are not visible to Azure Policy. Option D is wrong because Microsoft Defender for Endpoint (MDE) provides endpoint detection and response but does not, by itself, forward security alerts to Sentinel; MDE integration with Sentinel requires the servers to be onboarded to Azure Arc or have a direct data connector configured.

Full explanation →

MCQmedium

A SOC analyst needs to create a scheduled analytics rule in Microsoft Sentinel that detects when a user logs in from an IP address that is not in a predefined list of known corporate IP ranges. The list is maintained as a custom Sentinel watchlist and frequently updated. Which KQL function should the analyst use to reference the watchlist within the rule's query?

A.externaldata()

B._GetWatchlist()

C.lookup()

D.invoke()

AnswerB

_GetWatchlist() is the correct, built-in KQL function specifically designed to return the content of a Microsoft Sentinel watchlist by name. For example, _GetWatchlist('IPSAllowlist') returns a table with the watchlist's columns and rows, which you can then join with or filter against other data in the analytics rule query. This function is the native mechanism for operationalizing watchlists in scheduled rules and is preferred over generic operators because it handles the internal watchlist schema automatically.

Why this answer

The _GetWatchlist() function is the correct KQL function to reference a custom Sentinel watchlist within an analytics rule query. It retrieves the watchlist content as a table, allowing the analyst to join or filter login events against the known corporate IP ranges. This function is specifically designed for Sentinel watchlists and supports frequent updates without modifying the rule query.

Exam trap

The trap here is that candidates may confuse _GetWatchlist() with externaldata() or lookup(), thinking they can achieve the same result, but only _GetWatchlist() is designed for Sentinel watchlists and integrates seamlessly with analytics rules.

How to eliminate wrong answers

Option A is wrong because externaldata() is used to query external data sources like Azure Blob Storage or files, not Sentinel watchlists, and requires a direct URI reference. Option C is wrong because lookup() is a KQL operator for joining tables based on a key, but it does not directly retrieve watchlist data; it would require the watchlist to already be in a table format. Option D is wrong because invoke() is used to call a function or a machine learning model, not to access watchlist data, and is not relevant for referencing a watchlist in a query.

Full explanation →

MCQmedium

Your organization uses Microsoft Sentinel and Microsoft Defender for Cloud Apps to monitor cloud application usage. You have a custom analytics rule that detects multiple failed login attempts from different IP addresses for the same user within 5 minutes. This rule generates an incident. The security team wants to automatically suspend the user in Microsoft Entra ID (formerly Azure AD) when such an incident is created, but only if the user is not a member of the 'Emergency Access' group. You need to implement this automation. You have already created the analytics rule. What should you do next?

A.Modify the analytics rule to include a condition that checks the user's group membership using KQL.

B.Create an automation rule that suspends the user directly using a condition on the incident.

C.Create an automation rule that triggers on incident creation and runs a playbook that suspends the user.

D.Create a playbook that uses the Microsoft Entra ID connector to check if the user is a member of the 'Emergency Access' group. If not, suspend the user. Then create an automation rule that runs this playbook on incident creation.

AnswerD

A playbook can use conditional logic to check group membership and then take action. The automation rule triggers the playbook.

Why this answer

A playbook can check group membership and take action. Option A is wrong because automation rules cannot conditionally run playbooks based on group membership. Option B is wrong because modifying the analytics rule is not the way to add automation.

Option C is wrong because automation rules cannot directly suspend users.

Full explanation →

MCQmedium

A security analyst is investigating an incident in Microsoft 365 Defender where a user's device is suspected to be compromised. The analyst wants to collect a copy of a specific suspicious file from the device for offline analysis without disrupting the user. Which action should the analyst initiate?

A.Initiate a Live Response session

B.Isolate the device from the network

C.Initiate an automated investigation

D.Run a full antivirus scan

AnswerA

Live Response is a Microsoft Defender for Endpoint capability that opens an authenticated, remote command-line shell to the device. Using commands like 'collectfile' or 'getfile', an analyst can retrieve a specific file copy without changing the system state or interrupting the user's session, making it ideal for preserving evidence and performing focused file collection.

Why this answer

A Live Response session allows the analyst to remotely connect to the device in real time, collect a specific suspicious file via commands like 'getfile', and download it for offline analysis without interrupting the user's workflow. This is the only action that provides targeted file collection while the device remains operational.

Exam trap

The trap here is that candidates confuse 'Live Response' with 'isolation' or 'automated investigation', thinking that any remediation action can collect files, but only Live Response provides the granular, non-disruptive file collection capability required for offline analysis.

How to eliminate wrong answers

Option B is wrong because isolating the device from the network disconnects it from all network communications, which disrupts the user and prevents file collection without additional steps. Option C is wrong because an automated investigation runs predefined playbooks to detect and remediate threats, but it does not allow the analyst to manually collect a specific file for offline analysis. Option D is wrong because a full antivirus scan scans for malware and may delete or quarantine the file, but it does not provide a copy of the file for offline analysis and can disrupt the user by consuming system resources.

Full explanation →

MCQeasy

Your organization uses Microsoft Sentinel. You need to automatically assign incidents to the appropriate SOC tier based on severity. What should you create?

A.A data connector to Microsoft Teams

B.A scheduled analytics rule

C.A playbook in Microsoft Power Automate

D.An automation rule with an owner assignment action

AnswerD

Automation rules can assign incidents to specific users or groups.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically assign incidents to specific owners based on conditions like severity, using the 'Assign owner' action. This directly meets the requirement to route incidents to the appropriate SOC tier without manual intervention, leveraging Sentinel's native incident management capabilities.

Exam trap

The trap here is that candidates often confuse automation rules with playbooks, assuming that any automated response requires a playbook, when in fact simple owner assignment is a native automation rule action that does not need a separate playbook or Power Automate workflow.

How to eliminate wrong answers

Option A is wrong because a data connector to Microsoft Teams is used to ingest collaboration data (e.g., chat logs) into Sentinel for analysis, not to automate incident assignment based on severity. Option B is wrong because a scheduled analytics rule generates alerts from log data based on a query schedule, but it does not perform post-incident actions like owner assignment; it only creates incidents or alerts. Option C is wrong because a playbook in Microsoft Power Automate (or Azure Logic Apps) can automate response actions, but it is typically triggered by an automation rule or analytics rule, not directly used for initial owner assignment; the native 'Assign owner' action in automation rules is the correct, simpler method for this specific requirement.

Full explanation →

MCQhard

A security analyst is using advanced hunting in Microsoft 365 Defender to detect lateral movement. The analyst wants to find all devices where a specific user account had an interactive logon, and then identify which of those devices subsequently initiated outbound Remote Desktop Protocol (RDP) connections to other internal IP addresses. Which KQL approach is most efficient for this investigation?

A.Use DeviceLogonEvents and DeviceNetworkEvents with a join on DeviceId and a time range

B.Use IdentityLogonEvents and DeviceNetworkEvents with a join on IP address

C.Use DeviceProcessEvents and DeviceNetworkEvents with a join on DeviceId

D.Use EmailEvents and DeviceLogonEvents with a join on RecipientEmail

AnswerA

DeviceLogonEvents records successful interactive and remote logons to a machine, including the target DeviceId, the authenticating account, and the source device/IP. DeviceNetworkEvents logs outbound connection attempts from that same device, with destination IP and port. By joining on DeviceId and filtering to the short time window after the logon record—especially while looking for destination port 3389 or other RDP ports—you can link the account that just logged on to an immediate outbound RDP connection from that device to another host, which is a classic lateral-movement indicator.

Why this answer

It uses DeviceLogonEvents to identify interactive logons for the specific user account on devices, then joins those results with DeviceNetworkEvents on DeviceId within a time range to find subsequent outbound RDP connections (destination port 3389) to internal IPs. This approach directly correlates the user's logon activity with network connections from the same device, which is the most efficient and precise method for detecting lateral movement via RDP.

Exam trap

The trap here is that candidates may confuse IdentityLogonEvents (cloud identity) with DeviceLogonEvents (device-level logon), leading them to choose Option B, but the correct approach requires device-specific logon data to correlate with network events on the same device.

How to eliminate wrong answers

Option B is wrong because IdentityLogonEvents captures cloud identity logons (e.g., Azure AD) rather than device-level interactive logons, and joining on IP address is unreliable due to NAT and shared IPs, making it ineffective for correlating a specific device's network activity. Option C is wrong because DeviceProcessEvents tracks process creation events, not interactive logons; while it could indirectly indicate logon activity, it is less direct and less efficient than using DeviceLogonEvents for the specific user account. Option D is wrong because EmailEvents deals with email delivery and recipient data, which is irrelevant to device logons or RDP network connections; joining on RecipientEmail has no bearing on lateral movement detection.

Full explanation →

MCQmedium

A SOC analyst creates a watchlist in Microsoft Sentinel from a CSV file containing IP ranges (10.0.0.0/16) and a tag. The analyst wants to use this watchlist in a KQL query to check if a sign-in IP is within the ranges. Which KQL function should be used?

A._GetWatchlist('name') and use the has operator

B._GetWatchlist('name') and use the in operator

C._GetWatchlist('name') and use the ipv4_is_in_range function with the watchlist as a parameter

D._GetWatchlist('name') and use the contains operator

AnswerC

The `ipv4_is_in_range` function is the correct KQL scalar function for this scenario because it parses its first argument as an IPv4 address and the second as a CIDR range, returning a boolean representing membership. Using `_GetWatchlist('name')` provides the table of range strings, and you join or filter so each watchlist range is passed as the second parameter against the sign-in IP column. For IPv6 subnets, `ipv6_is_in_range` offers the same capability, making this a network-aware approach rather than a text-based match.

Why this answer

The `ipv4_is_in_range` function is designed to check whether an IPv4 address falls within a specified CIDR range. When combined with `_GetWatchlist('name')`, you can iterate over the watchlist entries and use `ipv4_is_in_range` to compare the sign-in IP against each range. This is the only approach that correctly handles CIDR notation (e.g., 10.0.0.0/16) rather than performing string matching or exact value comparison.

Exam trap

The trap here is that candidates often confuse string-matching operators (has, contains, in) with IP-specific functions, failing to recognize that CIDR range evaluation requires a dedicated function like `ipv4_is_in_range`.

How to eliminate wrong answers

Option A is wrong because the `has` operator performs substring matching on strings, not IP range evaluation; it would incorrectly match partial IPs or fail to interpret CIDR notation. Option B is wrong because the `in` operator checks for exact equality of values, so it cannot match an IP against a CIDR range unless the IP exactly equals the range string. Option D is wrong because the `contains` operator also performs substring matching and would not evaluate whether an IP falls within a CIDR range.

Full explanation →

MCQmedium

A security team needs to enforce that all Azure virtual machines have a specific custom script execution baseline (e.g., block PowerShell from executing scripts from the internet). They want to use Microsoft Defender for Cloud to continuously monitor and alert when a VM deviates from this baseline. Which feature should they use?

A.Just-In-Time VM Access (JIT)

B.Adaptive application controls

C.Regulatory compliance dashboard

D.File Integrity Monitoring (FIM)

AnswerB

Adaptive application controls is the correct control because it is a runtime host-based allowlisting solution in Microsoft Defender for Cloud that builds a machine-generated baseline of trusted applications and scripts for each VM. Using machine learning, it whitelists known-safe executables and script behavior patterns, then both audits and, when configured to 'Deny' mode, blocks unapproved executables or scripts—such as a PowerShell payload retrieved from the internet—at the moment of execution. This provides the precise enforcement mechanism needed to keep unauthorized scripts from running on Azure VMs.

Why this answer

Adaptive application controls (AAC) in Microsoft Defender for Cloud allow you to define allowlists for applications and scripts that can run on your Azure VMs. By configuring AAC to block PowerShell scripts from the internet, the service uses machine learning to establish a baseline of allowed executables and scripts, then continuously monitors for deviations—such as an unauthorized PowerShell script execution—and generates security alerts. This directly meets the requirement for continuous monitoring and alerting on custom script execution baselines.

Exam trap

The trap here is that candidates confuse File Integrity Monitoring (FIM) with script execution control, but FIM only monitors file and registry changes, not the execution behavior of scripts or applications.

How to eliminate wrong answers

Option A is wrong because Just-In-Time VM Access (JIT) controls network access to management ports (e.g., RDP, SSH) and does not monitor or enforce script execution policies. Option C is wrong because the Regulatory compliance dashboard tracks compliance against standards like ISO 27001 or PCI DSS, not custom script execution baselines. Option D is wrong because File Integrity Monitoring (FIM) monitors changes to registry keys and critical files (e.g., system binaries), not script execution behavior or PowerShell policies.

Full explanation →

MCQmedium

A security analyst is investigating a potential business email compromise (BEC) campaign. The analyst wants to find all emails that were sent to external recipients from an internal user's mailbox that also had a login from an unusual location shortly after the email was sent. Which advanced hunting tables should the analyst query to get the email metadata and the sign-in details?

A.EmailEvents and AADSignInEventsBeta

B.EmailPostDeliveryEvents and DeviceLogonEvents

C.EmailAttachmentInfo and IdentityLogonEvents

D.EmailUrlInfo and CloudAppEvents

AnswerA

EmailEvents is the correct source for the send side of a business email compromise because it records the sender's SMTP address, recipient, subject, and send timestamp for every outbound message. AADSignInEventsBeta is equally essential for the sign-in side, capturing interactive and non-interactive authentication events against Microsoft Entra ID with fields like UserPrincipalName, IP address, and risk level. Joining on the sender's SMTP address to the sign-in UPN lets you correlate an anomalous sign-in with a suspicious email sent by that account, which directly ties the initial phish to attacker authentication.

Why this answer

EmailEvents stores email metadata (sender, recipient, subject, etc.) and AADSignInEventsBeta captures Azure AD sign-in logs, including location data. Joining these tables on the user's account object ID allows the analyst to correlate emails sent to external recipients with unusual sign-in locations shortly after the email was sent, directly addressing the BEC investigation scenario.

Exam trap

The trap here is that candidates confuse DeviceLogonEvents or IdentityLogonEvents with Azure AD sign-in logs, not realizing that AADSignInEventsBeta is the only table that captures cloud-based sign-in location data for Microsoft 365 services like Exchange Online.

How to eliminate wrong answers

Option B is wrong because EmailPostDeliveryEvents contains post-delivery actions (e.g., remediation, ZAP) and DeviceLogonEvents captures device-level logons (e.g., Windows sign-ins), not mailbox sign-ins or email metadata; this combination cannot correlate email sends with Azure AD sign-in locations. Option C is wrong because EmailAttachmentInfo only provides attachment metadata (file name, hash) and IdentityLogonEvents records identity-based logons (e.g., on-premises Active Directory), not Azure AD sign-ins with location details; it lacks the core email metadata needed. Option D is wrong because EmailUrlInfo stores URL click data from emails and CloudAppEvents tracks activities in cloud apps (e.g., Office 365 operations), but CloudAppEvents does not provide the precise sign-in location and timestamp needed for the unusual login correlation; it focuses on app-level actions rather than authentication events.

Full explanation →

100

MCQmedium

An organization uses Microsoft 365 Defender. A security analyst is investigating an incident where a user received a phishing email that contained a link to a malicious domain. The user clicked the link, but the domain was blocked by Microsoft Defender for Office 365 at the time of click. The analyst needs to view the full details of the click verdict, including the time of click and the specific block action (e.g., blocked by custom block list). Where can the analyst find this information?

A.Attachments tab

B.Detection details section

C.Timeline section

D.User entity page

AnswerB

The Detection details section on the email entity page provides the click verdict, block reason, and action taken for URLs.

Why this answer

The Detection details section in the Microsoft 365 Defender portal provides the full click verdict for a URL, including the exact time of the click and the specific block action (e.g., blocked by custom block list, blocked by reputation). This information is part of the URL click verdict data logged by Microsoft Defender for Office 365 when Safe Links evaluates a clicked link. The analyst can access this by navigating to the incident's URL entity and selecting the Detection details tab.

Exam trap

The trap here is that candidates often confuse the Timeline section (which shows general event chronology) with the Detection details section (which provides the specific URL click verdict and block action), leading them to select Option C incorrectly.

How to eliminate wrong answers

Option A is wrong because the Attachments tab only shows details about email attachments (e.g., file hashes, malware detections), not URL click verdicts or block actions. Option C is wrong because the Timeline section provides a chronological view of alerts and events but does not expose the granular click verdict details like the specific block action or exact click time for a URL. Option D is wrong because the User entity page shows user-related information (e.g., risk level, activity, alerts) but does not contain the URL click verdict data, which is tied to the URL entity itself.

Full explanation →

101

MCQeasy

An analyst is investigating a phishing campaign that targeted multiple users. The analyst needs to identify if any users clicked a malicious link in the email. Which Microsoft Defender for Office 365 feature should be used?

A.Safe Attachments

B.Threat Explorer

C.Attack Simulator

D.Safe Links

AnswerB

Threat Explorer provides URL click data.

Why this answer

Threat Explorer (also known as Explorer) in Microsoft Defender for Office 365 provides a real-time, interactive view of threat data, including email delivery status and user actions such as clicks on malicious links. It allows analysts to filter by 'Click action' to identify users who clicked a URL that was determined to be malicious, making it the correct tool for this investigation.

Exam trap

The trap here is that candidates often confuse the protection features (Safe Links and Safe Attachments) with the investigation tool (Threat Explorer), assuming that because Safe Links blocks malicious clicks, it also provides historical click reports, when in fact Threat Explorer is the dedicated hunting and investigation tool for analyzing user actions.

How to eliminate wrong answers

Option A is wrong because Safe Attachments is a protection feature that detonates email attachments in a sandbox environment to detect malware, but it does not track or report user clicks on links. Option C is wrong because Attack Simulator is a training and simulation tool used to launch simulated phishing attacks to test user awareness, not to investigate past real-world phishing campaigns. Option D is wrong because Safe Links is a protection feature that rewrites URLs and checks them at time of click to block malicious destinations, but it does not provide a historical log or report of which users clicked a specific malicious link in a past campaign.

Full explanation →

102

MCQmedium

An organization uses Microsoft 365 Defender. An automated investigation on a device identifies a malicious file and blocks it. The analyst now wants to allow a specific trusted application that was incorrectly blocked, while keeping other malicious files blocked. Which action should the analyst take from the device's entity page?

A.Initiate a live response session and delete the file manually.

B.Use the 'Add indicator' feature to create a custom IOC for the file hash with action 'Allow'.

C.Change the automated investigation settings to 'No action' and rerun investigation.

D.Collect the file for analysis; the allow decision must be made by Microsoft after analysis.

AnswerB

Creating a custom indicator for the file hash with the 'Allow' action instructs Microsoft Defender for Endpoint (and connected Microsoft 365 Defender services) to treat the file as trusted, overriding the automated investigation's block. This indicator is a tenant-level override that applies to all monitored devices and allows the file to run without triggering future alerts. After adding the indicator, the file is permitted and the automated investigation's block is effectively removed.

Why this answer

The 'Add indicator' feature in Microsoft Defender XDR allows analysts to create custom indicators of compromise (IOCs) based on file hashes, IPs, or domains. By setting the action to 'Allow' for the specific file hash, the analyst can override the automated block for that trusted application while keeping other malicious files blocked. This is the correct approach because it provides granular control without affecting the overall automated investigation settings.

Exam trap

The trap here is that candidates may confuse the 'Add indicator' feature with manual file deletion or changing global investigation settings, not realizing that a custom IOC with an Allow action is the precise mechanism to override a block for a specific trusted file.

How to eliminate wrong answers

Option A is wrong because initiating a live response session to delete the file manually does not create an allow rule; it only removes the file, and the block action from the automated investigation would still prevent the application from running. Option C is wrong because changing the automated investigation settings to 'No action' would disable all automated responses for future detections, not selectively allow a specific file. Option D is wrong because collecting the file for analysis does not immediately allow the file; Microsoft analysis is for threat intelligence, not for overriding a block on a trusted application.

Full explanation →

103

MCQhard

A company has multiple Azure subscriptions under a management group. They want to ensure that all VMs across all subscriptions have Microsoft Defender for Cloud's vulnerability assessment solution (using the Microsoft Defender Vulnerability Management engine) enabled. They also want to automatically remediate any non-compliant VMs by enabling the VA solution when a VM is missing it. Which combination of policy initiatives and automation should they use?

A.Assign the 'Azure Security Benchmark' initiative at the management group, enable automatic remediation for the 'Vulnerability assessment should be enabled on your virtual machines' policy.

B.Assign the 'Defender for Cloud' initiative with the 'Configure machines to receive a vulnerability assessment provider' policy, and configure a remediation task with a deployment script.

C.Assign the 'Azure Security Benchmark' initiative and create an Azure Automation runbook triggered by a compliance alert to enable VA.

D.Assign the 'Configure machines to receive a vulnerability assessment provider' policy with 'DeployIfNotExists' effect and set it to auto-remediate at the management group-level scope.

AnswerD

The built-in DeployIfNotExists policy 'Configure machines to receive a vulnerability assessment provider' automatically installs the vulnerability assessment agent/extension on any virtual machine that does not have it. Assigning this policy at the management group scope makes the effect apply to every subscription and VM under that group, and enabling the remediation task in the assignment ensures existing non-compliant VMs are also remediated, not just new ones. This approach couples detection with deployment, which is the key difference from audit-only options, and it uses the standard Azure Policy lifecycle without custom scripts or runbooks.

Why this answer

The 'Configure machines to receive a vulnerability assessment provider' policy with the 'DeployIfNotExists' effect directly deploys the Microsoft Defender Vulnerability Management (MDVM) extension to any VM that lacks it. By assigning this policy at the management group scope and enabling automatic remediation, the policy will automatically remediate non-compliant VMs without requiring additional runbooks or scripts, fulfilling both the detection and automatic remediation requirements.

Exam trap

The trap here is that candidates often confuse 'AuditIfNotExists' policies (which only report compliance) with 'DeployIfNotExists' policies (which can automatically remediate), leading them to choose options that rely on audit-only policies or external automation when a built-in deployment policy with auto-remediation is available.

How to eliminate wrong answers

Option A is wrong because the 'Azure Security Benchmark' initiative includes the 'Vulnerability assessment should be enabled on your virtual machines' policy with an 'AuditIfNotExists' effect, which only audits compliance and does not automatically enable the VA solution; automatic remediation for an audit policy is not supported. Option B is wrong because while the 'Defender for Cloud' initiative contains the correct policy, the suggestion to configure a remediation task with a deployment script is unnecessary and less reliable than using the built-in 'DeployIfNotExists' effect with auto-remediation, which directly deploys the required extension. Option C is wrong because creating an Azure Automation runbook triggered by a compliance alert introduces complexity and latency, and the 'Azure Security Benchmark' initiative's audit-only policy cannot trigger automatic remediation; the correct approach uses a 'DeployIfNotExists' policy with auto-remediation.

Full explanation →

104

MCQmedium

A company uses Microsoft Defender for Cloud's Just-In-Time (JIT) VM access to secure its Azure virtual machines. A security analyst needs to grant a developer temporary RDP access to a specific VM for debugging purposes. Instead of using the default request approval flow, the analyst wants to configure an exemption so that the developer's access request never triggers a recommendation for that VM. Which action must the analyst perform?

A.Approve the access request once from the JIT blade and set a long expiration.

B.Add an exemption for the VM on the 'Management ports should be closed on just-in-time based virtual machines' recommendation.

C.Configure a custom Azure Policy to allow open management ports for that VM.

D.Disable the JIT solution for the entire subscription from the Defender for Cloud environment settings.

AnswerB

Creating an exemption for the specific VM on the 'Management ports should be closed on just-in-time based virtual machines' recommendation is the correct approach. This exclusion is resource-scoped and suppresses the recommendation for that VM alone, allowing permanent open management ports without generating alerts or affecting compliance state. Exemptions are a standard Defender for Cloud mechanism for legitimate exceptions, and they require the appropriate permissions to create, such as Security Admin or Resource Policy Contributor.

Why this answer

To prevent a specific VM from triggering a recommendation for open management ports, you must add an exemption directly on the 'Management ports should be closed on just-in-time based virtual machines' recommendation in Defender for Cloud. This exemption tells the recommendation engine to exclude that VM from compliance evaluation, so no alert or recommendation is generated for it. Approving a request with a long expiration does not suppress the underlying recommendation; it only grants temporary access.

Exam trap

The trap here is that candidates confuse 'approving a request with a long expiration' with 'exempting the VM from the recommendation,' not realizing that an exemption is a separate Azure Policy concept that permanently suppresses the recommendation for that resource.

How to eliminate wrong answers

Option A is wrong because approving a request with a long expiration still leaves the recommendation active and will continue to appear in the security recommendations list; it does not create an exemption. Option C is wrong because configuring a custom Azure Policy to allow open management ports would override the JIT policy but does not create an exemption on the specific recommendation; it would instead change the compliance state for all VMs under that policy scope, which is not the targeted exemption requested. Option D is wrong because disabling JIT for the entire subscription removes the protection from all VMs and is an overly broad action that does not meet the requirement to exempt only a single VM from the recommendation.

Full explanation →

105

MCQeasy

A company manages multiple Azure subscriptions under a single management group. The security team wants to enable Microsoft Defender for Cloud's enhanced security features (e.g., Defender for Servers) for all subscriptions under that management group with minimal administrative effort. Which method should they use?

A.Enable the plans individually on each subscription

B.Enable the plans at the management group level

C.Use Azure Blueprints to assign the plans to each subscription

D.Create a custom Azure Policy that enforces the installation of the Log Analytics agent

AnswerB

Correct. Policy and plan assignments at the management group propagate to all child subscriptions.

Why this answer

Enabling Microsoft Defender for Cloud's enhanced security features at the management group level applies the plans to all current and future subscriptions under that management group with a single action, minimizing administrative effort. This is the most efficient method because Defender for Cloud supports inheritance of security policies and plans from the management group down to subscriptions, eliminating the need for per-subscription configuration.

Exam trap

The trap here is that candidates may think Azure Blueprints or custom policies are required for bulk enablement, but Defender for Cloud natively supports enabling plans at the management group level, which is the simplest and most direct method.

How to eliminate wrong answers

Option A is wrong because enabling plans individually on each subscription requires repeated manual effort and does not scale, failing the 'minimal administrative effort' requirement. Option C is wrong because Azure Blueprints are used for deploying consistent resource configurations (e.g., ARM templates, policies, role assignments) but cannot directly enable Defender for Cloud plans; they would require a custom policy or initiative to achieve this, which is more complex than enabling at the management group. Option D is wrong because creating a custom Azure Policy to enforce the Log Analytics agent installation does not enable Defender for Cloud's enhanced security features (e.g., Defender for Servers); it only ensures agent deployment, which is a prerequisite but not the same as enabling the security plan.

Full explanation →

106

MCQeasy

You are configuring Microsoft Defender for Cloud Apps session controls for a SharePoint site containing sensitive data. Which condition must be met to apply real-time monitoring?

A.The SharePoint site must be added as a custom app in Defender for Cloud Apps.

B.Users must access the site through Microsoft Entra ID application proxy.

C.A browser extension must be installed on all client devices.

D.Users must be configured with Conditional Access policies from Microsoft Entra ID.

AnswerD

Session controls in Microsoft Defender for Cloud Apps are implemented through the Conditional Access session control pipeline in Microsoft Entra ID. When a user is subject to a Conditional Access policy that includes 'Use Conditional Access App Control' as a session control, the user's session is redirected through the Defender for Cloud Apps reverse proxy. Without this policy, the proxy never intercepts the request, so session-level monitoring and restrictions (e.g., download blocking) will not be enforced for SharePoint Online.

Why this answer

Microsoft Defender for Cloud Apps session controls for SharePoint require users to be routed through the Cloud App Security proxy, which is invoked by Conditional Access policies in Microsoft Entra ID. Conditional Access app controls apply session policies to traffic when users access SharePoint, enabling real-time monitoring. The Microsoft Entra ID application proxy is designed for on-premises apps, not for SaaS apps like SharePoint Online.

Therefore, the correct prerequisite is having Conditional Access policies configured.

Exam trap

Candidates often confuse the Microsoft Entra ID application proxy with the Cloud App Security proxy. For SharePoint Online session controls, Conditional Access policies trigger the Cloud App Security proxy, not the application proxy.

How to eliminate wrong answers

Option A is wrong because SharePoint is already a recognized app in Defender for Cloud Apps; adding it as a custom app is unnecessary and does not enable session controls. Option B is correct as explained. Option C is wrong because session controls for SharePoint do not require a client-side browser extension; the proxy handles interception server-side.

Option D is wrong because while Conditional Access policies are used to route traffic to the session control, they are not the condition that enables real-time monitoring—the proxy is the prerequisite.

Full explanation →

107

MCQhard

Your organization uses Microsoft Sentinel with the Microsoft 365 Defender connector. You are hunting for a threat that uses 'process hollowing' to evade detection. Which advanced hunting query in Microsoft Defender for Endpoint would be most effective?

A.DeviceProcessEvents | where InitiatingProcessFileName != ImageFileName | where ParentProcessFileName != ImageFileName

B.DeviceProcessEvents | where FileName in~ ('rundll32.exe', 'regsvr32.exe', 'mshta.exe')

C.DeviceFileEvents | where FileName contains 'hollow'

D.AlertInfo | where Title contains 'Process hollowing'

AnswerA

Process hollowing typically involves a process where the original image is replaced; this query finds mismatches between initiating, parent, and image file names.

Why this answer

Process hollowing often involves a child process with a different parent image; DeviceProcessEvents can show such anomalies. Option B is wrong because it looks for specific image names. Option C is wrong because file events are less direct.

Option D is wrong because it waits for alerts.

Full explanation →

108

MCQeasy

Refer to the exhibit. An admin creates this activity policy in Microsoft Defender for Cloud Apps. What will happen when a user fails to log in from 3 different IP addresses within 10 minutes?

A.The policy will generate an alert but not block the user.

B.The user will be blocked immediately after the third failed login from any IP.

C.The user will be blocked after 10 minutes regardless of the number of IPs.

D.The user will be blocked only if the third IP is different from the first two.

AnswerD

The policy requires 3 distinct IP addresses; after the third distinct IP, the user is blocked.

Why this answer

The policy triggers when the count of different IPs for failed logins reaches 3 within 10 minutes. The action is to block the user. 'DifferentCount' means distinct IPs, not total attempts. So exactly 3 different IPs trigger it.

Full explanation →

109

MCQhard

A company uses Microsoft Sentinel with Microsoft Defender for Cloud Apps. An incident is created when a user downloads 500 GB from SharePoint in one hour. The analyst wants to create a playbook that automatically suspends the user in Microsoft Entra ID when such activity is detected. Which connector and action should the analyst use in the playbook?

A.Microsoft Teams connector with 'Post message' action to notify admin.

B.Microsoft Entra ID connector with 'Update user' action to set accountEnabled to false.

C.Microsoft 365 Defender connector with 'Run advanced hunting' action.

D.Exchange Online connector with 'Set mailbox' action.

AnswerB

Directly disables the user account in Entra ID.

Why this answer

The Microsoft Entra ID connector provides the 'Update user' action, which can set the 'accountEnabled' property to false, effectively suspending the user in Microsoft Entra ID. This directly addresses the requirement to automatically disable a user account when a high-volume SharePoint download incident is detected in Microsoft Sentinel. The playbook can be triggered by the incident and use this action to perform the suspension without manual intervention.

Exam trap

The SC-200 exam often tests the distinction between notification actions (like Teams posts) and remediation actions (like disabling a user account), and the trap here is that candidates may choose a notification option (A) because it seems proactive, but the question explicitly requires automatic suspension, not just alerting.

How to eliminate wrong answers

Option A is wrong because the Microsoft Teams connector with 'Post message' action only sends a notification to an admin; it does not suspend the user or perform any account modification, so it fails to meet the requirement of automatically suspending the user. Option C is wrong because the Microsoft 365 Defender connector with 'Run advanced hunting' action is used to query threat data for investigation, not to modify user account status; it cannot suspend a user in Microsoft Entra ID. Option D is wrong because the Exchange Online connector with 'Set mailbox' action modifies mailbox settings (e.g., forwarding, quotas) but does not disable the user account in Microsoft Entra ID; suspending a user requires disabling the identity, not just the mailbox.

Full explanation →

110

MCQeasy

An organization has connected a Palo Alto Networks firewall to Microsoft Sentinel using the Common Event Format (CEF) connector via a Linux log forwarder. The analyst notices that some expected firewall logs are missing in Sentinel. Which troubleshooting step should be performed first to check if the logs are reaching the Sentinel workspace?

A.Run a KQL query in the Sentinel Logs workspace: CommonSecurityLog | where TimeGenerated > ago(1h) | take 10

B.Check the firewall configuration to ensure syslog forwarding is enabled and pointing to the correct Linux forwarder

C.Verify network connectivity between the firewall and the Linux forwarder on port 514 (or the configured port)

D.Restart the Log Analytics agent on the Linux forwarder

AnswerA

Querying CommonSecurityLog with a simple KQL filter for the last hour directly verifies whether Palo Alto CEF messages have been parsed and ingested into the Log Analytics workspace that backs Sentinel. Because CommonSecurityLog is the target schema for third-party syslog/CEF sources, seeing any rows proves the full pipeline (firewall, forwarder, agent, workspace) is functionally delivering data, making this the correct confirmatory test.

Why this answer

The first step in troubleshooting missing logs in Microsoft Sentinel is to verify whether the logs are actually reaching the workspace. Running a KQL query against the CommonSecurityLog table (which stores CEF data) with a recent time filter confirms if any CEF logs have been ingested. If the query returns results, the issue lies elsewhere (e.g., parsing or missing events); if it returns no results, the problem is upstream (connector, forwarder, or source).

This step isolates the problem to the Sentinel ingestion pipeline before investigating network or configuration issues.

Exam trap

The trap here is that candidates often jump to checking the source (firewall) or network connectivity first, but Microsoft Sentinel expects you to start by verifying data ingestion at the workspace level using KQL, as this immediately confirms whether the entire pipeline is working or broken.

How to eliminate wrong answers

Option B is wrong because checking the firewall’s syslog forwarding configuration is a downstream step that should only be taken after confirming logs are not reaching the workspace; it assumes the issue is at the source, but the first diagnostic step must be at the destination (Sentinel). Option C is wrong because verifying network connectivity between the firewall and the Linux forwarder on port 514 is also a downstream step; if logs are reaching the forwarder but not Sentinel, the network between forwarder and Sentinel (or the agent) is the real issue. Option D is wrong because restarting the Log Analytics agent is a reactive, brute-force action that does not provide diagnostic information; it may temporarily mask the problem but does not help identify whether logs are reaching the workspace.

Full explanation →

111

MCQeasy

A large organization manages multiple Azure subscriptions under a single management group. The security team wants to ensure that when new subscriptions are added to the management group, the Microsoft Defender for Cloud plans (e.g., Defender for Servers) are automatically enabled. What is the most efficient way to achieve this?

A.Assign the Azure Policy initiative 'Configure Azure Defender to be enabled on subscriptions' to the management group with appropriate policy parameters.

B.Enable all Microsoft Defender plans at the management group level in the Microsoft Defender for Cloud portal.

C.Manually enable the Defender plans on each new subscription as they are created.

D.Use an Azure Blueprint to assign the Defender plans to the subscription.

AnswerA

This built-in policy initiative uses DeployIfNotExists effects to enable Microsoft Defender for Cloud plans across all subscriptions within the management group's hierarchy. Because Azure Policy assignments are inherited and continuously evaluated, any subscription added later automatically receives the Defender plans without manual intervention. Assigning parameters lets you control which plans (e.g., SQL, Storage, Key Vault) are enabled, while the policy's remediation task ensures existing non-compliant subscriptions are brought into compliance.

Why this answer

Assigning the built-in Azure Policy initiative 'Configure Azure Defender to be enabled on subscriptions' to the management group ensures that any new subscription added under that management group automatically inherits the policy. This initiative uses DeployIfNotExists effect to enable the specified Defender plans (e.g., Defender for Servers) on subscriptions that do not already have them enabled, providing a fully automated, scalable solution without manual intervention.

Exam trap

The trap here is that candidates often confuse the 'Enable at management group level' portal setting (which only applies to existing subscriptions) with the automatic inheritance behavior of Azure Policy, leading them to choose Option B.

How to eliminate wrong answers

Option B is wrong because enabling Defender plans at the management group level in the Microsoft Defender for Cloud portal only applies to existing subscriptions under that management group; it does not automatically enable plans on newly added subscriptions. Option C is wrong because manually enabling Defender plans on each new subscription is inefficient, error-prone, and does not scale for a large organization with frequent subscription creation. Option D is wrong because Azure Blueprints are used to define and deploy a repeatable set of Azure resources and policies, but they require explicit assignment to each subscription and do not automatically propagate to new subscriptions added to the management group; Azure Policy is the native, more efficient mechanism for automatic inheritance.

Full explanation →

112

MCQmedium

A security administrator needs to ensure that only approved applications can run on a set of Windows Server virtual machines. The administrator has already enabled Microsoft Defender for Cloud's enhanced security features. Which Defender for Cloud feature should the administrator configure to define a list of allowed applications and get alerts when unapproved applications are executed?

A.Adaptive Application Controls

B.File Integrity Monitoring (FIM)

C.Just-in-Time VM Access (JIT)

D.Vulnerability Assessment

AnswerA

Correct: Adaptive Application Controls, part of Microsoft Defender for Cloud, leverages machine learning to establish a baseline of normal application usage on each VM. It then creates an allowlist of known-good executables based on file provenance, path, and publisher, and triggers security alerts when an application outside that baseline attempts to run. Administrators can optionally enforce a deny rule to block such executions.

Why this answer

Adaptive Application Controls (AAC) is the correct feature because it uses machine learning to establish a baseline of known-safe processes on your Windows Server VMs, then enforces an allowlist so that only those approved applications can run. When an unapproved application is executed, AAC generates a security alert in Microsoft Defender for Cloud, meeting the requirement to both define allowed applications and receive alerts on violations.

Exam trap

The trap here is that candidates confuse 'application control' with 'file integrity monitoring' because both deal with files, but FIM only alerts on changes to existing files, not on execution of new unapproved applications.

How to eliminate wrong answers

Option B (File Integrity Monitoring) is wrong because FIM monitors changes to critical files, registry keys, and software installations, but it does not enforce an application allowlist or alert on unapproved application execution; it focuses on integrity changes. Option C (Just-in-Time VM Access) is wrong because JIT controls network access to management ports (like RDP or SSH) by reducing exposure, not by controlling which applications can run on the VM. Option D (Vulnerability Assessment) is wrong because VA scans for known vulnerabilities and misconfigurations in the OS and applications, but it does not define or enforce an allowlist of approved applications.

Full explanation →

113

MCQhard

Your organization uses Microsoft Sentinel with multiple workspaces across different regions. You need to centrally manage all security incidents from a single pane of glass. The solution must allow analysts to investigate incidents across workspaces without switching contexts. What should you configure?

A.Deploy Microsoft Sentinel in a single region and use Azure Arc to connect other workspaces.

B.Create a union query across workspaces using the workspace() expression.

C.Use Azure Lighthouse to manage multiple workspaces and enable cross-workspace incident view in Microsoft Sentinel.

D.Configure a single workspace and use diagnostic settings to send all logs to it.

AnswerC

Azure Lighthouse allows managing multiple workspaces from a single view.

Why this answer

Azure Lighthouse enables cross-workspace incident management in Microsoft Sentinel by granting delegated access across multiple Azure tenants or regions. This allows analysts to view and investigate incidents from all connected workspaces in a single pane of glass without switching contexts, fulfilling the requirement for centralized incident management.

Exam trap

The trap here is that candidates often confuse cross-workspace querying (Option B) with centralized incident management, not realizing that the workspace() expression only enables log queries, not the aggregated incident view required for a single pane of glass.

How to eliminate wrong answers

Option A is wrong because Azure Arc extends Azure management to on-premises or multi-cloud resources, not to other Sentinel workspaces; it does not provide a unified incident view across multiple Sentinel workspaces. Option B is wrong because a union query using the workspace() expression is used for cross-workspace log queries in Log Analytics, not for centrally managing security incidents in the Sentinel incident interface; it requires manual querying and does not aggregate incidents into a single pane of glass. Option D is wrong because configuring a single workspace and sending all logs to it via diagnostic settings would require redesigning the existing multi-workspace architecture and does not address the need to centrally manage incidents from already deployed workspaces across different regions.

Full explanation →

114

Multi-Selecteasy

Which TWO Microsoft 365 Defender portals provide automated investigation and response capabilities? (Choose two.)

Select 2 answers

A.Microsoft Purview compliance portal

B.Microsoft Sentinel (portal.azure.com)

C.Microsoft Intune admin center

D.Microsoft Defender for Endpoint (security.microsoft.com)

E.Microsoft 365 Defender (security.microsoft.com)

AnswersD, E

Defender for Endpoint has automated investigation and response for endpoint threats.

Why this answer

Microsoft Defender for Endpoint (D) and Microsoft 365 Defender (E) both provide automated investigation and response (AIR) capabilities. Defender for Endpoint uses AIR to automatically investigate alerts on endpoints and take remediation actions, while Microsoft 365 Defender orchestrates AIR across email, identity, endpoints, and cloud apps. These portals are accessed via security.microsoft.com and offer built-in playbooks for automated response.

Exam trap

The trap here is that candidates may confuse Microsoft Sentinel's SOAR capabilities with the built-in AIR features of Microsoft 365 Defender portals, or mistakenly think the Purview compliance portal includes automated incident response.

Full explanation →

115

MCQhard

A SOC analyst is configuring a Microsoft Sentinel scheduled analytics rule to detect rare operations on Azure Key Vaults. The rule uses the AzureActivity table. The analyst wants to use a machine learning algorithm to identify anomalies based on historical activity patterns. Which analytics rule type should the analyst choose?

A.Scheduled

B.Microsoft Security Incident (for using existing alert triggers)

C.Anomaly detection

D.NRT (Near-Real-Time)

AnswerC

Anomaly detection rules in Microsoft Sentinel apply trained machine-learning models to establish a baseline of normal behavior for entities, users, or hosts and then flag events that deviate significantly from that baseline. These rules use built-in anomaly templates (such as unusual sign-in or anomalous privilege use) or custom ML models, making them specifically designed to detect rare, unusual operations that would never meet a static threshold. This matches the requirement for detecting rare operations without writing a fixed query.

Why this answer

The Anomaly Detection rule type in Microsoft Sentinel is specifically designed to use machine learning algorithms to identify unusual patterns in historical data. For detecting rare operations on Azure Key Vaults based on historical activity patterns in the AzureActivity table, this rule type automatically applies time series analysis and ML models to baseline normal behavior and flag deviations, making it the correct choice.

Exam trap

The trap here is that candidates often confuse Scheduled rules with Anomaly Detection rules because both can run on a schedule, but only Anomaly Detection rules incorporate built-in machine learning algorithms for dynamic baseline analysis.

How to eliminate wrong answers

Option A is wrong because a Scheduled analytics rule runs a query at defined intervals but does not inherently use machine learning algorithms; it relies on static threshold-based detection. Option B is wrong because Microsoft Security Incident rules are used to import alerts from other Microsoft security products (like Microsoft Defender for Cloud) and do not perform ML-based anomaly detection on AzureActivity data. Option D is wrong because NRT (Near-Real-Time) rules are designed for low-latency detection using simple queries and do not support machine learning-based anomaly detection.

Full explanation →

116

MCQmedium

In Microsoft 365 Defender, a security analyst reviews an automated investigation that found a potentially unwanted application on multiple devices. The analyst wants to manually approve the suggested remediation action of uninstalling the application. Where should the analyst go?

A.The Action center

B.The Incidents page

C.The Alerts queue

D.The Device inventory

AnswerA

The Action center is the centralized console in Microsoft 365 Defender where all pending and completed remediation actions — such as file quarantine, device isolation, and email deletion — are listed, regardless of their originating automated investigation or manual response. Analysts must use this hub to review and either approve or reject each pending action before it is executed, and the center also preserves a full history for audit and investigation purposes. Because it is specifically designed to aggregate these actionable tasks from across Microsoft Defender for Endpoint, Office 365, and Identity, it is the only place that meets the analyst's need to review remediation actions.

Why this answer

The Action center in Microsoft 365 Defender is the centralized location where security analysts can view and manually approve or reject remediation actions that were suggested by automated investigations, such as uninstalling a potentially unwanted application. This is the correct place because the Action center consolidates all pending and completed actions across devices, allowing the analyst to take direct manual intervention on the recommended remediation.

Exam trap

The trap here is that candidates often confuse the Incidents page or Alerts queue as the place to approve remediation actions, not realizing that the Action center is the sole interface for managing pending remediation actions from automated investigations.

How to eliminate wrong answers

Option B is wrong because the Incidents page is used to view and manage the full scope of an incident, including alerts, devices, and evidence, but it does not provide the interface to manually approve or reject specific remediation actions like uninstalling an application. Option C is wrong because the Alerts queue lists individual security alerts, but it does not show the suggested remediation actions from automated investigations; those actions are only visible and actionable in the Action center. Option D is wrong because the Device inventory shows the list of devices and their details, but it does not contain the pending remediation actions or the ability to approve them; it is purely an inventory view.

Full explanation →

117

MCQmedium

A security analyst is investigating a suspicious email that was reported by a user. The email contains an attachment with a known malicious macro. The analyst wants to find all instances of this same email being delivered to other users in the organization. Which Advanced Hunting table should the analyst query to find the delivery events?

A.EmailAttachmentInfo

B.EmailEvents

C.EmailUrlInfo

D.DeviceFileEvents

AnswerB

Correct. EmailEvents contains the delivery records, including the recipient addresses and delivery status. It can be filtered or joined with attachment data to find all recipients.

Why this answer

The EmailEvents table in Microsoft Defender XDR Advanced Hunting contains records of email delivery events, including sender, recipient, subject, and delivery status. Since the analyst needs to find all instances where the same email (with the malicious macro attachment) was delivered to other users, querying EmailEvents with the email's unique identifier (e.g., NetworkMessageId) will return all delivery events across the organization.

Exam trap

The trap here is that candidates confuse EmailAttachmentInfo (which contains attachment hashes) with EmailEvents, assuming attachment data alone can identify all recipients, but only EmailEvents holds the delivery event records needed to find every user who received the email.

How to eliminate wrong answers

Option A is wrong because EmailAttachmentInfo stores metadata about attachments (e.g., filename, SHA256 hash) but does not include delivery event details like recipient or delivery status; it is used to correlate attachments with emails, not to find delivery instances. Option C is wrong because EmailUrlInfo contains information about URLs in the email body or attachments, not delivery events; it is used for phishing URL investigations, not for locating all recipients of a specific email. Option D is wrong because DeviceFileEvents tracks file creation, modification, and deletion events on endpoints, not email delivery events; it is irrelevant for finding email recipients.

Full explanation →

118

MCQmedium

A security analyst in Microsoft Sentinel is creating a scheduled analytics rule to detect multiple failed logon attempts from the same source IP address. The rule should generate an incident only when the count of failed logons exceeds 10 within a 5-minute window. Which configuration setting is essential to limit the incident generation to this threshold?

A.Event grouping set to 'Group all events into a single alert'

B.Alert threshold set to a value of 10

C.Query scheduling set to run every 5 minutes

D.Entity mapping for source IP address

AnswerB

Alert threshold set to a value of 10 specifies the minimum number of records that the rule's query must return before an alert is generated. Runs that produce fewer than 10 results are completely ignored, which filters out low-volume, benign matches and ensures an incident is created only when at least 10 events match the rule's logic. This is the correct mechanism for requiring a statistically significant number of results before escalating to an incident.

Why this answer

The alert threshold setting in a Microsoft Sentinel scheduled analytics rule directly controls the minimum number of query results required to generate an incident. By setting the threshold to 10, the rule will only fire when the query returns more than 10 failed logon events within the 5-minute window, matching the requirement exactly.

Exam trap

The trap here is confusing the alert threshold with query scheduling or event grouping, leading candidates to think that setting the run interval to 5 minutes alone ensures the threshold is met, when in fact the threshold is a separate mandatory configuration.

How to eliminate wrong answers

Option A is wrong because 'Group all events into a single alert' controls how matching events are bundled into one alert, not the count threshold for triggering an incident. Option C is wrong because query scheduling set to run every 5 minutes defines the evaluation frequency, not the threshold for the number of failed logons. Option D is wrong because entity mapping for source IP address is used to enrich alerts with entity information for investigation, not to limit incident generation based on event count.

Full explanation →

119

MCQmedium

A SOC analyst is configuring an analytics rule in Microsoft Sentinel. The rule should run every hour and check for sign-ins from users who have been inactive for more than 30 days. The analyst uses the SigninLogs and IdentityInfo tables. Which KQL query pattern should be used to identify these users?

A.union IdentityInfo, SigninLogs | where TimeGenerated > ago(30d) | summarize by UserPrincipalName

B.IdentityInfo | join kind=leftanti (SigninLogs | where TimeGenerated > ago(30d)) on UserPrincipalName

C.SigninLogs | where TimeGenerated > ago(30d) | summarize by UserPrincipalName | join kind=rightanti IdentityInfo on UserPrincipalName

D.SigninLogs | where TimeGenerated < ago(30d) | summarize by UserPrincipalName

AnswerB

Correct. The left anti join returns all rows from IdentityInfo that do not have a matching UserPrincipalName in the recent SigninLogs, effectively finding inactive users.

Why this answer

It uses a `leftanti` join to return all rows from the `IdentityInfo` table that have no matching `UserPrincipalName` in the `SigninLogs` table for the last 30 days. This directly identifies users who are in the identity inventory but have not signed in within the past 30 days, which is the exact requirement for detecting inactive users.

Exam trap

The trap here is that candidates often confuse `leftanti` with `rightanti` or `leftouter` joins, mistakenly thinking that summarizing sign-ins first and then joining will correctly identify inactive users, when in fact the direction of the anti-join determines which table's unmatched rows are returned.

How to eliminate wrong answers

Option A is wrong because it uses `union` to combine the two tables and then filters for sign-ins within 30 days, which would include all users who have signed in recently and miss the inactive users entirely. Option C is wrong because it uses a `rightanti` join, which returns rows from the right table (`IdentityInfo`) that have no match in the left table (`SigninLogs`), but the query first summarizes sign-ins from the last 30 days, so the join would incorrectly return users who have signed in recently as inactive. Option D is wrong because it filters `SigninLogs` for sign-ins older than 30 days (`TimeGenerated < ago(30d)`), which would return historical sign-ins rather than identifying users with no recent sign-ins at all.

Full explanation →

120

MCQmedium

A SOC analyst wants to automate a response in Microsoft Sentinel: whenever an incident is created that contains a compromised user entity (e.g., a user whose credentials were used in a breach), a playbook should run to disable that user in Microsoft Entra ID. Which condition should be configured in the automation rule to trigger this playbook?

A.Set the trigger to 'When incident is created' with no additional condition.

B.Set the condition to 'When incident is created with entity type IP'.

C.Set the condition to 'When incident is created with entity type Account'.

D.Set the condition to 'When incident is updated with entity type Host'.

AnswerC

Selecting 'When incident is created with entity type Account' is the correct and precise condition because the Account entity type in Microsoft Sentinel represents user accounts, including the attributes needed to disable a user (e.g., user principal name, NT domain, or account SID). This condition ensures the playbook runs only on new incidents that actually contain a compromised user entity, directly aligning with the SOC analyst's goal of disabling that user. It avoids the extra latency and noise of an unscoped trigger while guaranteeing the playbook receives the necessary entity data to perform the account triage.

Why this answer

The automation rule must trigger when an incident is created with an entity type of 'Account' to match the compromised user entity. In Microsoft Sentinel, a user whose credentials were used in a breach is represented as an 'Account' entity, not an 'IP' or 'Host'. The playbook to disable the user in Microsoft Entra ID requires this entity type to pass the user principal name (UPN) or object ID to the action.

Exam trap

The trap here is that candidates often confuse 'Account' with 'User' or assume 'IP' is sufficient for user compromise, but Microsoft Sentinel uses the specific entity type 'Account' for user identities, and the automation rule condition must match exactly that type to trigger the playbook correctly.

How to eliminate wrong answers

Option A is wrong because setting the trigger to 'When incident is created' with no additional condition would run the playbook on every incident, regardless of whether it contains a compromised user entity, leading to unnecessary or incorrect executions. Option B is wrong because 'entity type IP' represents an IP address, not a user account; disabling an IP address in Microsoft Entra ID is not a valid action for user compromise. Option D is wrong because 'entity type Host' represents a device or computer, not a user account, and the condition 'When incident is updated' would not capture the initial creation of the incident containing the compromised user.

Full explanation →

121

MCQeasy

Your organization is implementing Microsoft Sentinel. You need to design a solution to automatically disable a user account in Microsoft Entra ID when a high-severity incident is triggered in Microsoft Sentinel related to that user. Which component should you use?

A.A playbook that uses the Microsoft Graph API to disable the user.

B.An analytics rule that includes a query to disable the user.

C.An automation rule that runs a PowerShell script on a hybrid worker.

D.A workbook that triggers a webhook to disable the user.

AnswerA

Playbooks can automate response actions like disabling a user.

Why this answer

A playbook is the correct component because it is an automated workflow that can be triggered by a Microsoft Sentinel incident. By using the Microsoft Graph API within the playbook, you can programmatically disable a user account in Microsoft Entra ID, which is the required action for a high-severity incident. This aligns with the need for an automated response that integrates Sentinel with identity management.

Exam trap

The trap here is that candidates may confuse automation rules with playbooks, thinking that automation rules can directly execute scripts or API calls, when in fact automation rules only trigger playbooks or run actions like changing incident status, not performing external remediation.

How to eliminate wrong answers

Option B is wrong because an analytics rule is designed to generate alerts based on query results, not to execute remediation actions like disabling a user; it lacks the capability to perform API calls or modify Entra ID objects. Option C is wrong because an automation rule in Sentinel can trigger a playbook or run a script on a hybrid worker, but running a PowerShell script directly on a hybrid worker does not natively integrate with Microsoft Graph API to disable a user without additional custom logic; the standard pattern is to use a playbook for such actions. Option D is wrong because a workbook is a visualization tool for data analysis and reporting; it cannot trigger webhooks or execute actions to disable user accounts.

Full explanation →

122

MCQeasy

Your organization uses Microsoft Sentinel. An incident is created for a possible data exfiltration via an unapproved external IP address. Which type of Microsoft Sentinel automation should you use to automatically block the IP address in the firewall?

A.Data connector.

B.Analytics rule.

C.Watchlist.

D.Playbook.

AnswerD

Playbooks automate response actions; they can be triggered from automation rules to block IPs.

Why this answer

Playbooks in Microsoft Sentinel are automated workflows based on Azure Logic Apps that can perform response actions, such as blocking an IP address in a firewall. When an incident indicates data exfiltration via an unapproved external IP, a playbook can be triggered automatically or manually to execute the block action via integration with firewall APIs or management tools.

Exam trap

The SC-200 exam often tests the distinction between detection (analytics rules) and response (playbooks), so candidates may confuse an analytics rule's ability to generate alerts with the capability to perform automated remediation actions.

How to eliminate wrong answers

Option A is wrong because a data connector is used to ingest logs and events from various sources into Sentinel, not to perform automated response actions like blocking an IP. Option B is wrong because an analytics rule generates alerts or incidents based on query logic; it does not execute remediation actions such as firewall changes. Option C is wrong because a watchlist is a collection of data (e.g., known malicious IPs) for correlation in queries, but it cannot directly trigger a block action in a firewall.

Full explanation →

123

MCQhard

A security analyst is investigating a sophisticated attack that involved multiple devices. The analyst needs to create a custom detection rule in Microsoft 365 Defender that triggers when a process with a specific SHA256 hash is executed on any device AFTER an attacker-controlled file is created on another device. Which approach should the analyst use to build this detection?

A.Create a custom detection rule using an advanced hunting query that joins DeviceFileEvents and DeviceProcessEvents, and schedule it in Microsoft 365 Defender.

B.Use the Microsoft 365 Defender incident creation rule to generate an incident when the behavior is observed.

C.Use Microsoft Sentinel analytics rules with a data connector to Microsoft 365 Defender.

D.Use Microsoft Defender for Cloud's workload protection alerts.

AnswerA

A custom detection rule in Microsoft 365 Defender lets you run a KQL advanced hunting query on a schedule, joining DeviceFileEvents and DeviceProcessEvents to correlate file creation and process execution events across devices. This enables alerting on multi-stage attack sequences that individual alert rules might miss, with full flexibility to define thresholds, time windows, and affected device groups. Because the rule runs natively in the same environment that ingests the endpoint telemetry, it provides direct, low-latency detection without extra data transfer or licensing.

Why this answer

The requirement is to correlate two distinct events (file creation on one device and process execution on another) across time and devices. An advanced hunting query in Microsoft 365 Defender can join DeviceFileEvents and DeviceProcessEvents tables using a common indicator (e.g., attacker-controlled file hash) and schedule the query as a custom detection rule. This is the only native Microsoft 365 Defender approach that supports multi-device, multi-event correlation with scheduled evaluation.

Exam trap

The trap here is that candidates often confuse incident creation rules (which only react to existing alerts) with custom detection rules (which can query raw telemetry), leading them to select Option B despite its inability to perform cross-table joins.

How to eliminate wrong answers

Option B is wrong because incident creation rules in Microsoft 365 Defender only trigger on existing alerts or incidents, not on raw telemetry; they cannot perform multi-table joins or detect custom behavioral sequences. Option C is wrong because while Microsoft Sentinel can ingest Microsoft 365 Defender data and create analytics rules, the question explicitly asks for a detection built within Microsoft 365 Defender, not a separate SIEM. Option D is wrong because Microsoft Defender for Cloud's workload protection alerts focus on cloud infrastructure and resource-level threats, not on device-level process and file events across endpoints.

Full explanation →

124

MCQeasy

A security analyst is investigating a potential phishing campaign and has identified a malicious attachment with a known SHA256 hash. The analyst needs to find all email messages that were delivered to users and contained this exact attachment. Which advanced hunting table should the analyst query to obtain the network message IDs of the relevant emails?

A.EmailEvents

B.EmailAttachmentInfo

C.EmailUrlInfo

D.EmailPostDeliveryEvents

AnswerB

EmailAttachmentInfo includes the SHA256 hash of each attachment and the NetworkMessageId of the email.

Why this answer

The EmailAttachmentInfo table in Microsoft 365 Advanced Hunting contains records of every attachment in email messages, including the SHA256 hash. By querying this table with the known hash, the analyst can retrieve the NetworkMessageId values for all emails that contained that specific malicious attachment, enabling further investigation into delivery and impact.

Exam trap

The trap here is that candidates often confuse EmailEvents (which has delivery status) with EmailAttachmentInfo (which has attachment hashes), failing to recognize that only the latter contains the SHA256 hash needed to match a known malicious file.

How to eliminate wrong answers

Option A is wrong because EmailEvents contains metadata about email delivery events (e.g., delivery status, sender, recipient) but does not include attachment-level details like SHA256 hashes. Option C is wrong because EmailUrlInfo stores information about URLs present in email bodies or attachments, not attachment file hashes. Option D is wrong because EmailPostDeliveryEvents records actions taken on emails after delivery (e.g., user clicks, ZAP actions) and does not contain attachment hash data.

Full explanation →

125

MCQmedium

A SOC analyst in Microsoft Sentinel is creating a scheduled analytics rule to detect sign-ins from IP addresses known to be associated with a threat actor. The list of threat actor IPs is maintained in a custom Microsoft Sentinel watchlist and is updated daily. The analyst wants the rule to query the SigninLogs table and compare the IP address against this list. What is the most efficient way to reference the list in the KQL query?

A.Use the externaldata operator to read from a blob storage URL.

B.Use the let statement to define a static list inline.

C.Use the _GetWatchlist() function to retrieve the watchlist.

D.Use the datatable operator to define the list directly in the query.

AnswerC

_GetWatchlist('name') is the purpose-built Kusto function for retrieving Microsoft Sentinel watchlist content inside an analytics rule. The watchlist data is cached by Sentinel, and updates made through the portal, API, or PowerShell are automatically reflected without changing the rule query. This centralization enables SOC teams to maintain and version reference data independently from detection logic, while still supporting efficient joins and lookups in scheduled queries, making it the recommended pattern.

Why this answer

The `_GetWatchlist()` function is the built-in, optimized way to reference a Microsoft Sentinel watchlist within a KQL query. It retrieves the watchlist data directly from the Sentinel workspace, ensuring the query always uses the latest daily-updated list without manual maintenance or external dependencies. This approach is both efficient and aligns with Sentinel's intended design for dynamic threat intelligence.

Exam trap

The trap here is that candidates may confuse `_GetWatchlist()` with other data retrieval methods like `externaldata` or `datatable`, not realizing that watchlists are a first-class Sentinel feature designed for exactly this use case—dynamic, centrally managed threat intelligence that updates automatically without query modification.

How to eliminate wrong answers

Option A is wrong because the `externaldata` operator reads data from an external blob storage URL, which introduces latency, requires managing access keys, and bypasses Sentinel's native watchlist caching and update mechanisms. Option B is wrong because a `let` statement defines a static list inline, which would require manual editing of the query every time the threat actor IP list changes, defeating the purpose of a daily-updated watchlist. Option D is wrong because the `datatable` operator defines a hardcoded list directly in the query, similar to a static `let` statement, and cannot be dynamically updated without modifying the analytics rule itself.

Full explanation →

126

MCQeasy

A company uses Microsoft Defender for Cloud to protect Azure virtual machines. The security team wants to identify which VMs have missing system updates such as critical security patches. Which Defender for Cloud feature should they use?

A.Adaptive application controls

B.Just-in-time VM access

C.Vulnerability assessment

D.File integrity monitoring

AnswerC

Vulnerability assessment in Microsoft Defender for Cloud uses an integrated scanner, like Microsoft Defender Vulnerability Management or Qualys, to continuously inspect VMs for known CVEs, missing OS patches, and security misconfigurations. This scanner evaluates the guest operating system state and correlates findings against vulnerability intelligence to produce actionable recommendations such as 'Machines should have vulnerability findings resolved.' Therefore, it is the only listed option that directly identifies missing security updates and is the correct control for this scenario.

Why this answer

Vulnerability assessment in Microsoft Defender for Cloud scans Azure VMs for missing system updates, including critical security patches, by integrating with built-in or partner vulnerability scanners (e.g., Qualys). This feature provides a continuous assessment of OS and application vulnerabilities, directly addressing the need to identify VMs with missing patches.

Exam trap

The trap here is confusing vulnerability assessment (which identifies missing patches and misconfigurations) with adaptive application controls (which restricts application execution) or file integrity monitoring (which detects file changes), leading candidates to pick a feature that addresses a different security control objective.

How to eliminate wrong answers

Option A is wrong because Adaptive application controls use machine learning to define allowlists for applications running on VMs, focusing on controlling which executables can run, not on identifying missing system updates. Option B is wrong because Just-in-time VM access reduces the attack surface by managing inbound network access to VMs on specific ports, but it does not scan for missing patches or vulnerabilities. Option D is wrong because File integrity monitoring tracks changes to critical system files and registry keys, alerting on unauthorized modifications, but it does not assess the state of system updates or patch levels.

Full explanation →

127

Multi-Selectmedium

Which THREE actions can be performed by automation rules in Microsoft Sentinel?

Select 3 answers

A.Modify a data connector to ingest more logs

B.Create a new analytics rule

C.Assign an incident to a specific owner

D.Run a playbook on an incident

E.Add a tag to an incident

AnswersC, D, E

Automation rules have an 'Assign owner' action.

Why this answer

Automation rules in Microsoft Sentinel can automatically assign incidents to specific owners based on conditions such as severity, entity type, or custom criteria. This action helps streamline incident response by ensuring the right personnel are notified and responsible for handling the incident without manual intervention.

Exam trap

The trap here is that candidates may confuse automation rules with analytics rules or data connectors, assuming automation rules can modify data sources or create detection logic, when in fact automation rules are limited to post-ingestion incident management actions.

Full explanation →

128

MCQhard

A SOC analyst is creating a scheduled analytics rule in Microsoft Sentinel to detect sign-ins from IP addresses that are not in the organization's known allow list. The allow list is maintained in a custom watchlist named 'AllowedIPs'. The analyst wants the KQL query to efficiently filter out allowed IPs. Which KQL approach should the analyst use?

A.Use the 'lookup' operator to map IPs against the watchlist.

B.Use a 'let' statement to define a static list of allowed IPs.

C.Use the _GetWatchlist('AllowedIPs') function and filter with the '!in' operator.

D.Use the 'evaluate' operator with a python script.

AnswerC

The _GetWatchlist function retrieves the watchlist content, and the '!in' operator efficiently excludes matching IPs from the results.

Why this answer

The _GetWatchlist('AllowedIPs') function retrieves the watchlist content at query runtime, and combining it with the '!in' operator efficiently filters out sign-ins from IPs present in the watchlist. This approach is dynamic, meaning updates to the watchlist are automatically reflected without modifying the query, and it avoids hardcoding IPs or using inefficient row-by-row lookups.

Exam trap

The trap here is that candidates often confuse the 'lookup' operator with filtering, or assume a static 'let' statement is acceptable, failing to recognize that watchlists are designed for dynamic, centrally managed data that must be referenced at query runtime.

How to eliminate wrong answers

Option A is wrong because the 'lookup' operator is designed to extend a table with columns from another table based on matching keys, not to filter rows; using it here would be semantically incorrect and less efficient than a simple '!in' filter. Option B is wrong because a 'let' statement with a static list would require manual updates whenever the allow list changes, defeating the purpose of a dynamic watchlist and introducing maintenance overhead. Option D is wrong because the 'evaluate' operator with a python script is overkill for a simple IP filtering task, introduces unnecessary complexity and performance overhead, and is not the recommended pattern for watchlist-based filtering in Sentinel.

Full explanation →

129

MCQmedium

A SOC analyst is investigating a potential brute-force attack on an Azure VM. The analyst has ingested Windows Security Events into Microsoft Sentinel. Which KQL query would count the number of failed logon attempts (EventID 4625) per user account in the last hour?

A.SecurityEvent | where EventID == 4625 | summarize Count = count() by Account | where TimeGenerated > ago(1h)

B.SecurityEvent | where EventID == 4625 and TimeGenerated > ago(1h) | summarize Count = count() by Account

C.SigninLogs | where ResultType != 0 | summarize Count = count() by UserPrincipalName | where TimeGenerated > ago(1h)

D.SecurityEvent | where EventID == 4625 | make-series Count = count() default=0 on TimeGenerated from ago(1h) to now() step 1h by Account

AnswerB

This query correctly applies the time filter alongside the EventID filter in the where clause, so only failed logon events (Event 4625) from the last hour are passed into the summarize operator. The summarize then groups these pre-filtered rows by Account, yielding the failure count for each account within the desired time window. This is a textbook example of proper KQL query ordering: filter first, aggregate second, and optionally post-filter aggregated results only if needed.

Why this answer

It filters for EventID 4625 (failed logon) and restricts the time range to the last hour before summarizing the count per Account. This ensures only relevant events are counted, and the aggregation is performed on the correct field (Account) from the SecurityEvent table, which contains Windows Security Events ingested into Sentinel.

Exam trap

The trap here is that candidates often apply the time filter after the summarize operator (as in Option A), which incorrectly counts all historical data before filtering, or they confuse the SecurityEvent table with SigninLogs (Option C), which is for Azure AD sign-ins and not Windows Security Events on a VM.

How to eliminate wrong answers

Option A is wrong because the time filter (where TimeGenerated > ago(1h)) is applied after the summarize operator, meaning the count includes all historical failed logons and only then filters the results, which does not limit the events to the last hour. Option C is wrong because it uses the SigninLogs table, which contains Azure AD sign-in logs, not Windows Security Events; EventID 4625 is specific to Windows Security Events, and the query also incorrectly filters by ResultType != 0 (which indicates failure in Azure AD sign-ins) but does not use the correct field (Account) for user accounts. Option D is wrong because it uses make-series to create a time series, which is overkill for a simple count and does not produce a straightforward count per user account; it also applies the time filter only in the make-series range, not as a filter on the events themselves, potentially including older data.

Full explanation →

130

MCQhard

Your organization uses Microsoft Sentinel with a workspace in the East US region. You have a playbook that runs an automation rule to create a support ticket in ServiceNow. The playbook fails intermittently with a timeout error. You have verified that the playbook's managed identity has the correct permissions. What should you check next?

A.Ensure the playbook is assigned to an Azure Policy that allows outbound connections.

B.Check if the ServiceNow API has rate limits that are being exceeded.

C.Verify that the logic app's network connectivity allows outbound traffic to the ServiceNow endpoint, including any regional restrictions.

D.Verify that the logic app's workflow is configured to use asynchronous operations.

AnswerC

Intermittent timeouts often indicate network issues like firewall rules or regional routing.

Why this answer

The playbook is a Logic App, and intermittent timeout errors when calling an external API (ServiceNow) often indicate network connectivity issues. Since the managed identity permissions are correct, the next logical step is to verify that the Logic App's outbound traffic is allowed to the ServiceNow endpoint, including any regional restrictions that might block or delay traffic from the East US region. This directly addresses the root cause of the timeout.

Exam trap

The trap here is that candidates confuse authentication/authorization (managed identity) with network connectivity, assuming that correct permissions guarantee successful API calls, when in fact network restrictions or regional IP blocking can cause intermittent timeouts even with valid credentials.

How to eliminate wrong answers

Option A is wrong because Azure Policy does not manage outbound connections for Logic Apps; it enforces compliance rules on Azure resources, not network traffic. Option B is wrong because rate limits typically cause HTTP 429 responses, not timeout errors, and the question states the error is a timeout, not a throttling response. Option D is wrong because asynchronous operations affect how the Logic App handles long-running tasks internally, not the network connectivity to an external endpoint, and the timeout is on the outbound HTTP call, not the workflow execution.

Full explanation →

131

MCQeasy

A company has enabled Microsoft Defender for Cloud on its Azure subscription. The security team wants to ensure that all existing virtual machines have a vulnerability assessment solution installed. Which Defender for Cloud feature can automatically deploy a vulnerability assessment agent to supported VMs?

A.Vulnerability assessment recommendations

B.Defender for Servers plan

C.Security policies

D.Workload protections

AnswerA

In Microsoft Defender for Cloud, vulnerability assessment recommendations (such as 'Machines should have a vulnerability assessment solution' or 'A vulnerability assessment solution should be enabled on your virtual machines') are the actionable items that include a 'Fix' (remediation) option. When you trigger remediation on one of these recommendations, Defender for Cloud automatically deploys the integrated vulnerability assessment agent—either Qualys or Microsoft Defender Vulnerability Management—onto the target VMs. This makes the recommendations the specific mechanism for agent deployment, not the plan itself.

Why this answer

The Vulnerability Assessment (VA) recommendations in Microsoft Defender for Cloud can automatically deploy a vulnerability assessment agent (such as the Qualys or Microsoft Defender Vulnerability Management agent) to supported Azure VMs. When a VM is found to be missing a VA solution, Defender for Cloud can enable the 'Auto-provision' setting for the VA recommendation, which triggers the agent installation without manual intervention. This directly meets the requirement to ensure all existing VMs have a vulnerability assessment solution installed.

Exam trap

The trap here is that candidates often confuse the 'Defender for Servers plan' (which enables the feature set) with the actual automated deployment mechanism, assuming the plan itself installs agents, when in fact the deployment is triggered by enabling the 'Auto-provision' setting on the specific vulnerability assessment recommendation.

How to eliminate wrong answers

Option B is wrong because the Defender for Servers plan enables advanced security capabilities (e.g., file integrity monitoring, just-in-time VM access, and adaptive application controls) but does not itself automatically deploy a vulnerability assessment agent; it only makes the VA recommendations available. Option C is wrong because security policies define the compliance rules and initiatives (e.g., Azure Policy) that govern resource configurations, but they do not directly deploy agents; they can enforce the VA recommendation but the deployment action is handled by the recommendation's auto-provision feature. Option D is wrong because workload protections refer to the set of threat detection alerts and security signals for workloads (e.g., SQL, storage, containers), not the automated deployment of vulnerability assessment agents to VMs.

Full explanation →

132

MCQhard

A security analyst is configuring a playbook in Microsoft Sentinel to run automatically when a new incident of severity 'High' is created. The playbook should only run for incidents that are not already assigned to an analyst. How can the analyst configure this automation?

A.Create an automation rule with a condition on 'Owner' field equals 'Unassigned'

B.Use a playbook trigger 'When a Microsoft Sentinel incident is created' and add a condition in the playbook

C.Configure a watchlist to filter incidents

D.Use a Logic Apps trigger for all incidents and check owner within the playbook

AnswerA

Automation rules in Microsoft Sentinel are the recommended way to conditionally invoke playbooks based on incident properties at creation or update. Setting a condition on the Owner field equals 'Unassigned' ensures the playbook runs only for incidents that are both unassigned and (with an additional severity condition) High severity, avoiding unnecessary executions. This pre-filtering at the platform level reduces resource consumption and is more efficient than inside the playbook.

Why this answer

Microsoft Sentinel automation rules can evaluate incident properties at creation time, including the 'Owner' field. By setting a condition that 'Owner' equals 'Unassigned', the rule triggers the playbook only for high-severity incidents that have not yet been assigned to an analyst, meeting the requirement without requiring custom logic inside the playbook.

Exam trap

The trap here is that candidates often think they must embed filtering logic inside the playbook (Option B or D), overlooking that automation rules provide a native, efficient pre-filtering mechanism that avoids unnecessary playbook executions.

How to eliminate wrong answers

Option B is wrong because using a playbook trigger 'When a Microsoft Sentinel incident is created' and adding a condition inside the playbook would cause the playbook to run for every new incident, even those already assigned, wasting resources and potentially causing unintended actions before the condition is evaluated. Option C is wrong because watchlists are used for correlation, enrichment, or filtering of data during queries and analytics rules, not for controlling automation rule triggers based on incident ownership. Option D is wrong because using a Logic Apps trigger for all incidents and checking the owner within the playbook is inefficient and redundant; automation rules are the correct and intended mechanism to filter incidents before invoking a playbook, and this approach would still invoke the playbook for every incident, consuming unnecessary compute and API calls.

Full explanation →

133

MCQmedium

A cloud security team uses Microsoft Defender for Cloud with Defender for Servers enabled. They want to ensure that all Azure virtual machines have automatic provisioning of the Log Analytics agent (Azure Monitor Agent) turned on. Where should this configuration be set to cover existing and future VMs?

A.In Microsoft Defender for Cloud > Environment settings > Select subscription > Settings & monitoring > Log Analytics agent for Azure VMs > Set to 'On'

B.In Azure Policy > Assign a policy that deploys the Log Analytics agent to VMs

C.In Microsoft Defender for Cloud > Security policy > Data collection

D.In Azure virtual machine blade > Auto-provisioning

AnswerA

This is the correct path because Microsoft Defender for Cloud's integrated automatic provisioning is managed under Environment settings for the subscription, then Settings & monitoring, where the Log Analytics agent for Azure VMs toggle is enabled. Turning this on ensures the agent is deployed to every existing and future Azure VM in that subscription without individual manual action. This setting is purpose-built for Defender for Cloud's security data collection and is the authoritative way to satisfy the requirement.

Why this answer

The 'Settings & monitoring' pane under Environment settings in Microsoft Defender for Cloud is the centralized location to enable automatic provisioning of the Log Analytics agent (Azure Monitor Agent) at the subscription level. This setting ensures that both existing Azure VMs and any future VMs are automatically provisioned with the agent, without requiring individual VM configuration or manual policy assignment.

Exam trap

The trap here is that candidates often confuse the deprecated 'Data collection' option under Security policy (Option C) with the current 'Settings & monitoring' pane, or they assume that Azure Policy (Option B) is the only way to enforce agent deployment, missing the built-in auto-provisioning toggle in Defender for Cloud.

How to eliminate wrong answers

Option B is wrong because Azure Policy can deploy the Log Analytics agent, but it is not the native Defender for Cloud auto-provisioning mechanism; using a custom policy requires additional management and does not integrate with Defender for Cloud's monitoring settings. Option C is wrong because the 'Security policy > Data collection' option in Defender for Cloud is deprecated and no longer controls auto-provisioning for the Log Analytics agent; it was used for the legacy Microsoft Monitoring Agent, not the Azure Monitor Agent. Option D is wrong because the Azure virtual machine blade's 'Auto-provisioning' setting does not exist; auto-provisioning is configured at the subscription level in Defender for Cloud, not per VM.

Full explanation →

134

MCQmedium

Your threat hunting hypothesis is that a user's credentials were used to sign in from two geographically distant locations within a short time. In Microsoft Defender for Cloud Apps, which log type would you query in Microsoft Sentinel to detect impossible travel?

A.SigninLogs

B.AuditLogs

C.CommonSecurityLog

D.OfficeActivity

AnswerA

SigninLogs record user sign-in events with location and time.

Why this answer

SigninLogs contain user sign-in activities with IP address and timestamp, essential for detecting impossible travel.

Full explanation →

135

MCQhard

You are a security analyst for a company that uses Azure Firewall. You are reviewing a custom rule deployed via Azure Firewall Manager. The exhibit shows the rule configuration. The rule is intended to block inbound traffic from known Tor exit nodes. However, a recent incident involved an attacker using a Tor exit node with IP 138.197.5.5 to access an internal web server on port 8080. The log shows the traffic was ALLOWED. What is the most likely reason the rule did not block the traffic?

A.The destination port 8080 is not listed in the rule.

B.The source address range does not include 138.197.5.5.

C.The rule type is 'Prevention' but should be 'Detection'.

D.The rule priority is too low and is overridden by a higher priority rule.

AnswerA

The application rule's destination port list is the crux: it only specifies 443 (HTTPS) and 80 (HTTP), so any outbound connection to port 8080 does not match the rule's conditions, even when the destination FQDN or IP is otherwise covered. A matching source and destination are not enough; for an Azure Firewall application rule to apply, the protocol:port must also be present in the rule. Because 8080 is absent, the traffic bypasses this deny action, which explains why the connection was allowed.

Why this answer

The rule is configured to block traffic on destination port 80, but the attacker used port 8080. Azure Firewall rules are explicit; if the destination port in the traffic does not match any port specified in the rule, the rule is not applied, and the traffic is evaluated by subsequent rules or default allow logic. Since the rule only lists port 80, traffic to port 8080 is not matched, and thus the rule does not block it.

Exam trap

The trap here is that candidates assume a rule blocking a source IP will block all traffic from that IP, but Azure Firewall rules require exact port matching, and the rule only specifies port 80, not port 8080.

How to eliminate wrong answers

Option B is wrong because the exhibit shows the source address range includes 138.197.5.5, so the source IP is correctly covered. Option C is wrong because Azure Firewall Manager does not use 'Prevention' or 'Detection' rule types; those are concepts from other security products like Microsoft Defender for Cloud or IDS/IPS systems, not Azure Firewall custom rules. Option D is wrong because rule priority determines the order of evaluation, but if the rule does not match the traffic (due to port mismatch), priority is irrelevant; the rule is simply skipped.

Full explanation →

136

MCQmedium

A SOC analyst needs to ingest firewall logs from an on-premises Cisco ASA into Microsoft Sentinel. The logs are sent via syslog to a Linux server. Which data connector should the analyst use to properly parse and collect these logs?

A.Common Event Format (CEF)

B.Syslog

C.Windows Firewall

D.Cisco ASA via API

AnswerA

Common Event Format (CEF) is a Syslog-based logging standard widely used by network and security appliances, and Microsoft Sentinel provides a dedicated CEF connector that automatically parses its key-value fields into the CommonSecurityLog schema. For Cisco ASA, you configure the appliance to send CEF-formatted events to the Log Analytics agent or Azure Monitor Agent, which then enriches and normalizes the data for queries and analytics. This is the correct choice because it gives structured, schema-mapped data with minimal configuration in Sentinel.

Why this answer

The Common Event Format (CEF) connector is the correct choice because Cisco ASA firewalls send syslog messages that can be forwarded to a Linux log collector (rsyslog or syslog-ng), which then formats them into CEF (a normalized syslog format) before forwarding to the Sentinel Log Analytics workspace. This connector parses the CEF headers and maps the fields into the CommonSecurityLog table, enabling proper parsing and correlation of firewall events.

Exam trap

The trap here is that candidates see 'syslog' in the question and immediately choose the Syslog connector, not realizing that Cisco ASA logs are best ingested via the CEF connector to leverage automatic parsing into structured fields, whereas raw Syslog would require heavy KQL parsing.

How to eliminate wrong answers

Option B is wrong because the raw Syslog connector ingests syslog messages without parsing them into a structured schema; it stores them in the Syslog table as raw text, which would require custom parsing for Cisco ASA fields like source/destination IP and port. Option C is wrong because the Windows Firewall connector is designed for Windows Defender Firewall logs on Windows machines, not for on-premises Cisco ASA logs sent via syslog. Option D is wrong because Cisco ASA does not natively support a REST API for log export; the ASA uses syslog (UDP/TCP) or SNMP, and the 'Cisco ASA via API' connector does not exist in Microsoft Sentinel.

Full explanation →

137

MCQhard

Your organization has Microsoft Defender for Cloud Apps and Microsoft Sentinel integrated. You need to create an automated playbook that, when a Microsoft Sentinel incident is created from a Defender for Cloud Apps alert, automatically suspends the user in Microsoft Entra ID and sends a notification to the security team. Which two connectors should you use in the playbook?

A.Microsoft Power BI and Microsoft Teams

B.Microsoft Entra ID and Microsoft Teams

C.Azure Automation and Microsoft Sentinel

D.Microsoft Entra ID and Outlook.com

AnswerB

Correct. Entra ID suspends user, Teams sends notification.

Why this answer

Microsoft Entra ID provides the identity management action to suspend a user account, and Microsoft Teams enables sending a notification to the security team via a Teams channel or chat. This combination directly fulfills the requirements of suspending the user in Entra ID and notifying the team when a Sentinel incident is triggered from a Defender for Cloud Apps alert.

Exam trap

The trap here is that candidates often confuse Outlook.com with Office 365 Outlook (Exchange Online) or think Power BI can be used for notifications, but the question specifically requires enterprise-grade identity suspension and team notification, which only Microsoft Entra ID and Microsoft Teams provide as native connectors in a Logic App playbook.

How to eliminate wrong answers

Option A is wrong because Microsoft Power BI is a data visualization tool, not a connector for suspending users or sending real-time notifications; it cannot perform identity management actions. Option C is wrong because Azure Automation can run scripts but is not a direct connector for suspending a user in Entra ID or sending a Teams notification; it would require additional modules and complexity, and Microsoft Sentinel is the trigger, not an action connector. Option D is wrong because Outlook.com is a personal email service, not enterprise-grade for security team notifications, and it lacks the structured channel-based notification and compliance features of Microsoft Teams.

Full explanation →

138

MCQhard

A security analyst is using Microsoft 365 Defender advanced hunting to investigate potential lateral movement. The analyst has identified a compromised device (DeviceA) and wants to find all other devices that initiated a remote desktop connection from DeviceA to other devices in the last 24 hours. Which table and query approach should the analyst use?

A.Query DeviceNetworkEvents for events from DeviceA with RemotePort 3389, then join with DeviceInfo to get target device names.

B.Query DeviceLogonEvents for LogonType 10 (RemoteInteractive), filtering by initiating device.

C.Query IdentityLogonEvents to find logons associated with DeviceA.

D.Query EmailEvents to find emails sent from DeviceA that contain RDP configuration files.

AnswerA

DeviceNetworkEvents in Microsoft 365 Defender Advanced Hunting records network connection attempts by managed devices, including the destination IP and port (RemotePort) and the initiating device ID. Filtering for DeviceA and RemotePort 3389 isolates RDP traffic leaving that device, and joining to DeviceInfo on RemoteIP resolves the target device name for each inbound connection. This directly answers which devices DeviceA connected to via RDP.

Why this answer

DeviceNetworkEvents logs network connections, including outbound RDP traffic (port 3389). By filtering for events from DeviceA with RemotePort 3389, the analyst captures all RDP connections initiated by DeviceA. Joining with DeviceInfo resolves the target IP addresses to device names, providing a complete list of devices that received an RDP connection from DeviceA in the last 24 hours.

Exam trap

The trap here is that candidates confuse 'initiating an RDP connection' (network-level outbound connection) with 'successful RDP logon' (authentication event on the target), leading them to incorrectly choose DeviceLogonEvents with LogonType 10 instead of DeviceNetworkEvents.

How to eliminate wrong answers

Option B is wrong because DeviceLogonEvents with LogonType 10 (RemoteInteractive) records successful interactive logons on the target device, not the initiation of an RDP connection from the source device; it would show logons on DeviceA from other devices, not connections from DeviceA to others. Option C is wrong because IdentityLogonEvents tracks authentication events at the identity level (e.g., Azure AD logons), not device-level network connections or RDP session initiations. Option D is wrong because EmailEvents logs email traffic, not network connections; RDP configuration files attached to emails are irrelevant to detecting actual RDP connections made from DeviceA.

Full explanation →

139

MCQhard

A security analyst in Microsoft Sentinel wants to correlate Microsoft Entra ID sign-in logs with IP addresses known to be associated with a threat actor. The threat actor's IPs are stored in a custom table named 'ThreatIntelligence_IP' that is ingested daily. The analyst needs to create an analytics rule that triggers only when a sign-in occurs from one of these IPs AND when the user is not in a list of approved users (stored in another custom table 'ApprovedUsers'). Which KQL query pattern should the analyst use to achieve this correlation and filtering?

A.SigninLogs | join ThreatIntelligence_IP on IPAddress | where UserId notin (ApprovedUsers | project UserId)

B.SigninLogs | where IPAddress in (ThreatIntelligence_IP | project IPAddress) and UserId !in (ApprovedUsers | project UserId)

C.SigninLogs | join kind=inner ThreatIntelligence_IP on IPAddress | join kind=leftanti (ApprovedUsers | project UserId) on $left.UserId == $right.UserId

D.SigninLogs | join ThreatIntelligence_IP on IPAddress | where not(UserId in (ApprovedUsers | project UserId))

AnswerC

This is the correct pattern. The first join uses `kind=inner`, which explicitly returns only matching rows from both sides without deduplicating the left-side SigninLogs rows—unlike the default `innerunique`—thereby preserving all sign-in events from threat-actor IPs. The second join uses `kind=leftanti` to keep every row from the left that has no match in the ApprovedUsers table on UserId, which is the exact semantic needed to exclude approved users. Both joins are optimized by the Kusto engine using hash-based algorithms, making this approach both logically clear and performant for large Sentinel tables.

Why this answer

It uses a `join kind=inner` to match sign-in logs with threat IPs, ensuring only sign-ins from known malicious IPs are considered. It then applies a `join kind=leftanti` to exclude any user who appears in the ApprovedUsers table, effectively filtering out approved users. This pattern guarantees that the rule triggers only when both conditions are met: the IP is in the threat list and the user is not approved.

Exam trap

The trap here is that candidates often choose Option B thinking that `in` and `!in` with subqueries are the simplest way to filter, but they overlook that KQL requires proper join semantics for correlating two tables, and that `in` with a table expression may not work as expected in all contexts, especially when the subquery returns multiple rows or columns.

How to eliminate wrong answers

Option A is wrong because it uses a `join` without specifying a join kind, which defaults to `innerunique` and may produce duplicate or unexpected results, and the `where` clause after the join does not properly exclude approved users as a set operation. Option B is wrong because it uses `in` and `!in` operators with subqueries that are not supported in the `where` clause for table expressions; KQL requires `in` to work with a list or a subquery that returns a single column, but the syntax `UserId !in (ApprovedUsers | project UserId)` is valid only if the subquery is enclosed in parentheses and the table is referenced correctly, but the main issue is that `IPAddress in (ThreatIntelligence_IP | project IPAddress)` is inefficient and may cause performance issues or incorrect results due to lack of proper join semantics. Option D is wrong because it uses a `join` without specifying a kind (defaulting to `innerunique`), and the `where` clause with `not(UserId in (...))` is syntactically incorrect as `not` cannot be applied to an `in` operator in that way; the correct syntax would be `where UserId !in (...)`.

Full explanation →

140

MCQhard

A company uses Microsoft Defender for Cloud with Defender for Servers enabled. The security team wants to receive an alert when a new user is added to the local Administrators group on a Windows virtual machine. Which data source must be enabled in Defender for Cloud to capture this event?

A.Enable the collection of Windows Security Event Log events (e.g., Event ID 4732) through the Log Analytics agent configuration.

B.Enable Just-in-Time (JIT) VM access on the virtual machine.

C.Enable Adaptive Application Controls (AAC) for the virtual machine.

D.Enable Azure Defender for SQL on the subscription.

AnswerA

Correct. Local group changes are captured via Windows security event 4732. To get this into Defender for Cloud, you must ensure the Log Analytics agent is collecting security events and that the required audit policies are in place.

Why this answer

The event of adding a user to the local Administrators group on Windows is logged as Security Event ID 4732. To capture this event in Defender for Cloud, the Log Analytics agent must be configured to collect Windows Security Event Log events, which includes Event ID 4732. This data source enables Defender for Cloud to generate security alerts based on such privileged group modifications.

Exam trap

The trap here is that candidates may confuse data collection sources (e.g., JIT, AAC, or SQL Defender) with the specific Windows Security Event Log required to detect local group membership changes, assuming any security control can generate the alert.

How to eliminate wrong answers

Option B is wrong because Just-in-Time (JIT) VM access controls network access to management ports (e.g., RDP, SSH) and does not capture local group membership changes. Option C is wrong because Adaptive Application Controls (AAC) define allowlists for running applications on VMs and do not monitor or alert on user account modifications. Option D is wrong because Azure Defender for SQL is a plan for securing SQL databases and servers, not for monitoring local user group changes on Windows VMs.

Full explanation →

141

MCQmedium

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. A new security policy requires that all incidents involving 'Credential Access' tactics be automatically assigned to the Tier 1 SOC team and have a severity of 'High'. You need to configure this automation. What should you do?

A.Configure an automated investigation rule in Microsoft Defender XDR to assign incidents.

B.Create a playbook in Microsoft Sentinel that runs on incident creation and assigns the incident to Tier 1 SOC.

C.Create an automation rule in Microsoft Sentinel with conditions for tactic 'Credential Access' and actions to assign to Tier 1 SOC and set severity to High.

D.Modify the analytics rule that generates the incidents to include the assignment and severity settings.

AnswerC

Correct: Automation rules can set incident properties based on conditions.

Why this answer

Automation rules in Microsoft Sentinel allow you to define conditions based on incident properties, such as tactic, and then trigger actions like assigning the incident to a specific owner (Tier 1 SOC) and setting the severity. This directly meets the policy requirement without requiring external playbooks or modifying analytics rules.

Exam trap

The trap here is that candidates may confuse automation rules (incident-level) with automated investigation rules (Defender XDR) or think that analytics rules can directly assign incidents, when in fact automation rules are the correct post-creation mechanism for assignment and severity changes.

How to eliminate wrong answers

Option A is wrong because automated investigation rules in Microsoft Defender XDR are designed for automated response actions (e.g., isolating devices) and cannot assign incidents to a SOC team or set severity based on MITRE tactics. Option B is wrong because while a playbook can assign incidents, it requires additional configuration and is not the simplest or most direct method; automation rules are the native, recommended approach for incident-level automation in Sentinel. Option D is wrong because analytics rules generate alerts/incidents but do not support actions like assignment or severity override; those are post-creation automation tasks.

Full explanation →

142

MCQeasy

A security administrator wants to enable Microsoft Defender for Cloud on all Azure subscriptions to generate security alerts for resources. What is the minimum configuration required on a subscription?

A.Assign Azure Policy to enable Defender for Cloud plans on the subscription

B.Enable enhanced security features on the subscription

C.Install the Azure Monitor Agent on all virtual machines in the subscription

D.Enable Microsoft Defender for Cloud at the management group level only

AnswerB

Enabling enhanced security features on the subscription is the minimum configuration required to activate Microsoft Defender for Cloud and start receiving security alerts. This action, performed in the Defender for Cloud environment settings, moves the subscription from the free basic tier to the Standard tier, enabling threat detection and vulnerability assessments across all supported resource types. Without this direct enablement, no security alerts or advanced protections are available, regardless of other configurations.

Why this answer

Enabling enhanced security features (now called Defender for Cloud plans) on a subscription is the minimum configuration required to generate security alerts. This action activates the Defender for Cloud workload protection plans (e.g., Defender for Servers, Defender for SQL) that provide threat detection and alerts for resources within that subscription. Without this step, the subscription remains in the free tier, which only offers basic security assessments and recommendations, not security alerts.

Exam trap

The trap here is that candidates often confuse enabling Defender for Cloud plans (the minimum requirement for alerts) with deploying agents or assigning policies, which are additional steps for enhanced coverage or governance, not the baseline configuration.

How to eliminate wrong answers

Option A is wrong because assigning an Azure Policy to enable Defender for Cloud plans is not the minimum configuration; it is a governance method to enforce the plans across multiple subscriptions, but the plans themselves must first be enabled at the subscription level. Option C is wrong because installing the Azure Monitor Agent on all virtual machines is not required for generating security alerts from Defender for Cloud; alerts can be generated from platform-level telemetry and other data sources without the agent, though the agent enhances detection for certain workloads. Option D is wrong because enabling Defender for Cloud at the management group level only does not automatically enable it on individual subscriptions; each subscription must have the plans enabled to generate alerts, and management group inheritance applies to policy assignments, not the enabling of security plans.

Full explanation →

143

MCQhard

A SOC team uses Microsoft Sentinel with multiple workspaces in a single region. They have deployed Azure Policy to send all Azure resource logs to a central Log Analytics workspace. Now they want to create a set of analytics rules that run across multiple workspaces to detect cross-workspace attacks. However, they note that the built-in analytics rules can only query data within the workspace they are defined. Which solution should the team implement to efficiently query data from multiple workspaces for detection?

A.Use Azure Lighthouse to delegate management and then create rules in the managing workspace that use workspace() expressions

B.Create a KQL function that unions the relevant tables from all workspaces using the workspace() expression, then use that function in the analytics rule query

C.Configure the analytics rule to run in Log Analytics workspace manager and use cross-workspace queries native to Copilot for Security

D.Enable cross-workspace incident view in Sentinel settings and define the rule in the central workspace to automatically query all linked workspaces

AnswerB

The recommended pattern is to create a KQL saved function that unions the target tables from every workspace using workspace() expressions, for example: union workspace('ws1').SecurityEvent, workspace('ws2').SecurityEvent. Then you reference that function directly inside the analytics rule query, allowing the rule to evaluate events across all workspaces in a single execution. This approach is reusable, keeps the rule query clean, and is the standard way to achieve multi-workspace detection in Microsoft Sentinel.

Why this answer

KQL functions can encapsulate cross-workspace queries using the `workspace()` expression, allowing an analytics rule to query multiple Log Analytics workspaces from a single rule definition. This approach efficiently reuses the union logic across rules without modifying each rule individually, addressing the limitation that built-in rules can only query their own workspace.

Exam trap

The trap here is that candidates confuse Azure Lighthouse's cross-tenant management delegation with cross-workspace querying, or assume that a central workspace automatically queries linked workspaces without explicit KQL expressions.

How to eliminate wrong answers

Option A is wrong because Azure Lighthouse delegates management across tenants, not across workspaces within the same tenant/region, and `workspace()` expressions in a managing workspace still only query that workspace unless explicitly used in a cross-workspace query. Option C is wrong because Log Analytics workspace manager does not exist as a feature; Copilot for Security is an AI assistant, not a cross-workspace query engine for analytics rules. Option D is wrong because cross-workspace incident view is a visualization feature, not a mechanism to make analytics rules query multiple workspaces; rules must explicitly include `workspace()` expressions to span workspaces.

Full explanation →

144

MCQhard

An organization uses Microsoft Defender for Office 365. A security analyst is investigating a phishing email that was delivered to a user. The user clicked the link, but it was blocked by Defender for Office 365 at the time of click. The analyst needs to view the full click verdict, including the specific block action (e.g., blocked by custom block list). Where can the analyst find this information?

A.Threat Explorer in Microsoft 365 Defender

B.The email entity page in Microsoft 365 Defender

C.The advanced hunting table EmailEvents

D.The Attack simulation training dashboard

AnswerB

The email entity page in Microsoft 365 Defender is the correct answer because it consolidates an email's protection status, delivery outcome, and all user interactions into one view. Under its 'Click verdict' section, it lists the user who clicked, the URL, the verdict (such as Blocked or Allowed), and the blocking reason, enabling an admin to quickly determine why a specific link was blocked for that recipient.

Why this answer

The email entity page in Microsoft 365 Defender provides the full click verdict for a specific email, including the exact block action (e.g., blocked by custom block list, blocked by URL reputation). This page aggregates all detection and verdict details for a single email, making it the correct location for the analyst to view the specific block action at time of click.

Exam trap

The trap here is that candidates often assume Threat Explorer (Option A) is the go-to for all email investigation details, but it aggregates data and requires navigation to the email entity page to see the specific click verdict and block action.

How to eliminate wrong answers

Option A is wrong because Threat Explorer shows aggregated threat data and trends, but does not display the full click verdict with the specific block action for a single email; it requires drilling into the email entity page for that detail. Option C is wrong because the advanced hunting table EmailEvents contains raw event data but does not include the full click verdict or the specific block action; it requires joining with other tables and does not present the verdict in a user-friendly format. Option D is wrong because the Attack simulation training dashboard is used for managing simulated phishing campaigns and training, not for viewing real click verdicts or block actions from actual phishing emails.

Full explanation →

145

Drag & Dropmedium

Order the steps to investigate a user account compromise using Microsoft Sentinel incidents.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Investigation starts with incident details, then reviewing alerts and behavior analytics, followed by deep querying, and finally remediation.

Full explanation →

146

MCQhard

An organization manages multiple Azure subscriptions under a single management group. They want to automatically enable Microsoft Defender for Cloud's enhanced security plans (e.g., Defender for Servers) on any new subscription added to the management group. Which configuration method should they use?

A.Create an Azure Policy that assigns the Defender for Cloud pricing tier at the management group level

B.Enable auto-provisioning in Defender for Cloud's settings

C.Use Azure Blueprints to define the subscription configurations

D.Manually enable plans per subscription as they are added

AnswerA

Azure Policy can enforce the 'Pricing tier' setting at a scope. When new subscriptions are added under the management group, they automatically get the policy and the plan is enabled.

Why this answer

Azure Policy can be assigned at the management group scope to enforce the 'Configure Microsoft Defender for Cloud plans to be enabled' policy, which automatically sets the pricing tier (e.g., Standard) for Defender for Servers on any new subscription added to that management group. This ensures compliance without manual intervention, as the policy evaluates and remediates new subscriptions upon creation or addition.

Exam trap

The trap here is that candidates often confuse auto-provisioning (which installs agents) with policy-based enforcement of pricing tiers, leading them to select Option B instead of recognizing that Azure Policy at the management group level is the correct method for automatic, scalable plan activation.

How to eliminate wrong answers

Option B is wrong because auto-provisioning in Defender for Cloud's settings only enables the automatic installation of the Log Analytics agent on existing VMs, not the activation of enhanced security plans for new subscriptions. Option C is wrong because Azure Blueprints can define subscription configurations, but they require explicit assignment to each subscription and do not automatically apply to new subscriptions added to a management group; Azure Policy is the native tool for continuous compliance enforcement. Option D is wrong because manually enabling plans per subscription is not scalable and contradicts the requirement for automatic enablement on new subscriptions.

Full explanation →

147

MCQeasy

A SOC analyst wants to create a scheduled analytics rule in Microsoft Sentinel that runs every 5 minutes and alerts when a single IP address fails to authenticate more than 10 times in that time window using the Microsoft Entra ID SigninLogs table. Which KQL function should be used to group the results into 5-minute intervals?

A.bin()

B.summarize

C.count

D.where

AnswerA

The bin() function in KQL is a scalar function that rounds a datetime value down to the nearest multiple of the specified interval, such as 5 minutes (e.g., bin(TimeGenerated, 5m)). This creates uniform time buckets that allow a scheduled analytics rule to aggregate events into fixed windows, making it essential for time-series analysis, rate detection, and anomaly identification. Without bin(), time values remain continuous and ungrouped, so patterns across discrete intervals would be impossible to discern. In practice, you pair bin() with summarize, as in `summarize count() by bin(TimeGenerated, 5m)`, to produce the time-bucketed aggregates the rule needs.

Why this answer

The `bin()` function is the correct choice because it is specifically designed to group time-series data into fixed-size buckets (e.g., 5-minute intervals) for aggregation. In this scenario, you need to align each authentication event to its corresponding 5-minute window so that you can count failures per IP address per window. Without `bin()`, the `summarize` operator would not automatically create these fixed intervals; it would group by the raw timestamp values, which would not produce the required 5-minute buckets.

Exam trap

Microsoft often tests the distinction between the `summarize` operator and the `bin()` function, trapping candidates who think `summarize` alone can bucket time, when in fact `bin()` must be used as the grouping expression inside `summarize` to create fixed time intervals.

How to eliminate wrong answers

Option B (summarize) is wrong because `summarize` is an operator that aggregates data, but it requires a grouping expression (like `bin()`) to create time buckets; by itself, it does not group timestamps into 5-minute intervals. Option C (count) is wrong because `count` is an aggregation function used within `summarize` to count rows, not a function to group results into time intervals. Option D (where) is wrong because `where` is a filtering operator that selects rows based on a condition; it cannot group or bucket data into time windows.

Full explanation →

148

MCQmedium

Your organization uses Microsoft Sentinel. A security analyst reports that an incident was automatically closed by a playbook before the investigation was complete. What should you do to prevent automatic closure in the future?

A.Disable the playbook

B.Remove the playbook from the automation rule

C.Modify the analytics rule to not automatically close incidents

D.Disable the automation rule that triggers the playbook

AnswerC

This prevents the playbook from closing incidents automatically.

Why this answer

The analytics rule that generates the incident includes a setting to automatically close incidents when an alert is triggered again. Modifying this setting prevents the incident from being closed prematurely, regardless of any playbook or automation rule. This ensures that incidents remain open for investigation until manually resolved.

Exam trap

The trap here is that candidates often focus on the playbook or automation rule as the cause of the closure, overlooking the analytics rule's built-in auto-close setting, which is the actual source of the behavior.

How to eliminate wrong answers

Option A is wrong because disabling the playbook would stop all its actions, not just the automatic closure, and may break other necessary automations. Option B is wrong because removing the playbook from the automation rule would prevent the playbook from running at all, but the underlying analytics rule setting would still automatically close the incident. Option D is wrong because disabling the automation rule would stop all triggers for that rule, including any other actions or playbooks, and does not address the analytics rule's auto-close setting.

Full explanation →

149

MCQhard

A security team wants to automatically block an IP address in Azure Firewall when Microsoft Sentinel detects a high number of failed logins from that IP. Which automation approach should they use?

A.Create an automation rule that triggers a playbook directly.

B.Create a scheduled analytics rule that runs a playbook.

C.Create an automation rule that triggers on incident creation and runs a playbook that uses the Azure Firewall connector to add a rule.

D.Configure a Logic App to poll Sentinel alerts and block IPs.

AnswerC

This is the correct architecture because it uses an automation rule with an incident-created trigger, which fires automatically when an incident is raised, and that rule runs a playbook as its action. The playbook—an Azure Logic App—uses the Azure Firewall connector to create a network or application rule in an Azure Firewall policy that denies inbound or outbound traffic from the offending IP address. This method is event-driven, near-real-time, and uses the proper Sentinel automation path, verifying that the automation rule's action is to invoke the playbook, which then performs the actual blocking via the firewall.

Why this answer

It uses an automation rule triggered on incident creation to run a playbook, which can leverage the Azure Firewall connector to add a blocking rule. This approach directly integrates Sentinel's detection of a high number of failed logins with automated remediation in Azure Firewall, ensuring a real-time response without manual intervention.

Exam trap

The trap here is that candidates may confuse automation rules with analytics rules, thinking a scheduled analytics rule can directly run a playbook, when in fact analytics rules only generate alerts/incidents, and playbooks are triggered separately via automation rules or incident/alert actions.

How to eliminate wrong answers

Option A is wrong because automation rules can trigger playbooks directly on alert or incident creation, but the question specifies blocking an IP in Azure Firewall, which requires a playbook with the Azure Firewall connector; however, the phrasing 'triggers a playbook directly' is too vague and does not specify the necessary connector or action, making it incomplete. Option B is wrong because scheduled analytics rules are used to generate alerts based on periodic queries, not to run playbooks; playbooks are executed by automation rules or directly from incidents/alerts, not by the analytics rule itself. Option D is wrong because polling Sentinel alerts with a Logic App is inefficient and not the recommended pattern; Sentinel provides native automation through automation rules and playbooks, and polling introduces latency and complexity compared to event-driven triggers.

Full explanation →

150

MCQmedium

An organization uses Microsoft Defender for Cloud and needs to track compliance with internal security policies that are not covered by any built-in regulatory standard. They want to see the compliance status for these internal controls in the Regulatory Compliance dashboard alongside other standards. What should they configure?

A.Create a custom Azure Policy initiative with the required controls and assign it to the relevant scopes.

B.Create a custom assessment in the Microsoft Defender for Cloud recommendations dashboard.

C.Use the Secure Score API to develop a custom dashboard outside Defender for Cloud.

D.Enable the "Custom compliance" feature in Defender for Cloud's pricing tier.

AnswerA

Defender for Cloud's Regulatory Compliance dashboard is implemented through Azure Policy initiatives, so to track internal or custom controls you must create a custom initiative that includes the required policy definitions (e.g., audit, deny, or deployIfNotExists effects). Assign that initiative to the relevant management group or subscription, and map its controls to the compliance framework in Defender for Cloud. This automatically generates continuous compliance assessments and integrates the results into the secure score and compliance dashboard, which is exactly the intended method for tracking custom requirements.

Why this answer

To track compliance with internal security policies not covered by built-in regulatory standards, you must create a custom Azure Policy initiative that defines the required controls and assign it to the relevant scopes. Defender for Cloud automatically evaluates resources against assigned initiatives and surfaces the compliance status in the Regulatory Compliance dashboard alongside built-in standards, allowing unified visibility.

Exam trap

The trap here is that candidates confuse custom assessments in the recommendations dashboard with custom compliance controls, not realizing that only custom Azure Policy initiatives are surfaced in the Regulatory Compliance dashboard.

How to eliminate wrong answers

Option B is wrong because creating a custom assessment in the recommendations dashboard only adds a security recommendation, not a compliance control that appears in the Regulatory Compliance dashboard; it does not integrate with the compliance framework. Option C is wrong because using the Secure Score API to develop a custom dashboard outside Defender for Cloud bypasses the Regulatory Compliance dashboard entirely, failing to meet the requirement of seeing compliance status alongside other standards within Defender for Cloud. Option D is wrong because there is no 'Custom compliance' feature in Defender for Cloud's pricing tier; the pricing tier controls features like cloud security posture management (CSPM) but does not enable custom compliance tracking.

Full explanation →

Microsoft Security Operations Analyst SC-200 (SC-200) — Questions 76–150