Microsoft Security Operations Analyst SC-200 SC-200 Questions 526–600 | Page 8/18

526

MCQmedium

A company has enabled Microsoft Defender for Cloud on their subscription containing Azure SQL databases. They receive an alert about a potential SQL injection attack. The analyst wants to see the actual query that was executed. Where can the analyst find the query details associated with the alert?

A.In the alert's entity tab

B.By opening the SQL database's threat detection logs

C.In the Azure Activity Log

D.In the alert's diagnostic data

AnswerA

The entity tab on a Microsoft Defender for Cloud alert details page provides a curated, contextual view of all affected resources and associated security entities. For SQL alerts, this includes the exact SQL query text that triggered the detection, along with related details such as the user account, source IP, and database. This is the designed interface to locate the flagged query, as it is directly tied to the alert's investigation workflow.

Why this answer

When Microsoft Defender for Cloud detects a SQL injection attack, the alert details include an 'Entities' tab that contains the actual SQL query that was executed. This tab provides the raw query text, which is essential for the analyst to understand the exact payload used in the attack and to assess the impact on the database.

Exam trap

The trap here is that candidates often confuse the Azure Activity Log (control-plane) with data-plane logs, or assume that threat detection logs are the primary source for query details, when in fact the alert's entity tab is the direct, curated source for the executed query.

How to eliminate wrong answers

Option B is wrong because SQL database's threat detection logs (e.g., Azure SQL Auditing or Advanced Threat Protection logs) may show query patterns but do not directly expose the specific query associated with a Defender for Cloud alert; the alert itself surfaces the query in its entities. Option C is wrong because the Azure Activity Log records control-plane operations (e.g., resource creation, policy changes) and does not capture data-plane events like SQL queries executed against a database. Option D is wrong because the alert's diagnostic data typically includes metadata such as severity, timestamp, and affected resources, but not the actual SQL query text; that is stored in the entities tab.

Full explanation →

527

MCQhard

Your company uses Microsoft Defender for Cloud to assess the security posture of hybrid workloads. You are configuring a governance rule to automatically remediate a specific recommendation that is out of compliance. The recommendation is 'Virtual machines should be migrated to new Azure Resource Manager resources'. You need to ensure that the remediation is applied at scale across all subscriptions in the management group. What should you do?

A.Create a PowerShell script that runs on each VM to migrate it, and execute it via Azure Automation.

B.Create an Azure Policy initiative that includes the recommendation and assign it with a remediation task at the management group level.

C.Create a governance rule in Microsoft Defender for Cloud with scope set to the management group, condition on the recommendation, and action set to 'Automatic'.

D.Create a governance rule in Microsoft Defender for Cloud with scope set to a single subscription and action set to 'Automatic'.

AnswerC

To meet the requirement, create a governance rule in Microsoft Defender for Cloud with scope set to the management group, a condition that includes the specific recommendation, and an action of 'Automatic'. Scoping at the management group makes the rule inherit to all subscriptions beneath it, so every VM is assessed, and the 'Automatic' action invokes Defender's built-in remediation capability to migrate the VMs without manual intervention. This is the native mechanism designed for exactly this scenario.

Why this answer

Governance rules in Microsoft Defender for Cloud allow you to define automatic remediation actions for specific recommendations at scale. By setting the scope to the management group, the rule applies to all subscriptions within that group, and the 'Automatic' action triggers the built-in remediation script for the 'Virtual machines should be migrated to new Azure Resource Manager resources' recommendation without requiring custom scripting or policy assignments.

Exam trap

The trap here is that candidates may confuse Azure Policy remediation tasks with Defender for Cloud governance rules, not realizing that governance rules provide a simpler, built-in mechanism for automatic remediation of specific recommendations at scale without requiring separate policy assignments.

How to eliminate wrong answers

Option A is wrong because creating a PowerShell script and executing it via Azure Automation is a manual, custom approach that does not leverage Defender for Cloud's native governance rule capability for automatic, at-scale remediation across all subscriptions in a management group. Option B is wrong because Azure Policy initiatives can enforce compliance but do not directly integrate with Defender for Cloud's governance rules for automatic remediation of specific recommendations; a governance rule is the correct mechanism for this scenario. Option D is wrong because setting the scope to a single subscription would not apply the remediation across all subscriptions in the management group, failing the requirement for at-scale application.

Full explanation →

528

MCQeasy

A threat hunter in Microsoft Sentinel wants to detect attempts to disable security logging on Windows servers using a KQL query. Which Windows Event ID should the query filter on to capture security log clearing events?

A.4688

B.4624

C.5145

D.1102

AnswerD

Event ID 1102 records the Windows security audit log being cleared, written to the Security log whenever someone runs wevtutil or clears it via Event Viewer. Filtering on 1102 in the KQL query therefore surfaces exactly the anti-forensic behaviour the hunter targets, satisfying the requirement to detect security logging being disabled on those servers.

Why this answer

Event ID 1102 in the Windows Security log indicates the security log was cleared, which is a common technique used by attackers to cover their tracks. Option A (4688) is for process creation. Option B (4624) is for successful logon.

Option C (5145) is for network share access. Therefore, only Option D (1102) correctly captures security log clearing events.

Full explanation →

529

MCQmedium

An organization has enabled Microsoft Defender for Cloud's enhanced security features. They want to ensure that newly provisioned Azure virtual machines automatically have the built-in vulnerability assessment solution installed. Which configuration should they enable in Defender for Cloud?

A.Auto-provisioning of the Log Analytics agent

B.Auto-provisioning of the vulnerability assessment solution

C.Automatic provisioning of all security agents

D.Azure Policy assignment for Update Management

AnswerB

Auto-provisioning of the vulnerability assessment solution is the correct setting because when enabled, Defender for Cloud automatically deploys a vulnerability assessment scanner (either the Qualys agent or the Microsoft integrated solution) to all new and existing VMs. This agent continuously scans for software vulnerabilities and missing updates without requiring manual per-VM installation. By enabling this auto-provisioning, you ensure that every newly created VM is immediately covered by vulnerability scanning, which directly addresses the requirement for continuous scanning.

Why this answer

Microsoft Defender for Cloud's enhanced security features include a dedicated auto-provisioning setting specifically for the built-in vulnerability assessment solution (powered by Qualys). When enabled, this setting automatically deploys the vulnerability assessment extension to all new and existing Azure VMs, ensuring continuous vulnerability scanning without manual intervention.

Exam trap

The trap here is that candidates often confuse the Log Analytics agent's auto-provisioning (which enables data collection for security alerts) with the separate vulnerability assessment auto-provisioning, assuming that log collection alone covers vulnerability scanning, when in fact a dedicated extension is required for that purpose.

How to eliminate wrong answers

Option A is wrong because auto-provisioning of the Log Analytics agent collects security events and telemetry for monitoring, but it does not install the vulnerability assessment solution; the vulnerability scanner is a separate extension. Option C is wrong because 'automatic provisioning of all security agents' is not a specific configuration in Defender for Cloud; the platform offers individual auto-provisioning toggles for specific agents (e.g., Log Analytics, vulnerability assessment, endpoint protection), not a single 'all agents' option. Option D is wrong because Azure Policy assignment for Update Management manages OS patch compliance via Azure Automation Update Management, not the installation of a vulnerability assessment solution.

Full explanation →

530

MCQhard

Your company uses Microsoft Defender for Endpoint (MDE) on all Windows 10 devices. You are investigating a machine that is suspected of being part of a botnet. The machine is communicating with a known C2 server at IP 203.0.113.55. You have confirmed that the IP is malicious. You need to block all outbound traffic from the machine to that IP immediately, and also ensure that no other devices in the organization can communicate with that IP. The solution must be implemented without deploying additional network appliances. What should you do?

A.Create a network protection policy in Microsoft Intune to block the IP

B.Create a custom network indicator in Microsoft Defender for Endpoint with action 'Alert and block'

C.Use the Microsoft Defender for Endpoint portal to block the IP globally

D.Create a firewall rule in Windows Defender Firewall to block outbound traffic to the IP, and deploy via Group Policy

AnswerB

Custom network indicators in Microsoft Defender for Endpoint let you block outbound traffic to a specified IP across all onboarded devices, using the existing agent rather than adding network appliances, satisfying both the immediate block and organisation-wide enforcement.

Why this answer

Custom network indicators in Microsoft Defender for Endpoint allow you to define IP addresses, URLs, or domains and assign an action of 'Alert and block' or 'Alert only'. When set to 'Alert and block', the indicator is enforced on all onboarded devices via the Defender for Endpoint network protection stack, blocking outbound connections to the specified IP without requiring any additional network appliances. This satisfies both requirements: immediate blocking on the affected machine and organization-wide enforcement across all MDE-onboarded Windows 10 devices.

Exam trap

SC-200 often tests the difference between Defender for Endpoint custom indicators (IOC-based, tenant-wide, no extra appliances) and Intune/Windows Firewall policies, tricking candidates into picking the more familiar firewall or Intune option when the question explicitly says 'no additional network appliances' and 'all devices'.

How to eliminate wrong answers

Option A is wrong because Intune network protection policies configure the Windows Defender SmartScreen/network protection feature but do not accept raw IP addresses as block entries — they rely on Defender for Endpoint indicators or web content filtering categories. Option C is wrong because there is no standalone 'block IP globally' button in the MDE portal; blocking is done through indicators (IOCs), not a generic portal toggle. Option D is wrong because a Windows Defender Firewall rule deployed via GPO only affects domain-joined Windows devices in scope of the GPO, does not integrate with MDE telemetry, and constitutes an additional management mechanism rather than using the existing MDE platform.

Full explanation →

531

MCQmedium

You are a security operations analyst for a company that uses Microsoft Defender XDR. You need to configure alert notifications so that the security team receives an email whenever a high-severity alert is generated. What should you do?

A.In Microsoft Sentinel, create an automation rule that triggers on high-severity incidents and sends an email using a playbook.

B.In Microsoft Defender for Endpoint, configure alert notifications for high-severity alerts.

C.In Azure Monitor, create an action group that sends emails for high-severity alerts from Microsoft Defender XDR.

D.In the Microsoft 365 Defender portal, go to Settings > Microsoft 365 Defender > Alert notifications, and create a new notification rule with severity set to High.

AnswerD

The Microsoft 365 Defender portal provides alert notification settings where you can define rules based on alert severity. Creating a rule with severity High ensures that only high-severity alerts trigger email notifications to the specified recipients. This is the correct method.

Why this answer

Microsoft Defender XDR provides built-in alert notification settings that allow you to define rules based on severity, alert category, and other criteria. Configuring a notification rule with severity High ensures that the security team receives email alerts for high-severity incidents across all Defender workloads.

Exam trap

The trap here is assuming that Defender for Endpoint notification settings cover all Defender XDR alerts; they only cover endpoint alerts, while the Microsoft 365 Defender portal settings cover all workloads.

Full explanation →

532

Multi-Selectmedium

Your organization uses Microsoft 365 Defender. You are investigating a potential malware outbreak on several endpoints. Which TWO actions should you take to isolate affected devices and prevent lateral movement?

Select 2 answers

A.Use Microsoft Defender for Endpoint to initiate device isolation on affected devices.

B.Run a full antivirus scan on all endpoints.

C.Reset the passwords of all users on the affected devices.

D.Delete the user accounts that logged into the affected devices.

E.Block the file hash of the malware in Microsoft Defender for Endpoint indicators.

AnswersA, E

Device isolation should be initiated from the Microsoft 365 Defender portal on each affected endpoint. This action immediately blocks all inbound and outbound network communications, except traffic to the Defender service, so the attacker loses the ability to move laterally, communicate with command-and-control servers, or exfiltrate data while the investigation continues. It is the first-line containment control when an active infection is confirmed.

Why this answer

Microsoft Defender for Endpoint's device isolation feature disconnects the device from the network while keeping the endpoint connected to the Defender service for monitoring and remediation. This prevents lateral movement by stopping all inbound and outbound communication, effectively containing the malware without losing visibility or control.

Exam trap

The trap here is that candidates often confuse reactive remediation actions (like scanning or password resets) with proactive containment actions, failing to recognize that only network-level isolation and indicator blocking directly prevent lateral movement.

Full explanation →

533

MCQmedium

Refer to the exhibit. You are reviewing a Microsoft Sentinel scheduled analytics rule defined in JSON. The rule is intended to trigger an incident when more than 5 sign-ins from anomalous locations occur within an hour. However, the rule is not triggering as expected. What is the most likely cause?

A.The severity is set to 'Medium', but it must be an integer.

B.The query references a column that does not exist in the SigninLogs table.

C.The triggerThreshold is set to 5, but it should be a string like '5'.

D.The queryFrequency and queryPeriod are set to the same value, which is not allowed.

AnswerB

The rule fails because the KQL query references a column that does not exist in the SigninLogs table. Sentinel resolves column names against the actual Log Analytics schema, so an unknown column such as a misspelled or guessed field name produces a 'Failed to resolve scalar expression' error when the rule is validated or run. The query must reference a valid column from the SigninLogs schema, such as RiskLevelDuringSignIn or RiskLevelAggregated when evaluating risk level.

Why this answer

The query references a column that does not exist in the SigninLogs table. In Microsoft Sentinel, if a scheduled analytics rule's KQL query references a non-existent column, the query will fail silently or return no results, preventing the rule from triggering an incident. The rule logic depends on the query returning a result set that meets the trigger threshold, and a missing column causes the query to fail or return zero rows.

Exam trap

The trap here is that candidates may focus on the JSON syntax or rule configuration parameters (like severity type or triggerThreshold) instead of recognizing that the core issue is a KQL query referencing a non-existent column, which is a common data source mismatch error.

How to eliminate wrong answers

Option A is wrong because the 'severity' field in a Sentinel analytics rule JSON must be a string (e.g., 'Medium'), not an integer; the rule would fail to validate if it were an integer. Option C is wrong because 'triggerThreshold' is not a valid field in a Sentinel scheduled analytics rule; the correct field is 'triggerOperator' and 'triggerThreshold' is used in other contexts like Azure Monitor alerts, and it must be an integer, not a string. Option D is wrong because setting 'queryFrequency' and 'queryPeriod' to the same value is allowed and is actually common for rules that look back exactly one frequency window; the rule would still run correctly.

Full explanation →

534

Multi-Selectmedium

Which THREE indicators of compromise (IOCs) are commonly used in Microsoft Sentinel to detect advanced persistent threats (APTs)? (Choose THREE.)

Select 3 answers

A.Suspicious domains and URLs.

B.Vulnerability scan results.

C.File hashes (SHA256) of known malware.

D.Windows event IDs for successful logins.

E.IP addresses of known command and control servers.

AnswersA, C, E

Suspicious domains and URLs are network-based IOCs that Microsoft Sentinel matches against DNS, proxy, and firewall logs to surface command-and-control beaconing and phishing infrastructure. They satisfy the APT detection requirement because advanced persistent threats routinely rely on domain generation algorithms and compromised legitimate sites, making domain and URL indicators high-fidelity detection signals.

Why this answer

Option A is correct because suspicious domains and URLs are classic network-based IOCs that Microsoft Sentinel ingests via threat intelligence connectors and matches against DNS, proxy, and firewall logs to surface APT beaconing or phishing infrastructure. Option C is correct because SHA256 file hashes of known malware are high-fidelity, atomic IOCs that Sentinel uses in scheduled analytics rules and the Threat Intelligence matching rule to detect malicious binaries on endpoints and in file events. Option E is correct because IP addresses of known command-and-control servers are standard network IOCs that Sentinel correlates with CommonSecurityLog, Azure Firewall, and DNS data to identify active C2 communication.

Option B is not an IOC but a vulnerability assessment artifact describing exposure rather than evidence of compromise, and Option D is a normal operational event (e.g., Event ID 4624) that only becomes suspicious in context, not a standalone IOC.

Exam trap

The trap here is that candidates confuse vulnerability data (Option B) or routine operational events (Option D) with true IOCs, which must directly indicate a past or ongoing compromise rather than a potential risk or normal behavior.

Full explanation →

535

MCQhard

Your organization has a hybrid identity environment with Microsoft Entra ID (Azure AD) and on-premises Active Directory. You are using Microsoft Defender for Identity (MDI) integrated with Microsoft Defender XDR. An incident is raised indicating that a user account has been compromised because of an anomaly in Kerberos protocol activity. The incident severity is High. You need to contain the incident immediately by disabling the user account across both on-premises and cloud. However, you also want to preserve the account for forensic analysis. What is the recommended course of action?

A.Delete the user account from Microsoft Entra ID and on-premises AD immediately.

B.Reset the user's password in Microsoft Entra ID and force a password change at next logon on-premises.

C.Enable conditional access policy to require MFA for the user and revoke all refresh tokens.

D.From Microsoft Defender XDR incident, use the action to disable the user account in Microsoft Entra ID and also disable the on-premises account using a playbook that runs a PowerShell script.

AnswerD

Disabling the account in Microsoft Entra ID blocks cloud sign-in, while a playbook running PowerShell disables the on-premises Active Directory account, containing the Kerberos-based compromise across both environments. Disabling rather than deleting preserves the account for forensic analysis.

Why this answer

Microsoft Defender XDR provides a built-in action to disable a user account in Microsoft Entra ID directly from the incident. For on-premises AD, a playbook with a PowerShell script can disable the account, preserving it for forensic analysis. This approach contains the incident across both environments without deleting the account.

Exam trap

SC-200 often tests the need to disable accounts in both cloud and on-premises environments while preserving them for forensics, and candidates may choose password reset or deletion instead.

How to eliminate wrong answers

Option A is wrong because deleting the account destroys forensic evidence and is not recommended for containment. Option B is wrong because resetting the password does not disable the account and may not stop active Kerberos attacks. Option C is wrong because conditional access and token revocation do not disable the on-premises account, leaving it vulnerable.

Full explanation →

536

MCQmedium

You are investigating a potential ransomware incident in Microsoft Defender XDR. The incident has a high severity alert indicating that a user installed a suspicious application. Which initial response action should you take to contain the threat while preserving evidence?

A.Isolate the device using Microsoft Defender for Endpoint.

B.Reset the user's password and enforce MFA.

C.Uninstall the suspicious application via Intune.

D.Disable the user account in Microsoft Entra ID.

AnswerA

Isolating the device via Microsoft Defender for Endpoint severs network communication while retaining the machine's live state, memory and forensic artefacts. This contains the ransomware's spread and preserves evidence, satisfying the requirement to contain the threat without destroying data needed for investigation.

Why this answer

Isolating the device using Microsoft Defender for Endpoint immediately stops lateral movement and data exfiltration while preserving forensic data. Option B is wrong because resetting the password and enforcing MFA does not contain the threat on the device itself. Option C is wrong because uninstalling the suspicious application may remove evidence needed for investigation.

Option D is wrong because disabling the user account does not stop malware already running on the device.

Full explanation →

537

MCQhard

Your organization uses Microsoft Sentinel and Microsoft Defender for Cloud. You receive an alert from Defender for Cloud that a virtual machine has a high severity vulnerability: 'CVE-2023-XXXX' with a CVSS score of 9.8. The virtual machine is running a critical application for the finance department. You need to remediate the vulnerability as quickly as possible while minimizing downtime. The application vendor has not yet released a patch but has provided a workaround. What should you do?

A.Dismiss the alert as a false positive because no patch is available.

B.Shut down the virtual machine until a patch is available.

C.Implement the workaround provided by the vendor and create a custom remediation task in Defender for Cloud to track the issue.

D.Apply a network security group to block all inbound traffic to the VM.

AnswerC

Applying the vendor workaround mitigates the CVSS 9.8 exposure immediately without downtime, since no patch exists, and the custom remediation task tracks the risk until a permanent fix arrives. This satisfies the stem's requirement to remediate quickly while minimising downtime.

Why this answer

When no vendor patch exists but a workaround is available, applying the workaround immediately mitigates the risk while a custom remediation task in Defender for Cloud tracks the issue until a permanent patch arrives. This balances urgency (CVSS 9.8 is critical) with the business need to keep the finance application running.

Exam trap

SC-200 often tests whether candidates choose the most extreme action (shutdown, full network block) instead of the proportionate, tracked mitigation that keeps the business running.

How to eliminate wrong answers

Option A is wrong because dismissing a confirmed high-severity CVE as a false positive ignores a real, exploitable vulnerability and violates incident response best practice. Option B is wrong because shutting down a critical finance VM causes unacceptable downtime when a vendor workaround exists. Option D is wrong because blocking all inbound traffic with an NSG is a blunt instrument that would break legitimate application access, not a targeted remediation.

Full explanation →

538

MCQeasy

In Microsoft 365 Defender, what is the primary function of the Action center?

A.Manage user roles and permissions for the security portal.

B.View and manage pending and completed remediation actions from automated investigations.

C.Create custom detection rules using advanced hunting queries.

D.Manage threat intelligence feeds and indicators.

AnswerB

The Action center in Microsoft 365 Defender consolidates all remediation actions generated by automated investigations, showing them in Pending and History tabs. For pending actions, analysts can approve or reject them — for example, quarantining a suspicious file, blocking a malicious URL, or isolating an endpoint. Completed actions remain in the history view for audit and verification, giving security teams a centralized way to track and control the response outcomes of Defender's automated investigation engine. This is its primary, and defining, function.

Why this answer

The Action center in Microsoft 365 Defender is the centralized console for tracking and managing remediation actions generated by automated investigations. It consolidates both pending actions (requiring approval) and completed actions (e.g., quarantining a file, blocking an IP) across Defender for Endpoint, Office 365, Identity, and Cloud Apps, ensuring security teams can review and approve or reject responses without switching contexts.

Exam trap

The trap here is that candidates confuse the Action center with the 'Hunting' or 'Indicators' sections, mistakenly thinking it is for creating custom rules or managing threat intelligence, when its sole purpose is remediation action tracking and approval from automated investigations.

How to eliminate wrong answers

Option A is wrong because managing user roles and permissions is handled via Azure AD roles and the Microsoft 365 Defender portal's permissions settings, not the Action center. Option C is wrong because creating custom detection rules using advanced hunting queries is done through the 'Custom detection rules' section under 'Hunting', not the Action center. Option D is wrong because managing threat intelligence feeds and indicators is performed in the 'Indicators' settings under 'Settings > Endpoints' or via the Microsoft Defender Threat Intelligence portal, not the Action center.

Full explanation →

539

MCQhard

Refer to the exhibit. You are investigating incidents related to suspicious process injection. The KQL query above is run in Microsoft Sentinel. What is the purpose of this query?

A.To find alerts that occurred within a specific time range

B.To list all alerts of type 'Suspicious process injection' in the last 7 days

C.To get a count of 'Suspicious process injection' alerts grouped by compromised entity and severity, sorted by count

D.To identify the compromised entities with the highest severity alerts

AnswerC

The query first filters to only alerts where the title equals 'Suspicious process injection', then uses `summarize count() by CompromisedEntity, Severity` to compute how many alerts fall into each entity/severity bucket. Finally, it orders the aggregated results by the count in descending order, so the highest-frequency entity/severity combinations appear first. This exactly matches the stated purpose.

Why this answer

The query uses `summarize` with `count()` to aggregate alerts by `CompromisedEntity` and `Severity`, then sorts by the count in descending order. This directly produces a count of 'Suspicious process injection' alerts grouped by compromised entity and severity, sorted by count. The `where` clause filters for the specific alert name, and the time range is implicitly the last 7 days (as shown in the exhibit's query editor).

Exam trap

The trap here is that candidates often confuse 'listing alerts' (Option B) with 'aggregating and counting alerts' (Option C), overlooking the `summarize` and `count()` operators that transform the output from individual records to grouped counts.

How to eliminate wrong answers

Option A is wrong because the query does not filter by a specific time range; it relies on the default time range set in the query editor (last 7 days), but the purpose is not to find alerts within a range but to aggregate and count them. Option B is wrong because the query does not simply list all alerts; it uses `summarize` to group and count them, not to return individual alert records. Option D is wrong because the query groups by both `CompromisedEntity` and `Severity` and sorts by count, not by severity; it does not identify entities with the highest severity alerts—it identifies those with the highest count of alerts, regardless of severity.

Full explanation →

540

Multi-Selecthard

Your organization uses Microsoft Defender XDR. A security incident involving a compromised user account has been identified. Which THREE actions should you take to contain and remediate the incident?

Select 3 answers

A.Disable the user account in Microsoft Entra ID.

B.Reset the user's password.

C.Block all IP addresses that the user has connected from.

D.Revoke all active sessions and tokens for the user.

E.Restore the user's mailbox from a backup.

AnswersA, B, D

Disabling the user account in Microsoft Entra ID is the most effective first containment step because it immediately blocks all authentication attempts, including the attacker's stolen credentials, and prevents access to all Microsoft 365 and cloud resources that depend on Entra ID. Even if the attacker holds a valid session token, disabling the account stops new sign-ins and is a strong, reversible measure that preserves the user profile and forensic data for investigation. In Microsoft Defender XDR incident response, this is the recommended manual action to halt attacker activity without deleting any evidence.

Why this answer

Disabling the user account in Microsoft Entra ID is a critical containment step because it immediately prevents the compromised account from authenticating to any Microsoft cloud services, including Exchange Online, SharePoint, and Teams. This action blocks further unauthorized access at the identity level, which is the foundation of the attack vector in a user account compromise. It is a direct and effective way to stop the attacker from using the account for lateral movement or data exfiltration.

Exam trap

The trap here is that candidates may think blocking IP addresses (Option C) is a valid containment action, but in Microsoft Defender XDR incidents, IP-based blocking is unreliable due to dynamic IPs and attacker evasion techniques, and the focus should be on identity-level controls like disabling the account and revoking tokens.

Full explanation →

541

Multi-Selecthard

Which THREE techniques are effective for hunting for living-off-the-land (LotL) attacks using Microsoft Sentinel?

Select 3 answers

A.Monitoring for installation of third-party software on endpoints.

B.Hunting for WMI activity using Event ID 5861 and correlating with process creation events.

C.Tracking non-interactive logon sessions (Logon Type 5).

D.Analyzing PowerShell script block logs (Event ID 4104) for encoded commands or unusual parameters.

E.Correlating remote service creation events (Event ID 7045) with network connections from administrative tools.

AnswersB, D, E

Event ID 5861 in the Microsoft-Windows-WMI-Activity/Operational log records the registration or modification of a permanent WMI event subscription, including the originating ProcessID and the consumer/filter details. Attackers commonly use WMI as a LotL lateral movement technique, so correlating this event with Windows process creation (Event ID 4688) reveals the exact command line, such as wmic.exe or PowerShell, that created the subscription. Without that correlation, 5861 can be mistaken for legitimate administrative tooling.

Why this answer

Option B is correct because WMI is a native Windows administration mechanism frequently abused for LotL execution and persistence, and Event ID 5861 (WMI permanent event subscription creation in the WMI-Activity operational log) combined with process creation telemetry (e.g., Event ID 4688/Sysmon Event ID 1) exposes malicious subscription-based persistence and spawned processes. Option D is correct because PowerShell script block logging (Event ID 4104) captures de-obfuscated script content, making it effective for detecting encoded commands (-EncodedCommand), download cradles, and unusual parameters typical of LotL tradecraft. Option E is correct because correlating service installation (System log Event ID 7045) with subsequent network connections from administrative tools such as PsExec, sc.exe, or SMB/RPC traffic reveals lateral movement and remote execution that rely on built-in utilities.

Option A does not belong because installing third-party software is not living-off-the-land activity, which by definition uses pre-installed, signed system binaries. Option C does not belong because Logon Type 5 is a service logon, and while service accounts can be abused, tracking non-interactive service logons alone is not a specific or effective LotL hunting technique compared with the correlated event-based methods above.

Exam trap

SC-200 often tests the confusion between general security monitoring and specific LotL hunting techniques, leading candidates to select generic activities like software installation or logon type tracking.

Full explanation →

542

Multi-Selectmedium

Which TWO capabilities are provided by Microsoft Copilot for Security within the Microsoft Sentinel experience?

Select 2 answers

A.Suggest KQL queries based on a description of what you want to detect.

B.Deploy a new workbook template from a description.

C.Modify an existing playbook by adding steps through natural language.

D.Generate a natural language summary of an incident.

E.Automatically create an automation rule based on a chat prompt.

AnswersA, D

Microsoft Copilot leverages generative AI to translate natural-language descriptions of detection intent into ready-to-run Kusto Query Language (KQL) statements for Advanced Hunting. This capability covers both Defender XDR and Sentinel's Log Analytics schema, allowing analysts to describe behaviors like 'show processes spawning PowerShell from Office apps' and receive schema-aware query syntax. Copilot can also iteratively refine these queries based on feedback, reducing syntax errors and accelerating detection authoring.

Why this answer

Microsoft Copilot for Security in Microsoft Sentinel can generate KQL queries from natural language descriptions, allowing analysts to quickly create detection rules without manually writing KQL syntax. This capability leverages AI to interpret the analyst's intent and produce a query that matches the described detection logic.

Exam trap

The trap here is that candidates may assume Copilot can automate operational tasks like deploying templates or modifying playbooks, but its capabilities are limited to generating KQL queries and summarizing incidents, not performing infrastructure changes.

Full explanation →

543

MCQhard

You are a Security Operations Analyst investigating a potential insider threat. A user's account was flagged for downloading a large number of files from SharePoint Online. You need to review the user's activity and determine if the behavior is malicious. You have Microsoft Defender for Cloud Apps and Microsoft Sentinel configured. Which Microsoft Sentinel data source should you query to analyze the user's file download activities in SharePoint?

A.AuditLogs table

B.OfficeActivity table

C.CloudAppEvents table

D.SigninLogs table

AnswerB

The OfficeActivity table in Microsoft Sentinel contains audit logs from Microsoft 365, including SharePoint Online and OneDrive for Business. It records events such as FileDownloaded, FileAccessed, and FileUploaded, along with user and file details. Querying this table allows you to analyze the user's file download activities and assess the volume and sensitivity of the files involved.

Why this answer

The OfficeActivity table is the correct data source for SharePoint Online file download activities. It captures detailed audit events such as FileDownloaded, including user, file name, and client IP, enabling you to assess the scale and nature of the downloads and determine if the behavior is suspicious.

Exam trap

The trap here is assuming that CloudAppEvents or AuditLogs contain SharePoint file download details, when in fact OfficeActivity is the dedicated table for Microsoft 365 audit events including SharePoint.

Full explanation →

544

MCQmedium

Your organization uses Microsoft Sentinel. A security analyst reports that an incident was automatically closed without investigation. You need to identify why the incident was closed automatically. Which Sentinel feature should you review?

A.Analytics rules

B.Automation rules

C.Playbooks

D.Workbooks

E.Watchlists

AnswerB

Automation rules are Sentinel's native, rule-based engine for incident lifecycle automation, evaluated when an incident is created or updated. They support one or more conditions (e.g., severity, title, entity) and multiple actions, including setting the incident status to 'Resolved/Closed' and specifying a closure classification and comment. Because they are first-class components that directly execute incident-state changes without external dependencies, they are the definitive mechanism for automatically closing incidents.

Why this answer

Automation rules in Microsoft Sentinel allow you to define automated responses to incidents, including automatically closing them based on specific conditions (e.g., severity, title, or entity). If an incident was closed without investigation, an automation rule likely triggered a closure action, such as setting the status to 'Closed' with a specific classification. Reviewing the automation rules list and their trigger conditions will reveal which rule caused the automatic closure.

Exam trap

The trap here is that candidates often confuse automation rules with playbooks, thinking playbooks directly close incidents, but in Sentinel, playbooks are only triggered by automation rules and the closure action is defined in the automation rule itself, not in the playbook.

How to eliminate wrong answers

Option A is wrong because analytics rules generate alerts and incidents based on data queries, but they do not directly close incidents; they only create or suppress them. Option C is wrong because playbooks are workflows triggered by automation rules or analytics rules to perform complex actions (e.g., sending emails), but they are not the configuration that directly closes incidents—automation rules invoke playbooks, but the closure action is defined in the automation rule itself. Option D is wrong because workbooks are visualization dashboards for data analysis and do not perform any automated incident management actions.

Option E is wrong because watchlists are collections of data (e.g., IP addresses) used for correlation or filtering in analytics rules, not for automating incident closure.

Full explanation →

545

MCQmedium

Your organization uses Microsoft Defender for Cloud to assess the security posture of Azure subscriptions. You receive an alert that a critical vulnerability exists on a virtual machine. What is the BEST immediate action to validate the alert and contain the threat?

A.Contact Microsoft support to request a vulnerability assessment.

B.Immediately apply the latest security patches to the VM using Azure Update Manager.

C.Isolate the VM from the network by applying a network security group rule.

D.Review the alert details in Microsoft Defender for Cloud to identify the vulnerability and follow the remediation steps.

AnswerD

Reviewing the alert details in Microsoft Defender for Cloud confirms the specific vulnerability and affected resource, then applying the documented remediation steps contains the threat. This validates before acting, satisfying the requirement for the best immediate action rather than unverified escalation or disabling the virtual machine.

Why this answer

The best immediate action is to review the alert details in Microsoft Defender for Cloud because it provides the specific vulnerability, affected resource, and recommended remediation steps. This validation step ensures you understand the threat before taking containment actions, which is critical for an effective and proportionate response. Defender for Cloud's alerts include contextual information such as severity, MITRE tactics, and remediation guidance, enabling informed decision-making.

Exam trap

SC-200 often tests the importance of validating alerts before taking action, as candidates may rush to containment or remediation without first reviewing the alert details, leading to unnecessary disruptions or ineffective responses.

How to eliminate wrong answers

Option A is wrong because Microsoft support does not perform vulnerability assessments on demand; Defender for Cloud already provides this capability. Option B is wrong because applying patches immediately without validating the alert could disrupt operations and may not address the specific vulnerability if the alert is a false positive. Option C is wrong because isolating the VM via NSG is a containment action that should be taken after validating the alert; doing so immediately could cause unnecessary downtime and may not be the appropriate response for a vulnerability that might not be actively exploited.

Full explanation →

546

MCQmedium

Your SOC is investigating an incident in Microsoft Sentinel. You need to quickly identify all related alerts and entities across the timeline. What Microsoft Sentinel feature should you use?

A.Run a hunting query.

B.Open the incident investigation graph.

C.Review the analytics rule that generated the incident.

D.Use the Incident workbook.

AnswerB

The investigation graph visually maps alerts, entities and their relationships across the incident timeline, letting analysts pivot through connected evidence. Logs queries and workbooks show data but lack this interactive entity-relationship exploration, so the graph directly satisfies the need to identify all related alerts and entities.

Why this answer

The incident investigation graph in Microsoft Sentinel provides a visual, interactive map of all alerts, entities (such as users, IP addresses, hosts), and their relationships linked to a specific incident. This allows SOC analysts to quickly see the full scope of an incident across the timeline without manually correlating data, making it the correct tool for this scenario.

Exam trap

The trap here is that candidates may confuse the incident investigation graph with the Incident workbook, assuming both provide incident details, but the workbook is for aggregated reporting while the graph is for interactive, entity-level exploration of a single incident.

How to eliminate wrong answers

Option A is wrong because hunting queries are proactive searches for potential threats across raw data, not designed to retroactively consolidate all alerts and entities for a single incident. Option C is wrong because reviewing the analytics rule only shows the rule's configuration and logic, not the aggregated alerts and entities tied to the incident. Option D is wrong because the Incident workbook provides summary metrics and trends across incidents, not a focused, interactive graph of a single incident's related alerts and entities.

Full explanation →

547

Multi-Selecthard

Your organization uses Microsoft Sentinel with UEBA enabled. You need to investigate a potential insider threat where a user is accessing sensitive data outside of business hours. Which three built-in UEBA entities should you review?

Select 3 answers

A.Azure subscription

B.User account

C.Device

D.IP address

E.Resource group

AnswersB, C, D

The user account is the central entity type in UEBA because it has a distinct identity that can be associated with authentication events, directory actions, and application usage. Sentinel's UEBA profiles the user by aggregating raw activities from sources like Microsoft Entra ID sign-in logs, Office 365 audit logs, and Windows security events, then computes a baseline to identify anomalies such as impossible travel or privileged-account misuse. Without a user entity, behavioral analytics like 'user from new country' or 'user added to privileged group' would have no subject to attach to.

Why this answer

User account (B) is correct because UEBA in Microsoft Sentinel profiles user behavior to detect anomalies such as accessing sensitive data outside business hours. The user account entity is the primary identity used to correlate activities, logon events, and data access patterns, enabling the detection of insider threats based on deviations from established baselines.

Exam trap

The SC-200 exam often tests the distinction between Azure resource management constructs (subscriptions, resource groups) and actual security entities that UEBA monitors, leading candidates to select options that sound related but are not part of the UEBA entity schema.

Full explanation →

548

MCQhard

Your organization has Microsoft Sentinel deployed across multiple workspaces for different business units. The security team wants to view a unified incident queue across all workspaces. What should you implement?

A.Create cross-workspace queries and use the incident view with workspace references

B.Use Microsoft Defender XDR portal to view all incidents

C.Use Azure Lighthouse to manage multiple workspaces

D.Configure a single workspace to receive all incidents

AnswerA

Microsoft Sentinel supports cross-workspace analytics rules that use the workspace() KQL expression to query data from multiple workspaces in a single detection rule. In the incidents blade, you can add workspace references to display and triage incidents from all connected workspaces in one queue, without duplicating data. This preserves data residency and access control while giving security analysts a unified incident management experience across the entire organization.

Why this answer

Microsoft Sentinel supports cross-workspace incident viewing through the use of workspace references in queries and the unified incident view. By configuring cross-workspace queries and enabling the incident view with workspace references, the security team can aggregate and display incidents from multiple Sentinel workspaces in a single queue, providing a unified view without moving data.

Exam trap

The trap here is that candidates often confuse Azure Lighthouse (which enables cross-workspace management but not a unified incident queue) with the native cross-workspace query and incident view capabilities in Sentinel, leading them to choose option C instead of A.

How to eliminate wrong answers

Option B is wrong because Microsoft Defender XDR portal is designed for Microsoft 365 Defender incidents and alerts, not for aggregating Sentinel incidents from multiple workspaces; it does not natively display Sentinel incidents. Option C is wrong because Azure Lighthouse provides delegated resource management across tenants, but it does not natively create a unified incident queue within Sentinel; it allows managing multiple workspaces but each workspace's incidents remain separate unless cross-workspace views are explicitly configured. Option D is wrong because configuring a single workspace to receive all incidents would require ingesting all logs into one workspace, which defeats the purpose of having separate workspaces for different business units and may cause data sovereignty, cost, and performance issues.

Full explanation →

549

MCQeasy

Your SOC uses Microsoft Defender for Cloud Apps. An alert indicates that a user is downloading a large number of files from SharePoint. Which action should you take to investigate and potentially block the activity?

A.Create a Conditional Access policy to block the user

B.Block the IP address in Azure Firewall

C.Use Microsoft Intune to wipe the user's device

D.Suspend the user in Defender for Cloud Apps

AnswerD

Suspending the user in Defender for Cloud Apps is the correct immediate governance action because it directly targets the user account, revoking active sessions, invalidating access tokens, and blocking future sign-ins to connected cloud apps. This identity-level action is precise, affecting only the suspicious account without impacting other users who might share an IP address, and it stops the ongoing activity in real time. Defender for Cloud Apps can apply this action via the underlying app's API, ensuring that the suspension propagates across all managed cloud services as a consistent and immediate containment measure.

Why this answer

In Microsoft Defender for Cloud Apps, suspending a user is a direct response action that blocks the user from accessing cloud apps and can be used during investigation of suspicious activity like mass file downloads. This is the native remediation action within the CASB solution, allowing the SOC to contain the threat without disabling the identity across all of Azure AD.

Exam trap

SC-200 often tests the difference between native Defender for Cloud Apps remediation actions (suspend user) and broader identity controls (Conditional Access), so candidates may overreach with Azure AD tools.

How to eliminate wrong answers

Option A is wrong because Conditional Access policies are configured in Azure AD/Entra ID and are broader identity controls, not the immediate investigative action within Defender for Cloud Apps for this alert. Option B is wrong because blocking an IP in Azure Firewall does not address a user-based cloud app activity and may not stop the user from other networks. Option C is wrong because wiping a device via Intune is a drastic endpoint action unrelated to cloud file downloads and would not directly stop the cloud app activity.

Full explanation →

550

MCQeasy

A security analyst needs to connect a Palo Alto Networks firewall to Microsoft Sentinel to ingest logs. The firewall supports Syslog and Common Event Format (CEF). Which data connector should the analyst use?

A.Palo Alto Networks (via Syslog CEF)

B.Common Event Format (CEF) via Syslog (generic)

C.Syslog (without CEF)

D.Custom Text Logs

AnswerA

The Palo Alto Networks (via Syslog CEF) connector is the vendor-specific data connector in Microsoft Sentinel that ingests Palo Alto firewall logs formatted as Common Event Format (CEF) over Syslog. It automatically applies the Sentinel CEF parser to map fields into the CommonSecurityLog schema, preserving predefined field mappings, timestamp normalization, and severity enrichment without requiring custom KQL. Because Palo Alto is a validated CEF device, using its dedicated connector is the supported, out-of-the-box path that ensures analytics rules and UEBA features work immediately.

Why this answer

The Palo Alto Networks firewall supports sending logs in Common Event Format (CEF) over Syslog, and Microsoft Sentinel provides a dedicated data connector specifically for Palo Alto Networks (via Syslog CEF). This connector parses the CEF-formatted syslog messages using a Log Analytics agent or AMA, normalizing fields into the CommonSecurityLog table for seamless ingestion. Using the vendor-specific connector ensures proper field mapping and schema alignment, unlike a generic CEF connector which may not handle Palo Alto's specific CEF extensions correctly.

Exam trap

Microsoft often tests the distinction between vendor-specific connectors and generic connectors, trapping candidates who assume any CEF-capable device can use the generic CEF connector without considering the need for vendor-specific field mappings and schema compatibility.

How to eliminate wrong answers

Option B is wrong because the generic 'Common Event Format (CEF) via Syslog' connector is intended for any CEF-capable device but lacks the vendor-specific parsing and field mappings that the dedicated Palo Alto Networks connector provides, potentially leading to missing or misaligned data. Option C is wrong because 'Syslog (without CEF)' ingests raw syslog messages without structured CEF fields, requiring custom parsing and losing the normalized CommonSecurityLog schema that CEF provides. Option D is wrong because 'Custom Text Logs' is used for log files in custom formats (e.g., JSON, CSV) and does not support syslog or CEF parsing, making it unsuitable for Palo Alto firewall logs sent via syslog.

Full explanation →

551

MCQhard

Refer to the exhibit. A security administrator runs this PowerShell script. What is the effect?

A.It creates an automation rule that runs a playbook on medium severity incidents

B.It creates a playbook that runs daily for high severity incidents

C.It schedules a daily report generation for all incidents

D.It creates a playbook named 'DailySummaryReport'

AnswerA

This is correct because the PowerShell cmdlet New-AzSentinelAutomationRule creates an automation rule, not a playbook. The rule's trigger condition is set to IncidentSeverity equals Medium at incident creation, and its configured action invokes a Logic Apps playbook. So the script's effect is to run that playbook whenever a medium-severity incident is created.

Why this answer

The PowerShell script uses the `New-AzSentinelAutomationRule` cmdlet to create an automation rule in Microsoft Sentinel. The `-TriggerType` parameter is set to `IncidentCreated`, and the `-Action` parameter specifies a playbook to run. The `-TriggeringLogic` parameter filters for incidents with a severity of `Medium`, so the automation rule triggers the playbook only when a medium-severity incident is created.

Exam trap

The trap here is that candidates confuse creating an automation rule with creating a playbook, or assume the script schedules a recurring task because of the 'DailySummaryReport' name, when in fact the script only links an existing playbook to a trigger condition.

How to eliminate wrong answers

Option B is wrong because the script creates an automation rule triggered by incident creation, not a scheduled playbook; there is no recurrence or daily schedule defined. Option C is wrong because the script does not generate any report or schedule a report generation; it only associates a playbook with incident creation. Option D is wrong because the script creates an automation rule, not a playbook; the playbook named 'DailySummaryReport' is referenced as an action, but the script itself does not create the playbook.

Full explanation →

552

MCQeasy

As part of a threat hunt, you want to find instances where a user successfully authenticated to multiple applications within a short time using different IP addresses. Which Microsoft 365 Defender data source would be most appropriate?

A.CloudAppEvents

B.DeviceLogonEvents

C.IdentityLogonEvents

D.AlertInfo

AnswerC

IdentityLogonEvents is the correct table because it is specifically designed to capture authentication events to applications using Microsoft Entra ID (Azure AD). Each row represents a user authentication attempt to a cloud app, with details such as the target application, logon type, protocol, and whether the attempt succeeded or failed. This directly matches the requirement to find instances of authentication to a cloud application, making it the authoritative source for this hunt.

Why this answer

IdentityLogonEvents contains authentication events for cloud apps, with columns like Application, IP address, and Timestamp.

Full explanation →

553

MCQhard

Your organization uses Microsoft Sentinel and Microsoft Defender for Identity. An alert fires for a potential DCSync attack. The incident response team needs to immediately block the source account from performing directory replication. Which action should be taken?

A.Use Microsoft Defender for Identity to disable the account.

B.Reset the account password and enforce a sign-out.

C.Disable the account in Microsoft Entra ID (if synced) or Active Directory.

D.Remove the account from the Domain Admins group.

AnswerC

Disabling the account in Microsoft Entra ID (for cloud-only accounts) or Active Directory (for on-premises or hybrid accounts) is the definitive containment step. For a hybrid environment, you should disable the account on-premises first, as Azure AD Connect will synchronize the disabled state to Entra ID; for a cloud-only account, you can disable sign-in in Entra ID. This immediately prevents any new authentication attempts, including Kerberos, NTLM, or interactive logon, and blocks DCSync because the account can no longer request a TGT or authorize replication. This is the only option that fully neutralizes the compromised account.

Why this answer

Immediately disabling the account in Microsoft Entra ID (if synced) or Active Directory is the fastest way to stop the compromised account from performing any directory replication, including DCSync attacks. DCSync abuses the domain controller's replication protocol (MS-DRSR) to request password hashes, and disabling the account blocks all Kerberos and NTLM authentication, effectively halting the attack at the source.

Exam trap

The trap here is that candidates often assume resetting the password is sufficient to stop an attack, but they overlook that cached Kerberos tickets or active replication sessions can persist, making immediate account disablement the only surefire way to block DCSync in real time.

How to eliminate wrong answers

Option A is wrong because Microsoft Defender for Identity does not have a built-in capability to disable an account; it can only trigger alerts or suggest remediation actions, but the actual disable must be performed in Active Directory or Entra ID. Option B is wrong because resetting the password and enforcing sign-out does not immediately stop an ongoing DCSync attack—the account may still have cached Kerberos tickets or active sessions that allow replication until they expire. Option D is wrong because removing the account from Domain Admins does not prevent it from performing DCSync if it still has the 'Replicate Directory Changes' permission assigned via other group memberships or direct delegation.

Full explanation →

554

MCQmedium

Refer to the exhibit. You are analyzing high severity alerts from Microsoft Defender for Endpoint in Microsoft Sentinel. What does this KQL query do?

A.It counts alerts for a specific alert name

B.It displays detailed properties of each alert

C.It lists high severity Defender for Endpoint alerts, grouped by name and day, ordered by frequency

D.It shows all alerts from Defender for Endpoint in the last week

AnswerC

This option correctly describes the query: it filters SecurityAlert for ProviderName == "Microsoft Defender for Endpoint" and Severity == "High", then performs `summarize Count = count() by AlertName, bin(TimeGenerated, 1d)` to group alerts by name and day. Finally, it orders the results by Count descending, which ranks the alert names by frequency. The output is a summary list, not individual alerts, matching the exact behavior of a KQL aggregation query.

Why this answer

The KQL query uses `summarize` with `count()` to group alerts by `AlertName` and `startofday(TimeGenerated)`, then sorts by `count_` descending. This directly produces a list of high severity Defender for Endpoint alerts grouped by name and day, ordered by frequency, matching option C.

Exam trap

Microsoft often tests the distinction between summarizing aggregated data (counts) versus displaying raw event details, so candidates mistakenly choose 'displays detailed properties' when the query uses `summarize` and `count()`.

How to eliminate wrong answers

Option A is wrong because the query groups by alert name and day, not filtering to a single specific alert name. Option B is wrong because the query uses `summarize` to aggregate counts, not `project` or `extend` to display detailed properties of each alert. Option D is wrong because the query filters for `TimeGenerated > ago(7d)` but also filters by `AlertSeverity == 'High'` and groups results, not showing all alerts from the last week.

Full explanation →

555

MCQmedium

A SOC analyst needs to create an automation rule that triggers only when an incident contains a specific custom tag (e.g., 'PII'). Which condition should the analyst use to filter incidents based on the presence of that tag?

A.Incident tag contains

B.Incident severity

C.Alert product name

D.Entity type

AnswerA

The 'Incident tag contains' condition triggers when an incident has a specific custom tag, such as 'VIP' or 'Phishing Campaign', assigned to it. This allows the automation rule to apply targeted actions, like creating a ticket or notifying a team, only for incidents that carry that business or classification label. Unlike severity or source filters, this directly evaluates the tag metadata on the incident.

Why this answer

Microsoft Sentinel automation rules use the 'Incident tag contains' condition to filter incidents based on the presence of specific custom tags. When an incident is enriched with a tag like 'PII' via analytics rules or playbooks, this condition allows the automation rule to match and trigger actions only on incidents carrying that exact tag, ensuring precise targeting without affecting unrelated incidents.

Exam trap

The trap here is that candidates confuse incident-level tags with alert-level properties or entity attributes, mistakenly thinking 'Alert product name' or 'Entity type' can filter by custom tags, when in fact only the 'Incident tag contains' condition directly evaluates tags assigned to the incident.

How to eliminate wrong answers

Option B is wrong because 'Incident severity' filters incidents by their severity level (e.g., High, Medium, Low), not by custom tags, so it cannot detect the presence of a specific tag like 'PII'. Option C is wrong because 'Alert product name' filters based on the source product of the alert (e.g., Microsoft Defender for Endpoint, Azure Identity Protection), which is unrelated to custom tags assigned to incidents. Option D is wrong because 'Entity type' filters incidents based on the type of entity involved (e.g., IP address, host, user), not on incident-level custom tags.

Full explanation →

556

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 in Microsoft Sentinel trigger on incident creation and can set the owner field, routing critical alerts to the correct SOC tier. This satisfies the requirement for automatic assignment without manual triage, since analytics rules alone cannot assign owners.

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 →

557

Multi-Selecteasy

A security analyst detects a suspicious login from an unusual location for a user in Microsoft Defender XDR. The analyst needs to investigate and contain the incident. Which TWO actions should be taken?

Select 2 answers

A.Disable the user account from Microsoft Entra ID.

B.Create a custom hunting query in Microsoft 365 Defender advanced hunting.

C.Review the user's sign-in logs and risk level in Microsoft Entra ID Identity Protection.

D.Run an automated investigation playbook.

E.Reset the user's password.

AnswersA, C

Disabling the account in Microsoft Entra ID immediately blocks further authentication and token issuance for the compromised identity, containing the incident while investigation continues. This directly satisfies the stem's requirement to contain a suspicious sign-in from an unusual location.

Why this answer

Option A is correct because disabling the user account in Microsoft Entra ID immediately blocks the compromised identity from authenticating, which is the fastest containment action to stop further unauthorized access during a suspicious-login incident. Option C is correct because reviewing the user's sign-in logs and Identity Protection risk level in Microsoft Entra ID provides the investigative context — source IP, location, device, and whether the sign-in was flagged as risky — needed to confirm compromise before or alongside containment. Option B is not the right primary action because advanced hunting is a proactive threat-hunting tool, not the standard investigative/containment step for a specific flagged sign-in.

Option D is not appropriate here because automated investigation playbooks are triggered by specific alerts or incidents and are not the analyst's direct manual containment action. Option E is not the best choice because a password reset alone does not immediately terminate active sessions or block the account, so it is weaker containment than disabling the account.

Exam trap

The trap is choosing password reset as containment — candidates assume resetting credentials stops the attacker, but without disabling the account or revoking sessions, an attacker with a valid token or persistence mechanism retains access.

Full explanation →

558

MCQeasy

You are threat hunting for signs of credential dumping via LSASS access. Which Advanced Hunting schema table in Microsoft Defender XDR should you primarily query to find processes that opened a handle to LSASS?

A.DeviceProcessEvents

B.DeviceEvents

C.DeviceNetworkEvents

D.DeviceRegistryEvents

AnswerB

DeviceEvents is the correct table because it stores security-sensitive behavioral events, and specifically the ActionType 'LsassAccessedByProcess' is emitted when a process attempts to open the LSASS process handle with credential-theft access rights such as PROCESS_VM_READ or PROCESS_ALL_ACCESS. This event directly indicates a potential credential-dumping attempt, making it the definitive data source for this hunt. Other tables may show supporting artifacts, but only DeviceEvents captures the actual LSASS access.

Why this answer

DeviceEvents is the correct table because it captures a broad set of endpoint telemetry including process access events, which is where LSASS handle-opening activity is recorded. When a tool like Mimikatz or a credential-dumping utility opens a handle to lsass.exe with read access, that action surfaces in DeviceEvents with ActionType values such as 'ProcessAccess' and fields identifying the source and target processes. DeviceProcessEvents only records process creation, so it would not show the handle open itself.

Exam trap

SC-200 often tests the distinction between DeviceProcessEvents (process creation) and DeviceEvents (broader telemetry including ProcessAccess) — candidates who assume 'process' events cover LSASS access pick the wrong table.

How to eliminate wrong answers

Option A is wrong because DeviceProcessEvents records process creation and termination events (e.g., a new process starting), not the act of one process opening a handle to another — so it would miss the LSASS access itself. Option C is wrong because DeviceNetworkEvents captures network connections and DNS activity, which is unrelated to local handle operations on LSASS. Option D is wrong because DeviceRegistryEvents records registry key and value modifications, not process memory access or handle operations.

Full explanation →

559

Multi-Selectmedium

Which THREE data sources in Microsoft Sentinel are most useful for threat hunting activities related to identity compromise?

Select 3 answers

A.SecurityEvent

B.SigninLogs

C.CommonSecurityLog

D.AuditLogs

E.OfficeActivity

AnswersA, B, D

SecurityEvent is a core Windows event log source in Sentinel, capturing event IDs such as 4624 (successful logon), 4625 (failed logon), 4672 (special privileges), and 4720 (user account created). Because it includes logon types and account logon details, it directly supports detection of brute-force attacks, pass-the-hash, and lateral movement across managed endpoints. Without this table, identity-focused hunts would lack the fine-grained audit trails of OS-level authentication and authorization.

Why this answer

SecurityEvent (A) is correct because it captures Windows Security event log data such as 4624/4625 logons, 4672 special privileges, and 4720/4728 account and group changes, which are essential for detecting credential theft, lateral movement, and privilege escalation tied to identity compromise. SigninLogs (B) is correct because it holds Microsoft Entra ID sign-in telemetry including result type, conditional access status, risk detections, IP/location, and MFA details, directly exposing brute-force, password spray, impossible travel, and token replay activity. AuditLogs (D) is correct because it records Entra ID directory changes such as role assignments, consent grants, credential additions, and user/group modifications that attackers use to persist or escalate after compromising an identity.

CommonSecurityLog (C) is not among the correct answers because it carries third-party CEF/Syslog data (firewalls, proxies, IDS) rather than native identity authentication events. OfficeActivity (E) is not among the correct answers because it reflects Microsoft 365 workload operations (SharePoint, Exchange, Teams) and, while useful for post-compromise activity, is less directly focused on identity compromise than the authentication and directory sources.

Exam trap

SC-200 often tests the distinction between identity-focused logs (SigninLogs, AuditLogs) and network/device logs (CommonSecurityLog), causing candidates to overlook AuditLogs for identity compromise.

Full explanation →

560

MCQmedium

A SOC analyst wants to ensure that multiple alerts from the same analytics rule that occur within a 1-hour window for the same user are automatically merged into a single incident. Which configuration setting should the analyst adjust in the analytics rule?

A.Incident grouping settings

B.Entity mapping

C.Alert details

D.Query scheduling

AnswerA

Incident grouping settings directly control whether and how multiple alerts are consolidated into a single incident. In an analytics rule's Incident creation section, you can enable alert grouping and specify a time window (up to 24 hours) as well as select entity types or alert attributes to match on. By adjusting these settings—for instance, grouping by user or host—the SOC analyst ensures that alerts from the same entity or timeframe automatically roll up into one incident rather than generating separate ones.

Why this answer

The Incident grouping settings in a Microsoft Sentinel analytics rule control whether multiple alerts from the same rule are automatically merged into a single incident. By configuring the grouping to 'Group alerts into a single incident if they match the specified conditions' and setting the time window to 1 hour, the SOC analyst ensures that alerts triggered for the same user within that window are combined, reducing alert noise and improving incident management efficiency.

Exam trap

The trap here is that candidates often confuse Entity mapping with incident grouping, thinking that mapping entities automatically merges alerts, but entity mapping only enriches alerts with contextual data and does not control grouping logic.

How to eliminate wrong answers

Option B is wrong because Entity mapping defines how entities (e.g., user accounts, IP addresses) are extracted from raw log data and linked to alerts, but it does not control alert grouping or incident creation logic. Option C is wrong because Alert details allow customization of the alert's name, description, and severity, but they have no role in merging multiple alerts into a single incident. Option D is wrong because Query scheduling sets the frequency and lookback period for running the analytics rule's query, not the grouping of resulting alerts into incidents.

Full explanation →

561

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 →

562

Drag & Dropmedium

Order the steps to create a Microsoft Sentinel automation rule that automatically closes low-severity incidents.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Automation rules are created in the Automation blade, conditions define when to trigger, and actions define what to do.

Full explanation →

563

MCQeasy

Your organization uses Microsoft Sentinel to manage security incidents. The security team wants to automatically assign incidents to the appropriate analyst based on the incident’s severity and category. Which feature should you configure?

A.Automation rules

B.Analytics rules

C.Playbooks

D.Watchlists

AnswerA

Automation rules are the native Sentinel capability that can automatically assign incidents to an owner or team based on incident conditions like severity, product name, or entity. When an incident is created or updated, the rule evaluates its criteria and directly sets the 'Owner' field, enabling immediate triage and workload routing without requiring external logic. This is the correct answer because assignment is a first-class automation action, not a side effect of detection or a separate workflow.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically assign incidents to specific analysts or teams based on conditions such as severity and category. This is the correct feature because it provides a rule-based engine that triggers on incident creation or update, enabling automatic assignment without manual intervention.

Exam trap

The trap here is that candidates often confuse playbooks (which can also assign incidents via Logic Apps) with automation rules, but automation rules are the simpler, native feature for direct assignment without needing to build a custom workflow.

How to eliminate wrong answers

Option B is wrong because analytics rules are used to generate alerts from data sources (e.g., detecting suspicious activity via KQL queries), not to assign incidents to analysts. Option C is wrong because playbooks are automated workflows (often using Azure Logic Apps) that respond to incidents or alerts (e.g., sending emails or blocking IPs), but they are not designed for initial assignment based on severity/category; assignment is a native automation rule action. Option D is wrong because watchlists are collections of data (e.g., known malicious IPs) used for correlation or enrichment in analytics rules, not for incident assignment.

Full explanation →

564

MCQmedium

Your company uses Microsoft Sentinel and has a workspace in the East US region. You need to ingest logs from a non-Azure Windows server located in a branch office in Europe. You have limited bandwidth and need to ensure that log ingestion does not impact network performance. What should you use?

A.Use Microsoft Defender for Endpoint to collect logs from the server and forward them to Sentinel.

B.Install the Log Analytics agent (MMA) on the server and configure it to send logs directly to the workspace.

C.Install the Azure Monitor Agent on the server and create a data collection rule to filter and compress logs before sending.

D.Configure the server to send logs to an Azure Event Hub, then stream to Sentinel.

AnswerC

The Azure Monitor Agent (AMA) is the current, cross-platform agent that supports configurable data collection rules (DCRs) for filtering, transforming, and enriching logs before they leave the server. DCR transformations, written in KQL, can discard unnecessary events, and the AMA uses an optimized protocol with built-in compression to minimize bandwidth usage. This approach directly meets the requirement to reduce the volume of data sent to Sentinel while ensuring only relevant logs are ingested.

Why this answer

The Azure Monitor Agent (AMA) supports data collection rules (DCRs) that can filter logs at the source and compress data before transmission, reducing bandwidth usage. This is critical for the limited bandwidth scenario, and AMA is the modern replacement for the Log Analytics agent, designed for efficient log ingestion across regions.

Exam trap

The trap here is that candidates often assume MMA is still the default for on-premises servers, but Microsoft has deprecated MMA in favor of AMA, and AMA’s DCR-based filtering and compression directly address bandwidth constraints, which MMA cannot do natively.

How to eliminate wrong answers

Option A is wrong because Microsoft Defender for Endpoint collects security telemetry (e.g., alerts, EDR signals) but does not natively forward arbitrary Windows event logs or custom logs to Sentinel; it requires additional configuration and does not address bandwidth optimization. Option B is wrong because the Log Analytics agent (MMA) sends logs without built-in compression or filtering at the source, leading to higher bandwidth consumption, and it is deprecated in favor of AMA. Option D is wrong because sending logs to an Azure Event Hub introduces additional network hops and potential latency, and while Event Hubs can handle high throughput, they do not inherently compress or filter logs to reduce bandwidth impact; this approach is typically used for high-volume streaming, not bandwidth-constrained scenarios.

Full explanation →

565

MCQeasy

You are configuring Microsoft Sentinel to ingest syslog data from a network appliance. After configuring the data connector, you notice that no data is appearing in the CommonSecurityLog table. The syslog server is sending data to the Azure Monitor Agent (AMA) on the log collector. What should you verify first?

A.Check the Heartbeat table for the log collector.

B.Verify that a Data Collection Rule is defined to collect the syslog facilities.

C.Ensure the syslog appliance can reach the collector on UDP port 514.

D.Check the data connector health status in Sentinel.

AnswerB

In Microsoft Sentinel with the Azure Monitor Agent, syslog ingestion is driven entirely by a Data Collection Rule (DCR) that explicitly lists which facilities (e.g., auth, cron, daemon) and severity levels to collect. Without such a DCR, the agent runs but the local syslog daemon has no instructions to forward any events to the Log Analytics workspace. You must verify that the DCR exists, is associated with the target VM, and includes the required facilities; simply enabling the Sentinel data connector will not create the rule automatically.

Why this answer

The Azure Monitor Agent (AMA) requires a Data Collection Rule (DCR) to specify which syslog facilities and severity levels to collect. Without a DCR, the AMA will not forward syslog data to the CommonSecurityLog table, even if the syslog server is sending data to the collector. This is the most common missing configuration step after setting up the data connector.

Exam trap

The trap here is that candidates assume the data connector automatically creates the necessary Data Collection Rule, when in fact the DCR must be manually configured or verified after connector setup.

How to eliminate wrong answers

Option A is wrong because the Heartbeat table shows agent connectivity, not whether syslog data is being collected or forwarded to the correct table; a healthy heartbeat does not guarantee DCR configuration. Option C is wrong because the question states the syslog server is already sending data to the AMA, so network connectivity on UDP 514 is already established. Option D is wrong because the data connector health status in Sentinel checks the connector's overall configuration and permissions, not the specific DCR mapping of syslog facilities to the CommonSecurityLog table.

Full explanation →

566

MCQmedium

Your organization uses Microsoft Defender for Cloud to monitor hybrid workloads. You need to ensure that security alerts from on-premises servers are sent to Microsoft Sentinel. What should you configure?

A.Install a third-party SIEM connector on the servers and forward logs to Sentinel.

B.Deploy Azure Policy on the servers to audit security settings.

C.Connect the on-premises servers to Azure Arc and deploy the Log Analytics agent.

D.Configure a site-to-site VPN to Azure and enable network logging.

AnswerC

Connecting the on-premises servers to Azure Arc creates an Azure resource that supports a consistent management plane and enables you to install the Log Analytics agent (or Azure Monitor Agent) through Azure. The agent collects Windows/Linux security events and sends them to a Log Analytics workspace, which Microsoft Sentinel uses as its data source. This is the native, recommended architecture for migrating on-premises log collection to Sentinel.

Why this answer

Azure Arc enables on-premises servers to be managed as Azure resources, allowing the Log Analytics agent to be deployed and configured to forward security alerts to a Log Analytics workspace integrated with Microsoft Sentinel. This is the standard method for ingesting security events from hybrid workloads into Sentinel without requiring third-party connectors or complex network configurations.

Exam trap

The trap here is that candidates may mistakenly think a VPN or third-party connector is required for on-premises data ingestion, overlooking Azure Arc's ability to bridge on-premises servers into Azure management plane and enable agent-based log collection directly to Sentinel.

How to eliminate wrong answers

Option A is wrong because installing a third-party SIEM connector on the servers is unnecessary and introduces additional complexity; Microsoft Sentinel natively supports the Log Analytics agent for collecting security events from Windows and Linux servers, and third-party connectors are typically used for external SIEMs like Splunk or QRadar, not for direct ingestion into Sentinel. Option B is wrong because Azure Policy is a governance tool for auditing and enforcing compliance rules on Azure resources, not a mechanism for forwarding security alerts to Sentinel; it cannot send log data or alerts to a Log Analytics workspace. Option D is wrong because a site-to-site VPN provides network connectivity but does not forward security alerts or logs to Sentinel; network logging would require additional configuration and does not address the requirement of sending security alerts from on-premises servers to Sentinel.

Full explanation →

567

MCQmedium

Refer to the exhibit. You run this KQL query in Microsoft Defender XDR to detect suspicious PowerShell activity. Why might this query generate many false positives?

A.The time range is too broad.

B.The query is too specific and misses many attacks.

C.Legitimate administrators often use encoded PowerShell commands.

D.The query does not filter by user.

AnswerC

Encoded PowerShell is a legitimate administrative technique, so a detection rule flagging encoded commands matches benign activity and inflates false positives. The query's logic keys on encoding itself, which is not inherently malicious, satisfying the stem's constraint that the rule triggers on common legitimate behaviour.

Why this answer

Legitimate administrators often use encoded PowerShell commands, which would match this query and generate false positives. Option A is wrong because the time range shown in the exhibit (e.g., 7 days) is not excessively broad for hunting. Option B is wrong because the query is specific to encoded commands, but it does not miss attacks; it targets a specific technique.

Option D is wrong because, while filtering by user could reduce noise, the main reason for false positives is that encoded commands are used legitimately, not because of the absence of user filtering.

Full explanation →

568

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 in Microsoft Sentinel can add a task to an incident, letting the SOC track required follow-up actions; rules also support assignment, tagging, status changes and running playbooks, but task creation is a native incident action.

Why this answer

Option A is correct because Microsoft Sentinel automation rules support the "Create task" action, which adds a task to an incident for analyst follow-up. Option B is correct because automation rules can trigger a playbook (Logic App) to run against an incident, which is one of their primary purposes. Option C is not correct because incident creation is handled by analytics rules, not automation rules.

Option D is not correct because automation rules cannot create other automation rules. Option E is not correct because sending an email is done by a playbook, not directly by an automation rule action.

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 →

569

MCQhard

Refer to the exhibit. You have an automation rule defined as shown. The rule is enabled but never triggers. What is the most likely reason?

A.The playbook resource ID is incomplete.

B.The condition requires incident status 'Active', but incidents start as 'New'.

C.The trigger type should be 'AlertCreated' instead of 'IncidentCreated'.

D.The rule order is set to 1, which is too low.

AnswerB

When Microsoft Sentinel creates an incident, its Status property is always set to 'New' by default, regardless of the severity or entity classification. The automation rule's condition requires Status to equal 'Active', which is a later state an incident enters only after manual triage or another automation rule changes it. Because the trigger fires at incident creation—before any status transition—the condition evaluates to false and the rule does not execute. This is the definitive cause of the problem.

Why this answer

The automation rule triggers on incident creation, but the condition requires the incident status to be 'Active'. In Microsoft Sentinel, incidents are created with a status of 'New', not 'Active'. Therefore, the condition is never met, and the rule never triggers.

To fix this, the condition should either be removed or changed to include 'New' status.

Exam trap

Microsoft often tests the subtle difference between incident status values ('New' vs 'Active') and the fact that incidents are created as 'New', not 'Active', causing candidates to overlook the condition mismatch.

How to eliminate wrong answers

Option A is wrong because the playbook resource ID is used to identify the playbook to run, and an incomplete ID would cause a different error (e.g., playbook not found), not prevent the rule from triggering entirely. Option C is wrong because the trigger type 'IncidentCreated' is correct for an automation rule that runs when an incident is created; 'AlertCreated' would be used for alert-based automation, not incident-based. Option D is wrong because the rule order (priority) determines the sequence of rule execution but does not prevent a rule from triggering; a low order number simply means it runs earlier among enabled rules.

Full explanation →

570

MCQhard

Your organization has deployed Microsoft Sentinel with the Microsoft Defender XDR connector. A high-severity incident is created for a user who received a phishing email that contained a malicious link. The user clicked the link, and the attacker gained access to the user's mailbox. The security team needs to remove the attacker's access and prevent future occurrences. What should you do first?

A.Run a full antivirus scan on the user's device

B.Reset the user's password immediately

C.Report the incident to Microsoft for further investigation

D.Remove any mailbox forwarding rules and delegated access

AnswerD

Attackers persist by creating hidden inbox forwarding rules and granting delegated mailbox access, so removing these first severs the attacker's ongoing access to the compromised mailbox. Containment precedes broader remediation such as password resets or investigation, satisfying the requirement to remove access immediately.

Why this answer

The first step should be to remove any mailbox forwarding rules and delegated access because attackers often set up persistence mechanisms to maintain access even after password resets. Removing these ensures the attacker cannot continue to receive emails or access the mailbox. This is a critical containment step before other remediation actions.

Exam trap

SC-200 often tests the order of incident response actions; the trap is focusing on password reset or antivirus scans while missing the attacker's persistence mechanisms like forwarding rules.

How to eliminate wrong answers

Option A is wrong because a full antivirus scan on the user's device addresses malware but does not remove attacker access from the mailbox, which is the immediate concern. Option B is wrong because resetting the password alone may not remove forwarding rules or delegated access, allowing the attacker to persist. Option C is wrong because reporting to Microsoft is not the first step; containment and remediation should be prioritized.

Full explanation →

571

MCQmedium

Your security team uses Microsoft Defender XDR. You need to ensure that a user who is suspected of credential theft is immediately blocked from accessing corporate email and cloud apps, while the investigation continues. What should you do?

A.Create a conditional access policy in Microsoft Entra ID to block the user

B.Use Microsoft Defender for Cloud Apps to suspend the user

C.Disable the user account in Microsoft Entra ID

D.Reset the user's password from Microsoft Entra ID

AnswerB

Suspending the user in Microsoft Defender for Cloud Apps is the correct immediate response because it sends a governance action through the connected app connectors to invalidate the user’s active sessions and tokens for all connected cloud apps. This terminates ongoing access in near-real time, making it effective for containing an active compromise rather than waiting for sign-in-time controls to take effect.

Why this answer

Suspending the user in Microsoft Defender for Cloud Apps immediately revokes the user's access tokens and active sessions for cloud apps, blocking further access to corporate email and cloud apps without deleting the account. This allows the investigation to continue while the user is isolated, which is the precise requirement for a suspected credential theft scenario.

Exam trap

The trap here is that candidates often confuse 'blocking access' with 'disabling the account' or 'resetting the password,' not realizing that immediate token revocation via Defender for Cloud Apps is the only option that stops active sessions without disrupting the user's directory object.

How to eliminate wrong answers

Option A is wrong because creating a conditional access policy in Microsoft Entra ID requires time to propagate and may not immediately revoke existing sessions; it also does not suspend the user's tokens for already-authenticated sessions. Option C is wrong because disabling the user account in Microsoft Entra ID removes the user from all directory services and can break dependencies like group memberships or licensing, and it does not specifically target cloud app access while preserving the account for investigation. Option D is wrong because resetting the user's password does not invalidate existing active sessions or tokens issued before the reset, so the user could still access email and cloud apps until those tokens expire.

Full explanation →

572

MCQmedium

A SOC analyst needs to create a Microsoft Sentinel scheduled analytics rule that detects a potential brute-force attack. The rule should alert when a single IP address attempts to sign in to more than 10 different user accounts within 5 minutes. The data is in the 'SigninLogs' table. Which KQL operator should the analyst use to count distinct users per IP address per 5-minute time window?

A.summarize dcount(UserPrincipalName) by IPAddress, bin(TimeGenerated, 5m)

B.summarize count(UserPrincipalName) by IPAddress

C.summarize dcount(IPAddress) by UserPrincipalName, bin(TimeGenerated, 5m)

D.make-set(UserPrincipalName) by IPAddress

AnswerA

This is correct because dcount(UserPrincipalName) computes a distinct count of user accounts, which directly answers how many different users attempted sign-ins. Grouping by IPAddress and bin(TimeGenerated, 5m) segments the data into fixed 5-minute windows per source IP, allowing the rule to detect sudden spikes in unique accounts from a single IP—a classic brute-force or password-spray signature. The bin function ensures temporal alignment across events, so aggregation is performed over consistent time slices rather than ad-hoc intervals.

Why this answer

The requirement is to count distinct user accounts per IP address within a 5-minute window. The `dcount()` function estimates the number of distinct values of `UserPrincipalName`, `bin(TimeGenerated, 5m)` groups the logs into 5-minute buckets, and `summarize ... by IPAddress` ensures the count is per source IP. This directly matches the brute-force detection logic of more than 10 distinct users from a single IP in 5 minutes.

Exam trap

The trap here is confusing `count()` (total events) with `dcount()` (distinct values), leading candidates to pick Option B, which would count repeated attempts to the same user as separate events and miss the distinct-user threshold required for a brute-force detection.

How to eliminate wrong answers

Option B is wrong because `count(UserPrincipalName)` counts all sign-in attempts, including duplicates, not distinct users, which would inflate the count and cause false positives. Option C is wrong because it counts distinct IP addresses per user, which is the inverse of the required logic and would detect a single user being targeted from many IPs, not a brute-force from one IP. Option D is wrong because `make-set()` creates an array of distinct values but does not provide a count; the analyst would need to further process the set to get the number of distinct users, making it inefficient and not directly usable in a rule condition.

Full explanation →

573

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 →

574

Multi-Selectmedium

You are managing Microsoft Defender for Endpoint. Which TWO actions can be taken directly from the Microsoft 365 Defender portal to respond to a compromised device?

Select 2 answers

A.Run a full antivirus scan on the device.

B.Block the user's sign-in from Microsoft Entra ID.

C.Remotely wipe the device.

D.Isolate the device from the network.

E.Reset the device's local administrator password.

AnswersA, D

Running a full antivirus scan is a supported response action in Microsoft Defender for Endpoint. It invokes Microsoft Defender Antivirus to scan the entire device for malware, including persistent threats that may survive a quick scan, and automatically remediates detected threats. This action is initiated from the device's page in the Microsoft 365 Defender portal.

Why this answer

The Microsoft 365 Defender portal allows security operators to initiate a full antivirus scan on a compromised device directly from the device's action menu. This leverages Microsoft Defender Antivirus to detect and remediate threats without requiring local user interaction, providing an immediate response capability within the unified security operations interface.

Exam trap

The trap here is that candidates confuse identity-based remediation (like blocking sign-in) with endpoint-based remediation, assuming all security actions are available from the same portal, when in fact Microsoft 365 Defender focuses on device-level responses while identity actions remain in Microsoft Entra ID.

Full explanation →

575

MCQmedium

A security team wants to enable advanced threat detection for all Azure SQL databases across multiple subscriptions. They want to receive alerts for SQL injection attempts and anomalous activities. Which action should they take in Microsoft Defender for Cloud?

A.Enable the Microsoft Defender for Servers plan on each subscription.

B.Enable the Microsoft Defender for SQL plan at the subscription level.

C.Configure SQL Auditing and Threat Detection on each SQL server individually.

D.Create an Azure Policy to deploy Azure SQL Firewall rules.

AnswerB

Microsoft Defender for SQL is the correct security plan to enable at the subscription level, as it automatically protects all Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse SQL pools within that subscription. It delivers advanced threat protection that continuously monitors database activity, detects SQL injection attempts, suspicious access patterns, and brute-force attacks, and provides actionable security alerts directly in Defender for Cloud. One subscription-level enablement applies the protection to every existing and future database, eliminating the need for per-server configuration.

Why this answer

Microsoft Defender for SQL provides advanced threat detection for Azure SQL databases, including alerts for SQL injection attempts and anomalous activities. Enabling the plan at the subscription level automatically protects all existing and future SQL databases within that subscription, ensuring centralized management and compliance.

Exam trap

The trap here is that candidates often confuse the need for per-server configuration (Option C) with the centralized subscription-level enablement, or they mistakenly think that server-level security controls like firewalls (Option D) or server-specific plans (Option A) can provide the same threat detection capabilities.

How to eliminate wrong answers

Option A is wrong because Microsoft Defender for Servers is designed to protect virtual machines and servers, not Azure SQL databases; it does not include SQL-specific threat detection capabilities. Option C is wrong because configuring SQL Auditing and Threat Detection on each SQL server individually is a legacy, manual approach that lacks the centralized policy enforcement and advanced analytics provided by Microsoft Defender for SQL at the subscription level. Option D is wrong because creating an Azure Policy to deploy Azure SQL Firewall rules only manages network access controls and does not enable threat detection or alerting for SQL injection or anomalous activities.

Full explanation →

576

MCQhard

You are managing a Microsoft Sentinel workspace that ingests data from Microsoft 365 Defender. You notice that some incident creation rules are not generating incidents as expected. What should you check first?

A.The Microsoft 365 Defender data connector

B.The workspace daily usage cap

C.The SecurityIncident table schema

D.The analytics rule status

AnswerA

The Microsoft 365 Defender data connector is the ingestion pipeline that pulls incidents generated within M365 Defender into Sentinel's SecurityIncident table. When this connector is disabled or misconfigured, incident records never reach the workspace, even if analytics rules are enabled and querying correctly. Therefore, this is the first thing to verify because without successful connector synchronization, no incidents can appear.

Why this answer

The Microsoft 365 Defender data connector is the correct first check because it is the ingestion pipeline for security alerts from Microsoft 365 Defender into Microsoft Sentinel. If this connector is misconfigured, disconnected, or has stopped syncing, incident creation rules that depend on these alerts will not trigger, even if the analytics rules themselves are enabled and correctly configured.

Exam trap

The trap here is that candidates often jump to checking analytics rule status first, assuming the rule is disabled or misconfigured, but the real issue is that the data connector—the upstream dependency—is broken, preventing the rule from ever receiving the alerts it needs to evaluate.

How to eliminate wrong answers

Option B is wrong because the workspace daily usage cap affects data ingestion costs and can stop data ingestion if exceeded, but it would impact all data types, not just incident creation rules from Microsoft 365 Defender; moreover, Sentinel incident creation rules are based on analytics rule logic, not directly on ingestion volume. Option C is wrong because the SecurityIncident table schema is a fixed schema in Log Analytics that stores incidents after they are created; checking the schema would not reveal why incidents are not being generated, as schema changes are rare and would cause errors, not silent failures. Option D is wrong because while analytics rule status (enabled/disabled) is relevant, the question states that incident creation rules are not generating incidents as expected, implying they are enabled; the root cause is more likely a data connector issue that prevents the required alerts from being ingested.

Full explanation →

577

MCQhard

An analyst is using advanced hunting in Microsoft 365 Defender. A device made outbound RDP connections shortly after a suspicious PowerShell process started. Which join is most useful to identify the initiating process for those network connections?

A.Join EmailEvents with UrlClickEvents

B.Join IdentityInfo with SecureScoreControls

C.Join CloudAppEvents with AlertEvidence only

D.Join DeviceNetworkEvents with DeviceProcessEvents by device and process identifiers/time window

AnswerD

DeviceNetworkEvents records outbound and inbound network connections, including InitiatingProcessId and InitiatingProcessFileName, while DeviceProcessEvents captures process creation with ProcessId, ParentProcessId, CreationTime, and command-line arguments. Joining these tables on DeviceId and ProcessId/InitiatingProcessId, with a time window aligned to the process creation timestamp, maps the RDP network connection to the exact process (e.g., mstsc.exe) and its parent, enabling full attribution of the RDP session.

Why this answer

It joins DeviceNetworkEvents (which contain outbound RDP connection details) with DeviceProcessEvents (which contain process creation data like the suspicious PowerShell process) using device ID, process ID, and a time window. This join allows the analyst to directly correlate the network connection to the initiating process, identifying whether the PowerShell process spawned the RDP connection.

Exam trap

The trap here is that candidates may choose a join involving cloud or email tables (A, B, C) because they focus on the 'suspicious PowerShell' aspect, forgetting that the question specifically asks for the initiating process of network connections, which requires device-level process and network event correlation.

How to eliminate wrong answers

Option A is wrong because EmailEvents and UrlClickEvents deal with email and URL click data, which are irrelevant to identifying the initiating process of outbound RDP connections from a device. Option B is wrong because IdentityInfo and SecureScoreControls relate to user identity and security posture scores, not process-to-network correlation. Option C is wrong because CloudAppEvents and AlertEvidence focus on cloud application activities and alerts, not device-level process and network events; joining them would not reveal the initiating process for RDP connections on a device.

Full explanation →

578

MCQhard

Your organization uses Microsoft Defender XDR for threat detection and response. The security team wants to automatically isolate a compromised device when a specific malware alert is triggered, but only if the device is not a critical server. What is the most efficient way to achieve this?

A.Use advanced hunting to find devices and then manually isolate

B.Use PowerShell scripts in a playbook

C.Configure an automation rule in Microsoft Defender XDR

D.Create a custom detection rule

AnswerC

Configuring an automation rule in Microsoft Defender XDR is the correct approach because automation rules are native, event-driven response engines that evaluate criteria such as alert title, severity, device group, and incident tags, then automatically perform actions like isolating a device or running an antivirus scan. They are managed centrally, support order of execution for multiple rules, and do not require external services or scripting. This enables an immediate, policy-based containment action precisely when a qualifying alert fires, which is directly aligned with the requirement for automated device isolation.

Why this answer

Automation rules in Microsoft Defender XDR allow you to define conditions (e.g., malware alert triggered) and actions (e.g., isolate device) with scoping filters (e.g., exclude devices tagged as 'critical server'). This provides a no-code, built-in mechanism that runs automatically without manual intervention or external scripting, making it the most efficient approach for conditional automated response.

Exam trap

The trap here is that candidates often confuse automation rules (native to Defender XDR) with playbooks (which require external orchestration like Logic Apps), leading them to choose PowerShell or custom detection rules instead of the simpler built-in automation rule.

How to eliminate wrong answers

Option A is wrong because advanced hunting is a query-based tool for threat investigation, not an automated response mechanism; manually isolating devices after hunting defeats the goal of automatic isolation. Option B is wrong because PowerShell scripts in a playbook require additional infrastructure (e.g., Azure Logic Apps or Microsoft Sentinel) and introduce unnecessary complexity and latency compared to the native automation rule in Defender XDR. Option D is wrong because custom detection rules are used to create custom alerts based on advanced hunting queries, not to define automated response actions like device isolation; they lack the built-in action and scoping capabilities of automation rules.

Full explanation →

579

MCQhard

You are reviewing an analytics rule configuration in Microsoft Sentinel using ARM template JSON. The rule is enabled and incident creation is set to true. However, when alerts are generated, they are not being grouped into a single incident. What is the most likely reason?

A.The lookbackDuration is set to 5 hours which is too short.

B.The groupingConfiguration is disabled.

C.The matchingMethod is set to 'AllEntities' which is not supported.

D.The rule is not enabled properly.

AnswerB

With groupingConfiguration disabled, every alert that the rule generates is immediately converted into its own individual incident. This is exactly why you are seeing separate incidents despite alerts sharing common entities or firing within the same time window. To combine related alerts, grouping must be enabled and configured with a matching method and appropriate lookbackDuration.

Why this answer

The groupingConfiguration in Microsoft Sentinel analytics rules controls whether alerts are grouped into a single incident. When this configuration is disabled, each alert generates its own separate incident, even if the rule is enabled and incident creation is set to true. Therefore, the most likely reason alerts are not being grouped is that the groupingConfiguration is disabled.

Exam trap

The trap here is that candidates often focus on the lookbackDuration or matchingMethod as the cause of grouping failure, overlooking that the groupingConfiguration must be explicitly enabled for any grouping to occur.

How to eliminate wrong answers

Option A is wrong because a short lookbackDuration (e.g., 5 hours) limits the time window for grouping alerts, but it does not prevent grouping entirely; alerts within that window can still be grouped if grouping is enabled. Option C is wrong because 'AllEntities' is a valid matchingMethod in Sentinel's grouping configuration; it matches alerts based on all entity types and is fully supported. Option D is wrong because the rule is explicitly stated to be enabled and incident creation is set to true, so the rule is properly enabled; the issue lies specifically with the grouping configuration.

Full explanation →

580

MCQhard

Refer to the exhibit. You have created an automation rule in Microsoft Sentinel with the above configuration. The playbook isolates the device and disables the user account. After enabling the rule, you notice that a low-severity incident containing an alert titled 'Ransomware Behavior' did NOT trigger the automation. What is the most likely reason?

A.The 'ContainsAny' operator does not match single values

B.The automation rule does not have permission to run the playbook

C.The playbook ID is invalid

D.The incident severity is Low, but the rule only triggers on High severity

AnswerD

The rule's condition filters on High severity, so a Low-severity incident falls outside its trigger scope entirely. Microsoft Sentinel evaluates automation rule conditions against incident properties at creation; severity mismatch prevents any playbook run, regardless of the alert title. Raising the incident's severity or broadening the rule condition would allow execution.

Why this answer

Microsoft Sentinel automation rules have a condition set that includes severity; if the rule is configured to trigger only on High-severity incidents, a Low-severity incident will never fire the rule regardless of the alert title. The exhibit shows the rule's conditions, and the most likely mismatch is the severity filter. The playbook itself is not the issue because the rule simply never evaluated to true for this incident.

Exam trap

The trap is assuming the playbook or operator is at fault when the real issue is a condition mismatch — always check the rule's severity/status filters against the incident that failed to trigger.

How to eliminate wrong answers

Option A is wrong because the `ContainsAny` operator in Sentinel automation conditions is designed to match against a list of values and works fine with single values — it is not the cause of the non-trigger. Option B is wrong because a permissions problem with the playbook would surface as a failed playbook run (visible in the automation rule's run history), not as the rule silently not triggering. Option C is wrong because an invalid playbook ID would typically produce a configuration error or a failed action, not a clean 'rule did not run' outcome; the rule would still fire and then fail at the playbook step.

Full explanation →

581

MCQeasy

A security analyst is hunting for signs of credential dumping using Microsoft Defender for Endpoint. Which advanced hunting query should the analyst use to detect the use of Mimikatz?

A.DeviceRegistryEvents where RegistryKey contains 'mimikatz'

B.DeviceProcessEvents where ProcessCommandLine contains 'mimikatz'

C.DeviceFileEvents where FileName contains 'mimikatz'

D.DeviceNetworkEvents where RemoteIP contains 'mimikatz'

AnswerB

DeviceProcessEvents capture process creation events, including the full command line, which is exactly where Mimikatz's execution appears—for example, 'mimikatz.exe privilege::debug sekurlsa::logonpasswords'. Searching ProcessCommandLine for 'mimikatz' directly detects the tool being run, even if the executable is renamed, as long as the command line includes the name. This is the most dependable hunting query because credential dumping requires process execution, and process creation logs are the primary telemetry for that activity.

Why this answer

Mimikatz is executed as a process, and its invocation (e.g., 'mimikatz.exe', 'Invoke-Mimikatz', or sekurlsa::logonpasswords) appears in the process command line. Microsoft Defender for Endpoint's DeviceProcessEvents table captures ProcessCommandLine, making it the correct table for detecting execution-based credential dumping. This is the standard hunting pattern for tool-name or command-line-based detection.

Exam trap

The trap is that candidates pick the table that sounds most 'security-related' (registry or network) instead of recognizing that tool execution and command-line arguments are always captured in DeviceProcessEvents — the exam tests whether you know which MDE table holds which telemetry type.

How to eliminate wrong answers

Option A is wrong because DeviceRegistryEvents captures registry key modifications, and while Mimikatz can touch registry keys (e.g., WDigest), the tool name itself is not a registry key — this query would return nothing useful. Option C is wrong because DeviceFileEvents tracks file creation/modification, and while mimikatz.exe may exist as a file, hunting by filename alone misses renamed binaries and does not capture the credential-dumping behavior. Option D is wrong because DeviceNetworkEvents records network connections with IP addresses and ports; 'mimikatz' is not an IP address, so this query is syntactically and semantically invalid for the hunt.

Full explanation →

582

MCQhard

A threat hunter wants to proactively identify devices that may have been compromised by a known adversary using DLL side-loading techniques. Which Microsoft Sentinel solution or feature should the hunter leverage to create custom detection rules based on the latest threat intelligence?

A.User and Entity Behavior Analytics (UEBA)

B.Automation rules with playbooks

C.Custom workbooks

D.Threat Intelligence integration with analytics rules

AnswerD

Ingesting threat intelligence indicators into Microsoft Sentinel and mapping them to analytics rules lets hunters build custom detections for DLL side-loading observables, such as malicious file hashes or loaded modules, matching the requirement to use the latest threat intelligence proactively.

Why this answer

Microsoft Sentinel's Threat Intelligence integration allows you to import threat indicators (IOCs) from various sources and use them in analytics rules to detect known adversary techniques like DLL side-loading. By creating custom analytics rules that reference threat intelligence data, the hunter can proactively identify compromised devices based on the latest intel. This directly addresses the requirement to leverage threat intelligence for custom detection.

Exam trap

The trap is assuming that UEBA or automation rules provide threat intelligence-based detection, but only the Threat Intelligence integration with analytics rules enables custom detection using external IOCs.

How to eliminate wrong answers

Option A is wrong because UEBA focuses on behavioral anomalies and does not directly incorporate external threat intelligence feeds for custom detection rules. Option B is wrong because automation rules with playbooks are for orchestrating responses, not for creating detection logic based on threat intelligence. Option C is wrong because custom workbooks are for visualization and reporting, not for generating detection rules.

Full explanation →

583

Drag & Dropmedium

Order the steps to set up a Microsoft Sentinel workspace and connect Microsoft 365 Defender data.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Sentinel is enabled on a Log Analytics workspace, then data connectors like M365 Defender are configured to ingest data.

Full explanation →

584

MCQhard

Your organization uses Microsoft Defender for Endpoint and has enabled the 'Block at First Sight' feature. You notice that some legitimate executables are being blocked incorrectly. You need to temporarily allow these files while you submit them for analysis. What should you do?

A.Create an indicator of compromise (IoC) in Microsoft Defender for Endpoint to allow the file hash.

B.Add an application control policy in Microsoft Intune to allow the files.

C.Submit the files to Microsoft for analysis and wait for the verdict.

D.Disable the 'Block at First Sight' feature until the files are analyzed.

AnswerA

Creating an allow indicator of compromise (IoC) for the file hash in Microsoft Defender for Endpoint is the supported, targeted way to override an automatic block. This action adds an entry to the threat intelligence that the Microsoft Defender for Endpoint sensor enforces; an allow verdict takes precedence over block verdicts for that specific SHA-256 hash, including blocks from the cloud protection service. It applies immediately and leaves protection intact for all other files.

Why this answer

Creating an allow indicator (IoC) in Microsoft Defender for Endpoint explicitly overrides the cloud-based 'Block at First Sight' verdict for a specific file hash. This allows the legitimate executable to run while you submit it for analysis, without disabling the broader protection feature. The allow indicator takes precedence over automated blocking actions, providing a temporary, targeted exemption.

Exam trap

The trap here is that candidates may think disabling the feature entirely (Option D) is a quick fix, but the exam tests the understanding that targeted allow indicators are the correct, least-privilege approach to handle false positives without compromising overall security posture.

How to eliminate wrong answers

Option B is wrong because application control policies in Microsoft Intune (e.g., Windows Defender Application Control) enforce execution rules based on code integrity policies, not file hash overrides for cloud-delivered protection; they cannot bypass the 'Block at First Sight' verdict. Option C is wrong because waiting for Microsoft's analysis without taking immediate action leaves the legitimate executables blocked, disrupting operations; the question explicitly asks for a temporary allow while submitting. Option D is wrong because disabling 'Block at First Sight' removes protection against all unknown files, not just the specific ones, creating a broad security gap; the goal is to allow only the known legitimate files.

Full explanation →

585

MCQhard

Your organization uses Microsoft Sentinel and Microsoft Defender for Cloud. You receive an alert from Defender for Cloud indicating that a virtual machine has a high severity vulnerability (CVE-2023-XXXX). You need to create an incident in Microsoft Sentinel and trigger a playbook to remediate the vulnerability. However, the incident is not being created automatically. What is the most likely cause?

A.The Microsoft Defender for Cloud connector in Microsoft Sentinel is not enabled or misconfigured

B.An analytics rule with a matching severity threshold has not been created

C.The free trial of Microsoft Sentinel has expired

D.The playbook does not have the correct permissions on the target VM

AnswerA

The Microsoft Defender for Cloud connector is the data ingestion pipeline that brings security alerts from Defender for Cloud into Microsoft Sentinel. If this connector is disabled, not connected to the correct subscription, or has misconfigured diagnostic settings, no Defender for Cloud alerts reach the Sentinel workspace, so no incidents can be generated from them. Without this connector enabled, all other components—analytics rules, automation, and playbooks—have no alert data to act upon.

Why this answer

The Microsoft Defender for Cloud connector in Microsoft Sentinel is the bridge that forwards security alerts from Defender for Cloud to Sentinel. If this connector is not enabled or is misconfigured, Defender for Cloud alerts—including vulnerability alerts for VMs—will never reach Sentinel, so no incident can be created automatically. Without the connector, the data source is disconnected, and Sentinel has no trigger to generate an incident or invoke a playbook.

Exam trap

The trap here is that candidates often assume Defender for Cloud alerts automatically create incidents in Sentinel without needing a connector, or they confuse the connector with an analytics rule, thinking a custom rule is required to match severity thresholds.

How to eliminate wrong answers

Option B is wrong because an analytics rule with a matching severity threshold is not required for Defender for Cloud alerts; these alerts are automatically ingested as incidents via the connector, not through custom analytics rules. Option C is wrong because if the Sentinel free trial had expired, the entire Sentinel workspace would be disabled, not just the incident creation for a specific alert; the question states Sentinel is still operational. Option D is wrong because playbook permissions on the target VM are irrelevant to incident creation; they only matter when the playbook attempts to execute remediation actions after the incident is already created.

Full explanation →

586

MCQmedium

Refer to the exhibit. You are reviewing an Azure Resource Manager (ARM) template for a Microsoft Sentinel analytics rule. Based on the exhibit, which statement is true?

A.The rule will create one incident per alert and group alerts by entity.

B.The rule will only trigger if more than 5 users have MFA disabled.

C.The rule runs every hour and looks back 5 hours.

D.The rule will generate one alert per user that has MFA disabled.

AnswerD

This is correct because the analytics rule is configured with 'Alert Per Result,' which instructs Microsoft Sentinel to create an independent alert for every row returned by the query. The query returns one row for each user who has MFA disabled, so each of those users triggers a separate alert. No incident grouping is applied, so each of these alerts is also converted into its own incident.

Why this answer

The ARM template configures a Microsoft Sentinel scheduled analytics rule that runs every hour, queries for users with MFA disabled, and uses the 'Alert Per Result' event grouping setting. This setting generates a separate alert for each unique result returned by the query, meaning each user who has MFA disabled triggers its own alert.

Exam trap

The trap here is that candidates confuse the 'frequency' and 'period' values (both PT5H) with a common 1-hour interval, or misinterpret 'AlertPerResult' as grouping alerts into incidents, when in fact it creates one alert per query result row.

How to eliminate wrong answers

Option A is wrong because the rule uses 'Alert Per Result' event grouping, not 'Group alerts into a single incident per alert'—the setting creates one alert per result, not one incident per alert with entity grouping. Option B is wrong because the query does not include any aggregation or threshold condition like 'count > 5'; it simply lists users with MFA disabled, so the rule triggers for any number of results. Option C is wrong because the rule runs every 5 hours (frequency: PT5H) and looks back 5 hours (period: PT5H), not every hour.

Full explanation →

587

MCQmedium

You are a security analyst at Fabrikam. The company uses Microsoft Defender for Cloud Apps and Microsoft Sentinel. During a threat hunt, you need to identify users who are accessing cloud applications from multiple geographic locations in a short time, which could indicate credential theft or token replay. You want to create a hunting query in Microsoft Sentinel using the CloudAppEvents table. Which approach should you take?

A.Query CommonSecurityLog for VPN connections

B.Query OfficeActivity for sign-in logs

C.Query SecurityAlert for location-related alerts

D.Query CloudAppEvents, summarize by AccountDisplayName and bin(TimeGenerated, 1h), then use dcount(CountryCode) > 1

AnswerD

Summarising CloudAppEvents by AccountDisplayName within one-hour bins and filtering where dcount(CountryCode) exceeds one directly surfaces impossible-travel patterns, satisfying the requirement to detect users accessing cloud apps from multiple geographies in a short window. The CloudAppEvents table supplies the CountryCode and TimeGenerated fields this aggregation depends on.

Why this answer

The CloudAppEvents table in Microsoft Sentinel contains Microsoft Defender for Cloud Apps activity logs, including user sign-ins and access to cloud applications with geographic metadata such as CountryCode. Summarizing by AccountDisplayName and binning TimeGenerated into 1-hour windows, then filtering where dcount(CountryCode) > 1, directly detects the impossible-travel pattern described. This is the canonical KQL approach for multi-geo access hunting in Sentinel.

Exam trap

The trap is that candidates pick OfficeActivity or SecurityAlert because they sound like they contain sign-in or location data, but only CloudAppEvents provides the enriched cloud app access telemetry with CountryCode needed for the multi-geo dcount pattern.

How to eliminate wrong answers

Option A is wrong because CommonSecurityLog contains network security appliance logs (e.g., firewalls, proxies) and does not include cloud app user access events with CountryCode — it would not surface the credential-theft pattern. Option B is wrong because OfficeActivity covers Microsoft 365 audit events but does not include the broader cloud app access telemetry (including non-Microsoft SaaS) that CloudAppEvents provides, and it lacks the same CountryCode enrichment. Option C is wrong because SecurityAlert contains generated alerts, not raw access events, so you cannot reliably hunt for the multi-geo pattern from alerts alone.

Full explanation →

588

Multi-Selectmedium

A SOC analyst is configuring a Microsoft Sentinel automation rule to trigger a playbook when an incident is created. The playbook should only run if the incident severity is 'High' and the incident title contains 'Phishing'. Which two conditions should the analyst add to the automation rule? (Select all that apply.) (Choose 2.)

Select 2 answers

A.Incident severity equals High

B.Incident title contains Phishing

C.Incident status is New

D.Incident owner is Unassigned

AnswersA, B

The condition 'Incident severity equals High' directly implements the SOC's stated requirement to trigger the automation runbook for high-severity incidents. In Microsoft Sentinel, severity is an incident property set during analytics rule detection, and this condition uses the 'equals' operator to match only incidents with the exact severity value 'High'. This ensures the automation workflow engages precisely when the security impact is most significant, without introducing extraneous restrictions.

Why this answer

The automation rule condition 'Incident severity equals High' directly matches the requirement that the playbook should only trigger for incidents with a severity of 'High'. In Microsoft Sentinel, automation rules evaluate conditions against incident properties, and severity is a standard field that can be filtered using the 'equals' operator. This ensures the playbook is not invoked for lower-severity incidents.

Exam trap

The trap here is that candidates may mistakenly add 'Incident status is New' thinking the playbook should only run on newly created incidents, but the automation rule already triggers 'when an incident is created', making the status condition redundant and incorrect for this specific requirement.

Full explanation →

589

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 →

590

MCQeasy

During an incident, an analyst wants to use Microsoft Defender XDR's automatic attack disruption to contain an ongoing attack. What prerequisite must be met?

A.Devices must be onboarded to Microsoft Defender for Endpoint.

B.Microsoft Purview compliance portal must be configured.

C.Users must have Azure AD Premium P2 licenses.

D.Microsoft Sentinel must be enabled and connected to Defender XDR.

AnswerA

Automatic attack disruption in Microsoft Defender XDR executes active containment responses—such as isolating devices or blocking indicators—based on real-time endpoint signals. These signals only exist when devices are onboarded to Microsoft Defender for Endpoint, which deploys the sensor and enables EDR in active mode. Without onboarded endpoints, the service has no telemetry to trigger or apply disruption actions.

Why this answer

Microsoft Defender XDR's automatic attack disruption relies on Microsoft Defender for Endpoint (MDE) signals to automatically contain compromised devices or user accounts. Devices must be onboarded to MDE so that the high-confidence alerts (e.g., from ransomware or lateral movement) can trigger automated containment actions like device isolation or blocking an IP. Without MDE onboarding, the attack disruption engine has no endpoint telemetry or remediation capability to act upon.

Exam trap

The trap here is that candidates often confuse the broader Microsoft security ecosystem (Purview, Sentinel, Azure AD P2) as prerequisites for Defender XDR's automated response, when in fact the core requirement is simply having devices onboarded to Microsoft Defender for Endpoint.

How to eliminate wrong answers

Option B is wrong because Microsoft Purview compliance portal is focused on data governance, eDiscovery, and compliance (e.g., DLP, retention), not on real-time attack disruption or endpoint containment. Option C is wrong because Azure AD Premium P2 licenses are required for Identity Protection and risk-based conditional access, but automatic attack disruption in Defender XDR does not depend on Azure AD P2; it requires MDE licenses (e.g., Microsoft 365 E5 or standalone MDE). Option D is wrong because Microsoft Sentinel is a SIEM/SOAR that can ingest alerts from Defender XDR, but it is not a prerequisite for Defender XDR's own automatic attack disruption; the disruption logic runs natively within Defender XDR using MDE data.

Full explanation →

591

MCQmedium

You are responsible for Microsoft Defender for Identity. The security team reports that some high-confidence alerts are not triggering any automated response. You need to automate the response for these alerts. What should you configure?

A.Use Microsoft Intune to trigger a script on domain controllers when an alert fires.

B.Create an automation rule in Microsoft Sentinel to respond to Identity alerts.

C.In Microsoft Defender XDR, configure automated investigation and response for Identity alerts.

D.Configure Microsoft Purview compliance policies to respond to Identity alerts.

AnswerC

Defender XDR provides automated investigation and response (AIR) for identity alerts generated by Defender for Identity. This feature automatically investigates suspicious identity activity, such as compromised account usage or lateral movement, and can contain or remediate threats by disabling accounts, resetting passwords, or blocking sign-ins. Enabling AIR for identity alerts in the Defender XDR portal ensures that alerts are handled through the security incident lifecycle rather than requiring separate device management or compliance tooling.

Why this answer

Microsoft Defender for Identity alerts are natively integrated into Microsoft Defender XDR (formerly Microsoft 365 Defender), which provides automated investigation and response (AIR) capabilities. By configuring AIR for Identity alerts in Defender XDR, you can automatically trigger remediation actions such as suspending compromised accounts or blocking suspicious activities without additional scripting or third-party tools.

Exam trap

The trap here is that candidates may confuse Microsoft Sentinel (a SIEM/SOAR) with the native automated investigation and response capabilities within Microsoft Defender XDR, assuming that any automation must go through Sentinel, when in fact Defender XDR provides built-in AIR for its own alerts including Identity alerts.

How to eliminate wrong answers

Option A is wrong because Microsoft Intune is a mobile device management (MDM) and mobile application management (MAM) service, not designed to trigger scripts on domain controllers in response to security alerts; it manages endpoints, not on-premises Active Directory infrastructure. Option B is wrong because Microsoft Sentinel is a SIEM/SOAR platform that can ingest alerts from various sources, but it is not the native automation mechanism for Defender for Identity alerts; the correct native automation is within Defender XDR. Option D is wrong because Microsoft Purview compliance policies focus on data governance, eDiscovery, and compliance (e.g., retention labels, DLP), not on automated response to identity-based security alerts.

Full explanation →

592

MCQmedium

Your organization uses Microsoft Defender for Cloud Apps and Microsoft Sentinel. During a threat hunt, you find that a user accessed a sensitive SharePoint site from an anonymous IP address. Which hunting method would best identify all users who accessed the same site from similar anonymous IPs?

A.Query CloudAppEvents in Advanced hunting for the SharePoint site URL and filter by IP category 'AnonymousProxy'

B.Query DeviceEvents for network connections from the anonymous IP

C.Use Microsoft Purview to scan for sensitive data accessed from anonymous IPs

D.Search Azure AD sign-in logs for the same IP

AnswerA

CloudAppEvents holds Microsoft Defender for Cloud Apps activity records, including SharePoint access and the IP category field. Filtering on the site URL and AnonymousProxy identifies every user who reached that site from anonymous IPs, which Sentinel's sign-in tables cannot surface.

Why this answer

Using KQL to query CloudAppEvents for the specific SharePoint site and filtering by IP address categories (e.g., AnonymousProxy) is the most direct method. Option D (Azure AD sign-in logs) may not include SharePoint site-level access. Option B (Microsoft Defender for Endpoint) is for endpoint activities.

Option C (Microsoft Purview) focuses on data classification and governance.

Full explanation →

593

MCQeasy

Your security operations center (SOC) uses Microsoft Sentinel. An incident is created from a fusion alert. What does Fusion technology do?

A.Uses machine learning to detect suspicious user behavior

B.Runs queries at scheduled intervals to detect threats

C.Detects unusual patterns in Azure activity logs

D.Correlates alerts from different products to detect multi-stage attacks

AnswerD

Fusion correlation in Microsoft Sentinel links low-fidelity alerts and anomalies across multiple products into a single incident, identifying multi-stage attack progressions that individual detections miss. This directly satisfies the stem's fusion alert scenario, where the SOC receives one consolidated incident rather than separate, unrelated alerts.

Why this answer

Microsoft Sentinel's Fusion technology is a correlation engine that stitches together low-fidelity alerts and signals from multiple sources (Microsoft and third-party products) into high-fidelity incidents representing multi-stage attacks. It uses machine learning models built on attack kill-chain patterns to detect sequences like a suspicious sign-in followed by anomalous resource creation. This is why Fusion incidents are typically high severity and span multiple products.

Exam trap

The trap is confusing Fusion with UEBA or scheduled analytics rules — Fusion is specifically the cross-product, multi-stage attack correlation engine, not a behaviour-analytics or query-scheduling feature.

How to eliminate wrong answers

Option A is wrong because UEBA (User and Entity Behavior Analytics) is the Sentinel feature that uses machine learning to detect suspicious user behaviour — Fusion is about cross-product correlation, not behavioural baselining. Option B is wrong because scheduled analytics rules run KQL queries at intervals to detect threats; that is the standard analytics rule mechanism, not Fusion. Option C is wrong because detecting unusual patterns in Azure Activity logs is a specific data-source analytics scenario, not the definition of Fusion, which spans many sources and products.

Full explanation →

594

MCQeasy

Your organization uses Microsoft Sentinel with a Log Analytics workspace in the East US region. You need to ensure that incident investigation data is retained for two years for compliance. What should you configure?

A.Adjust the Interactive retention period to 730 days in the Log Analytics workspace.

B.Configure a data retention policy in Microsoft Purview.

C.Set the Total retention period to 730 days and enable Archive.

D.Enable Basic Logs and set retention to 730 days.

AnswerA

To meet a 730-day retention requirement, adjust the Interactive retention period in the Log Analytics workspace to 730 days. The Interactive tier is the default hot storage used by Microsoft Sentinel for running KQL queries, analytics rules, and investigations. Log Analytics lets you set interactive retention to up to 730 days (2 years) without moving data into the Archive tier. Merely setting total retention would not guarantee that data stays in the fully queryable, interactive state for the entire 730-day period.

Why this answer

Log Analytics workspaces allow you to configure the Interactive retention period independently from the Total retention period. Setting Interactive retention to 730 days ensures that incident investigation data remains available for interactive queries for the full two-year compliance requirement, without needing to enable archive or change log types.

Exam trap

The trap here is that candidates often confuse the Interactive retention period with the Total retention period, assuming that setting Total retention to 730 days automatically keeps data interactively available, when in fact only the Interactive retention period controls that access, and archive data requires a search job to query.

How to eliminate wrong answers

Option B is wrong because Microsoft Purview manages data governance, compliance, and sensitivity labels, not the retention of operational data in a Log Analytics workspace used by Microsoft Sentinel. Option C is wrong because setting the Total retention period to 730 days and enabling Archive would move data to the archive tier after the interactive period (default 30 days), making it inaccessible for interactive queries and requiring a search job to retrieve, which does not meet the requirement for incident investigation data to be retained for two years in an accessible state. Option D is wrong because Basic Logs are designed for verbose, low-volume logs with reduced query capabilities and a maximum retention of 30 days; setting retention to 730 days is not supported for Basic Logs.

Full explanation →

595

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(Account) counts distinct account values per grouping, so summarising by IP with a threshold above 10 flags the same source failing against many accounts within the five-minute window. It satisfies the distinct-account counting requirement precisely.

Why this answer

The dcount(Account) operator is correct because it counts the number of distinct values in the Account column, which is exactly what the analyst needs: the number of unique accounts targeted by failed logons from a single IP. The full query would use summarize dcount(Account) by IPAddress and then filter for counts greater than 10 within a 5-minute window. This directly addresses the requirement to count distinct accounts per IP.

Exam trap

SC-200 often tests the difference between count() and dcount() in KQL — candidates confuse counting all rows with counting distinct values, leading to incorrect detection logic.

How to eliminate wrong answers

Option A is wrong because count() counts all rows, not distinct accounts — it would count every failed logon event, including multiple attempts against the same account. Option B is wrong because summarize count() by Account groups by Account and counts events per account, which does not give the number of distinct accounts per IP. Option C is wrong because distinct Account is not a valid KQL operator for aggregation — distinct is used as a tabular operator to return unique rows, not as an aggregation function within summarize.

Full explanation →

596

MCQmedium

A security administrator wants to ensure that all existing and future Azure virtual machines have Microsoft Defender for Cloud's built-in vulnerability assessment solution (Qualys or Microsoft) installed without manual intervention. Which feature should the administrator configure?

A.Continuous export of security findings to Log Analytics

B.Auto-provisioning of the vulnerability assessment solution

C.Just-in-time VM access

D.Regulatory compliance dashboard

AnswerB

Auto-provisioning in Microsoft Defender for Cloud is the correct mechanism because it automatically deploys the vulnerability-assessment solution—the integrated Microsoft Defender Vulnerability Management engine or the Qualys agent—to all existing virtual machines and applies an Azure Policy effect to any future VM at creation time. Once enabled at the subscription or management-group level, it removes the need for manual agent installation, ensures every new instance receives the scanner, and keeps the assessor running through the Azure Monitor Agent or Log Analytics agent as appropriate. This continuous, agent-based coverage is precisely what the requirement 'ensure that all existing and future Azure virtual machines have VA' demands.

Why this answer

Auto-provisioning of the vulnerability assessment solution ensures that Microsoft Defender for Cloud automatically installs either the Qualys or Microsoft built-in vulnerability assessment extension on all existing and future Azure VMs without manual intervention. This feature is specifically designed to enable continuous vulnerability scanning by deploying the agent at scale, covering both new and existing resources as they are provisioned or discovered.

Exam trap

The trap here is that candidates often confuse 'continuous export' (which sends data after the agent is installed) with 'auto-provisioning' (which actually installs the agent), leading them to select Option A thinking it automates the deployment process.

How to eliminate wrong answers

Option A is wrong because continuous export of security findings to Log Analytics is a data export feature that sends vulnerability scan results to a Log Analytics workspace for centralized analysis or integration, but it does not install or deploy the vulnerability assessment solution itself. Option C is wrong because Just-in-time VM access is a network security feature that controls inbound traffic to VMs by opening ports only when needed, and it has no role in deploying vulnerability assessment agents. Option D is wrong because the Regulatory compliance dashboard provides a view of compliance posture against standards like CIS or NIST, but it does not automate the installation of vulnerability assessment software.

Full explanation →

597

MCQmedium

You are a security operations analyst at a company that uses Microsoft Sentinel. You need to create an automation rule that automatically closes incidents with a severity of Informational and a status of New after 24 hours, but only if they do not contain any entities. Which three conditions must you configure in the automation rule?

A.Severity equals Low, Status equals New, and Entities count equals 0.

B.Severity equals Informational, Status equals New, and Entities count equals 0.

C.Severity equals Informational, Status equals New, and Entities count greater than 0.

D.Severity equals Informational, Status equals Active, and Entities count equals 0.

AnswerB

This option correctly identifies the three conditions required: severity equal to Informational, status equal to New, and no entities present. These conditions ensure that only low-priority incidents without entities are automatically closed after the specified time, aligning with the scenario's requirement to reduce noise from such incidents.

Why this answer

The automation rule must target incidents that are Informational severity, have a status of New, and contain no entities. These conditions ensure that only low-risk, unassigned incidents without any associated entities are automatically closed after 24 hours, reducing analyst workload. The other combinations either target incorrect severity, status, or entity presence, failing to meet the scenario's requirements.

Exam trap

The trap here is confusing incident status values or severity levels, such as using Active instead of New or Low instead of Informational, which would misdirect the automation rule.

Full explanation →

598

Multi-Selecthard

A Microsoft Sentinel scheduled analytics rule detects impossible travel but creates too many duplicate incidents for the same user within a short period. Which two rule settings should you tune? (Choose 2.)

Select 2 answers

A.Configure event grouping or incident grouping by user entity.

B.Configure suppression to stop creating new alerts for a defined period after a match.

C.Disable the data connector.

D.Delete the Log Analytics workspace.

AnswersA, B

In the scheduled analytics rule's "Alert grouping" and "Event grouping" settings, you can define that query results containing the same user entity are combined into a single alert, and later that multiple alerts referencing the same user are combined into one incident. This consolidation directly addresses alert fatigue by collapsing many impossible-travel event pairs into one investigation object centered on the affected user. However, you must consider grouping by other entities like location or IP to avoid over-consolidating distinct attacker activities.

Why this answer

Configuring event grouping or incident grouping by user entity consolidates multiple alerts for the same user into a single incident, reducing duplicate incidents. In Microsoft Sentinel, this setting controls how alerts are aggregated into incidents based on entity fields like user account, ensuring that a burst of impossible travel alerts for the same user generates one incident instead of many.

Exam trap

The trap here is that candidates often confuse suppression (which stops alert creation) with incident grouping (which consolidates alerts into incidents), and may incorrectly think disabling the data connector or deleting the workspace are valid tuning actions for reducing duplicates.

Full explanation →

599

Multi-Selecthard

Your organization is implementing Microsoft Sentinel and needs to ensure that incident response activities are compliant with regulatory requirements. You need to track and document all changes made to analytics rules and playbooks. Which TWO features should you enable?

Select 2 answers

A.Sentinel workbooks

B.Automation rules

C.Activity logs (Azure Monitor)

D.Azure Resource Change History (Change tracking)

E.Microsoft Purview Compliance Manager

AnswersC, D

The Azure Activity log is the subscription-level platform log that records administrative operations on Azure resources, including every write (PUT, POST, PATCH) against Sentinel analytics rules, playbooks, and data connectors. Each entry captures the resource ID, the operation name, the initiating principal, and a timestamp, giving you a comprehensive compliance audit trail. To meet compliance requirements, you would enable diagnostic settings to export this log to a Log Analytics workspace for long-term retention and alerting.

Why this answer

Activity logs (Azure Monitor) record all management-plane operations, including changes to analytics rules and playbooks, while Azure Resource Change History (Change tracking) captures resource-level modifications. Together they provide comprehensive audit trails for regulatory compliance. Workbooks (A) are for visualization, Automation rules (B) trigger responses but don't log changes themselves, and Microsoft Purview (E) is for broader data governance, not operational change tracking.

Exam trap

Candidates often confuse automation rules or workbooks as change-tracking tools. Remember that only Azure-native logging services (Activity Logs and Change History) provide the audit trail required for regulatory compliance.

Full explanation →

600

MCQhard

You are configuring Microsoft Sentinel automation rules to handle incidents from multiple analytics rules. You need to ensure that incidents from a specific rule are automatically assigned to the 'SOC Tier 2' group and have a severity of 'High' regardless of the original severity. What should you do?

A.Use a logic app trigger to change severity

B.Create a playbook to modify the incident properties

C.Create a separate analytics rule to override the incident

D.Configure an automation rule with 'Add tag' and 'Set severity' actions, plus 'Assign owner'

AnswerD

Automation rules in Microsoft Sentinel natively support incident property modification through actions like 'Add tag', 'Set severity', and 'Assign owner'. You can configure these rules with conditions scoped to specific analytics rules, yet they run automatically when an incident is generated or updated, so the severity and owner are set at creation time without manual intervention or external tooling. This is the recommended, built-in mechanism for incident property management, and it avoids the complexity of playbooks while also preventing duplicate incidents.

Why this answer

Automation rules in Microsoft Sentinel can directly modify incident properties such as severity and owner without requiring external logic apps or playbooks. Option D correctly uses the 'Set severity' action to override the original severity to 'High' and the 'Assign owner' action to assign the incident to the 'SOC Tier 2' group, fulfilling both requirements in a single, efficient rule.

Exam trap

The trap here is that candidates often confuse automation rules with playbooks, assuming that any property modification requires a playbook, when in fact automation rules natively support 'Set severity' and 'Assign owner' actions for simple, rule-based changes.

How to eliminate wrong answers

Option A is wrong because a logic app trigger is used to initiate automated workflows, but it cannot directly modify incident properties within Sentinel; it would require a playbook to change severity, making this an indirect and unnecessary step. Option B is wrong because a playbook is designed for complex, multi-step automation and is overkill for simple property changes; automation rules are the native, simpler solution for such tasks. Option C is wrong because creating a separate analytics rule to override an incident is not possible; analytics rules generate incidents based on detection logic, not modify existing incidents' properties.

Full explanation →

Microsoft Security Operations Analyst SC-200 (SC-200) — Questions 526–600