CCNA Manage a security operations environment Questions — Page 7 of 7

451

Multi-Selecthard

Your Microsoft Defender XDR environment has an advanced hunting query that returns devices potentially affected by a known vulnerability. You want to create a custom detection rule that triggers an alert when more than 10 devices are affected. Which THREE steps are required?

Select 3 answers

A.Set the rule frequency and threshold to trigger when the query returns more than 10 results.

B.Configure the rule action to generate an alert in Microsoft Defender XDR.

C.Assign the rule to a severity level.

D.Create a Power Automate flow to send an email when the rule triggers.

E.Save the advanced hunting query as a custom detection rule.

AnswersA, B, E

In Microsoft Defender XDR custom detection rules, you must set both the rule frequency (how often the query runs, such as every hour) and the threshold (the number of results that triggers the rule) in the rule's settings. For this scenario, configuring the threshold to fire when the query returns more than 10 results ensures that only significant matches generate alerts, reducing false positives. This step is essential because without a defined frequency and threshold, the rule has no scheduling or triggering condition to act on.

Why this answer

Setting the rule frequency and threshold to trigger when the query returns more than 10 results directly implements the requirement to alert when more than 10 devices are affected. In Microsoft Defender XDR custom detection rules, the threshold condition is configured in the rule settings to evaluate the number of query results against a specified count, enabling precise alert triggering based on result volume.

Exam trap

The trap here is that candidates often confuse optional post-alert actions (like Power Automate flows or severity assignment) with the mandatory steps required to create a functional custom detection rule, leading them to select options C or D instead of focusing on the core rule creation steps (save query, set frequency/threshold, configure alert action).

Practice this question →

452

MCQmedium

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. A security analyst reports that incidents related to ransomware are not being automatically triaged by the SOC automation playbook. You confirm that the playbook is enabled and connected to the analytics rule. What is the most likely cause of the issue?

A.The Microsoft Sentinel workspace is in a different region than Microsoft Defender XDR.

B.The incident is not being created by the analytics rule.

C.The playbook is not associated with the correct analytics rule in the automation rule.

D.The automation rule that triggers the playbook is set to run only when the incident is created by a specific provider (e.g., Microsoft Defender XDR), but the incident is created by Microsoft Sentinel.

AnswerD

If the automation rule includes a condition using the 'Provider' property — such as requiring it to equal 'Microsoft Defender XDR' — then an incident created by a Microsoft Sentinel analytics rule will not match. Analytics rule incidents have their Provider field set to 'Microsoft Sentinel' by default, regardless of the source data source, so the rule's condition evaluates to false and the playbook never triggers. To fix this, remove the provider filter or change it to 'Microsoft Sentinel' (or set it to 'Other' depending on the version), ensuring the automation rule runs for incidents generated by the desired analytics rule.

Why this answer

The automation rule that triggers the playbook is configured with a condition that restricts it to incidents created by a specific provider, such as Microsoft Defender XDR. However, the ransomware incident is being created by Microsoft Sentinel (e.g., via an analytics rule), not by Microsoft Defender XDR. This provider mismatch prevents the automation rule from firing, so the playbook never runs, even though the playbook itself is enabled and connected to the analytics rule.

Exam trap

The trap here is that candidates assume the playbook or analytics rule association is the problem, when in fact the automation rule's provider condition silently filters out the incident, causing the playbook to never trigger despite all other connections being correct.

How to eliminate wrong answers

Option A is wrong because Microsoft Sentinel and Microsoft Defender XDR can be integrated across regions; region mismatch does not prevent automation rules from triggering playbooks. Option B is wrong because the question states that incidents related to ransomware are not being automatically triaged, implying that incidents are indeed being created (the analyst sees them), but the playbook is not running. Option C is wrong because the playbook is confirmed to be enabled and connected to the analytics rule; the issue lies in the automation rule's provider filter, not in the playbook-to-rule association.

Practice this question →

453

MCQhard

Your organization uses Microsoft Defender for Office 365. You need to configure a policy that automatically moves emails detected as 'Bulk' to the user's Junk Email folder. However, users must be able to override this by adding the sender to their Safe Senders list. What should you configure?

A.Anti-spam policy with Bulk email threshold set to a value that triggers junk action

B.Anti-phishing policy

C.Malware filter policy

D.Connection filter policy

AnswerA

This is the correct control because sender complaint data produces a Bulk Complaint Level (BCL) from 0 to 9 for each inbound message, and the anti-spam policy's bulk email threshold routes messages that exceed that BCL to the Junk Email folder. A lower threshold value, such as 6, classifies more senders as bulk and makes the action increasingly aggressive. Safe Senders and Safe Lists can override this action for trusted senders, but no other policy in Microsoft Defender for Office 365 applies BCL thresholds.

Why this answer

The Bulk email threshold setting in an anti-spam policy allows you to specify a Bulk Complaint Level (BCL) value that, when exceeded, triggers a specific action such as moving the email to the Junk Email folder. This action respects the user's Safe Senders list, meaning if the sender is added to that list, the email will bypass the junk folder and be delivered to the inbox. Other policy types like anti-phishing, malware filter, or connection filter do not provide this granular control over bulk email classification and user override behavior.

Exam trap

The trap here is that candidates often confuse anti-spam policies with anti-phishing policies, assuming phishing protection handles bulk email, but only anti-spam policies contain the Bulk email threshold setting that interacts with the user's Safe Senders list.

How to eliminate wrong answers

Option B is wrong because anti-phishing policies are designed to protect against impersonation and phishing attempts, not to handle bulk email classification or junk folder actions based on BCL thresholds. Option C is wrong because malware filter policies focus on detecting and removing malicious attachments or links, not on categorizing or acting on bulk email. Option D is wrong because connection filter policies control email flow based on sender IP reputation (e.g., allow or block lists), not on the content-based bulk email detection or user Safe Senders override.

Practice this question →

454

MCQhard

You are a security administrator for a multinational company using Microsoft Sentinel. You need to ensure that critical incidents are automatically escalated to the on-call team via email and SMS. The on-call schedule uses Microsoft Teams channel. What is the most efficient way to achieve this?

A.Create an automation rule that sends email directly to the on-call team.

B.Build a playbook using Microsoft Teams connector to post a message in the on-call channel with an adaptive card that allows acknowledge and escalate.

C.Configure the analytics rule to send an email when the incident is created.

D.Use a workbook to display critical incidents and expect the team to monitor it.

AnswerB

This is the correct approach because a playbook—built on Azure Logic Apps—can be triggered by an automation rule when an incident is created. The playbook uses the Microsoft Teams connector to post an adaptive card to the on-call channel, and the card's buttons (Acknowledge/Escalate) invoke further logic, such as updating the incident status or notifying a second-tier team. This provides a closed-loop, interactive notification workflow rather than a one-way message.

Why this answer

It uses a Microsoft Teams connector playbook triggered by an automation rule to post an adaptive card in the on-call channel. This allows the on-call team to acknowledge or escalate the incident directly from Teams, fulfilling the requirement for email and SMS escalation through the Teams channel schedule. Automation rules in Sentinel can trigger playbooks based on incident creation or update, making this the most efficient integrated approach.

Exam trap

The trap here is that candidates assume automation rules can natively send emails or SMS, but they can only trigger playbooks or modify incident properties, requiring a Logic App for actual notification delivery.

How to eliminate wrong answers

Option A is wrong because sending email directly via an automation rule does not support SMS or integrate with the Microsoft Teams on-call schedule; automation rules can only trigger playbooks or change incident properties, not send emails natively. Option C is wrong because analytics rules cannot send emails directly; they can only generate alerts or incidents, and email notification would require a separate playbook or logic app. Option D is wrong because a workbook is a passive monitoring tool that requires manual review and does not provide automatic escalation via email or SMS, failing the requirement for automated notification.

Practice this question →

455

Multi-Selecteasy

Which THREE are valid incident classification options in Microsoft Sentinel?

Select 3 answers

A.Informational

B.Benign Positive

C.Malicious

D.False Positive

E.True Positive

AnswersB, D, E

Benign Positive is a valid top-level classification in Microsoft Sentinel for activity that is confirmed to be real and potentially interesting but not malicious. Examples include a security tool triggered by an authorized penetration test, a misconfigured internal application, or a user performing an unusual but permitted action. Analysts select this classification to document harmless-but-noteworthy alerts separately from actual threats and false alarms.

Why this answer

(Benign Positive) is correct because Microsoft Sentinel uses incident classification to categorize the outcome of an investigation. A Benign Positive indicates that an alert is triggered by legitimate activity that is expected or acceptable, such as a security tool scanning the network or a user performing an authorized administrative task. This classification helps analysts distinguish between true threats and harmless events without marking them as false positives.

Exam trap

The trap here is that candidates often confuse alert severity levels (like Informational, Low, Medium, High) with incident classification options, leading them to incorrectly select 'Informational' as a valid classification when it is actually a severity label for alerts, not a post-investigation classification for incidents.

Practice this question →

456

MCQeasy

Your organization uses Microsoft Defender for Identity. You need to create a role that allows analysts to view security alerts but not modify them. Which built-in role should you assign?

A.Security Administrator

B.Compliance Administrator

C.Global Administrator

D.Security Reader

AnswerD

Security Reader provides read-only access to security alerts and reports across Microsoft 365 services, including Microsoft Defender for Identity. This role allows users to view and investigate identity-based alerts without the ability to modify settings, making it the correct minimum-permission role for this task.

Why this answer

The Security Reader role (D) is the correct choice because it provides read-only access to security-related features in Microsoft 365 Defender, including the ability to view security alerts from Microsoft Defender for Identity without the ability to modify or respond to them. This aligns directly with the requirement to allow analysts to view alerts but not modify them, as the role grants no write permissions to security configurations or alert states.

Exam trap

The trap here is that candidates often confuse Security Reader with Security Administrator, assuming the 'Administrator' suffix implies broader access, but the key distinction is that Security Reader is the only built-in role that provides read-only access to security alerts without modification rights.

How to eliminate wrong answers

Option A is wrong because the Security Administrator role has full write permissions to security policies and alerts, including the ability to modify alert statuses and configurations, which violates the requirement to prevent modifications. Option B is wrong because the Compliance Administrator role is focused on compliance settings (e.g., data classification, DLP, retention policies) and does not grant access to security alerts from Defender for Identity; it is not designed for security operations viewing. Option C is wrong because the Global Administrator role has unrestricted access to all administrative features, including full control over security alerts, which far exceeds the read-only requirement and introduces unnecessary privilege.

Practice this question →

457

MCQeasy

You are configuring Microsoft Defender for Cloud Apps to enhance visibility into your organization's SaaS app usage. You need to ensure that risky user activities are automatically suspended. What should you configure?

A.Set up IP address range policies.

B.Configure app discovery policies.

C.Create a session policy to block or limit activities based on risk.

D.Define file policies to protect sensitive data.

AnswerC

Session policies in Microsoft Defender for Cloud Apps use reverse proxy conditional access app control to intercept user sessions in real time, allowing you to allow or block specific activities such as downloading sensitive files, copying data, or uploading from risky devices. They can enforce restrictions based on user risk, device compliance, and contextual signals, applying controls dynamically during the active session. This granular, per-activity enforcement is exactly what is needed to 'block or limit activities based on risk' in a real-time manner.

Why this answer

Session policies in Microsoft Defender for Cloud Apps allow you to monitor and control user activities in real time based on risk level. By configuring a session policy with the 'block' or 'limit' action triggered by risk factors (e.g., anomalous location, impossible travel), you can automatically suspend risky user activities without disrupting legitimate usage.

Exam trap

The trap here is that candidates often confuse 'session policies' (which control real-time risky activities) with 'app discovery policies' (which only identify shadow IT) or 'file policies' (which protect data, not user behavior), leading them to select a wrong answer that addresses a different security objective.

How to eliminate wrong answers

Option A is wrong because IP address range policies are used to tag or categorize traffic by location (e.g., known corporate IPs) but do not automatically suspend risky activities; they only provide context for other policies. Option B is wrong because app discovery policies identify and analyze shadow IT usage (e.g., discovering unsanctioned SaaS apps) but do not enforce real-time activity suspension. Option D is wrong because file policies focus on detecting and protecting sensitive data (e.g., DLP rules for credit card numbers) rather than suspending risky user behaviors.

Practice this question →

458

MCQmedium

You are reviewing a PowerShell script used for automated response on a Windows 10 device managed by Microsoft Defender for Endpoint. What is the intended outcome of this script?

A.It removes all Trojan threats from the device.

B.It updates the antimalware signatures and then performs a scan.

C.It triggers a quick scan if any Trojan detection exists.

D.It configures Windows Defender to exclude Trojan files.

AnswerC

The script includes a conditional statement that evaluates whether any Trojan threat detection is present, likely using Get-MpThreatDetection or Get-MpThreat with a filter for the Trojan threat category. When that condition is true, it executes Start-MpScan with the QuickScan parameter. Because the decision to run the quick scan depends directly on the presence of Trojan detections, the correct characterization is that it triggers a quick scan if any Trojan detection exists.

Why this answer

The script checks for Trojan detections using Get-MpThreat with a threat category filter for Trojans. If any Trojan is found, it triggers Start-MpScan -ScanType QuickScan to perform a quick scan. This matches option C exactly.

Exam trap

The trap here is that candidates may assume the script performs remediation (option A) or updates signatures (option B) because those are common steps in response workflows, but the script only triggers a scan based on detection, not removal or update actions.

How to eliminate wrong answers

Option A is wrong because the script does not remove threats; it only triggers a scan, and removal would require additional commands like Remove-MpThreat. Option B is wrong because the script does not update antimalware signatures (which would require Update-MpSignature) before scanning. Option D is wrong because the script does not configure exclusions; it only checks for threats and initiates a scan.

Practice this question →

459

MCQeasy

Refer to the exhibit. You run this KQL query in Microsoft Sentinel. What does it return?

A.Number of high-severity incidents per status.

B.Total count of high-severity incidents in the last 7 days.

C.Top 5 incident owners by number of high-severity incidents in the last 7 days.

D.Top 5 users assigned to high-severity incidents.

AnswerC

This is correct. After filtering incidents to those with `Severity` equal to 'High' and `TimeGenerated` within the last 7 days, the query performs `summarize count() by Owner`, sorts the owner counts in descending order, and applies `take 5`. That yields exactly the top five incident owners ranked by their number of high-severity incidents in that time period.

Why this answer

The KQL query uses `summarize` with `count()` by `Owner`, then `top 5 by count_`, and filters with `where Severity == 'High'` and `TimeGenerated > ago(7d)`. This returns the top 5 incident owners ranked by the number of high-severity incidents they own in the last 7 days, making option C correct.

Exam trap

The trap here is that candidates confuse `Owner` (the incident owner, often a person or automation rule) with `User` (a user entity involved in the incident), leading them to pick option D, which incorrectly assumes the query returns users assigned to incidents rather than owners.

How to eliminate wrong answers

Option A is wrong because the query does not group or summarize by `Status`; it groups by `Owner` and counts incidents, not statuses. Option B is wrong because the query returns a top 5 list of owners with counts, not a single total count of incidents. Option D is wrong because the query filters by `Owner` (the incident owner, typically a security analyst or automation account), not by `User` (which would refer to a user entity or account involved in the incident).

Practice this question →

460

Multi-Selecteasy

Which THREE components are part of Microsoft Defender XDR? (Select three.)

Select 3 answers

A.Microsoft Defender for Endpoint

B.Microsoft Entra ID

C.Microsoft Defender for Identity

D.Microsoft Defender for Cloud

E.Microsoft Defender for Office 365

AnswersA, C, E

Microsoft Defender for Endpoint is one of the core workloads that compose Microsoft Defender XDR, feeding endpoint detections and alerts into the unified incident queue. Its signals correlate with the other Defender services, making it a required component of the suite.

Why this answer

Microsoft Defender XDR is the unified extended detection and response suite that correlates signals across Microsoft's first-party security workloads, and its core components include Microsoft Defender for Endpoint (A), which provides endpoint detection and response (EDR) for devices; Microsoft Defender for Identity (C), which monitors on-premises Active Directory Domain Services signals via sensors to detect identity-based attacks; and Microsoft Defender for Office 365 (E), which protects email, collaboration, and Office apps against phishing, malware, and business email compromise. These three services natively share incidents, alerts, and advanced hunting data in the Microsoft 365 Defender portal, which is why they are part of Defender XDR. Microsoft Entra ID (B) is the identity and access management service (formerly Azure AD) and is not itself a Defender XDR workload, though it feeds identity signals into the suite.

Microsoft Defender for Cloud (D) is a cloud security posture management and workload protection offering for Azure, multicloud, and hybrid resources, and it belongs to the Microsoft Defender for Cloud family rather than being one of the Defender XDR components.

Exam trap

The trap here is that candidates often confuse Microsoft Entra ID (formerly Azure AD) as a security detection component because it handles identity, but it is not a source of threat alerts within Defender XDR; instead, it is the identity provider that Defender for Identity monitors for malicious activity.

Practice this question →

461

MCQeasy

Refer to the exhibit. You are reviewing a custom Azure Policy definition that should block deployments from specific IP addresses. However, the policy does not seem to be evaluating any resources. What is the most likely issue?

A.The 'in' operator cannot be used with an array parameter

B.The policy definition has not been assigned to any scope

C.The policy mode should be 'Indexed' for network policies

D.The 'effect' should be 'audit' instead of 'deny'

AnswerB

A custom policy definition is merely a rule set that remains dormant until it is assigned to a management group, subscription, or resource group. Without an assignment, Azure Policy does not evaluate resources against the definition, so no deny actions or compliance results will appear. In this exhibit, the policy definition has no assigned scope, which is why it has no effect on any resources.

Why this answer

The exhibit shows a custom Azure Policy definition that is syntactically correct, but the policy is not evaluating any resources. The most likely cause is that the policy definition has not been assigned to a scope (e.g., management group, subscription, or resource group). In Azure Policy, a definition alone does nothing; it must be assigned to a scope to take effect and begin evaluating resources.

Exam trap

The trap here is that candidates focus on syntax errors or operator misuse in the policy definition, overlooking the prerequisite that a policy must be assigned to a scope before it can evaluate any resources.

How to eliminate wrong answers

Option A is wrong because the 'in' operator can be used with an array parameter in Azure Policy; the issue is not with the operator but with the missing assignment. Option C is wrong because the policy mode should be 'All' (or 'Microsoft.Network.Data') for network policies that evaluate resource properties, not 'Indexed', which is used for resource provider modes like 'Microsoft.Kubernetes.Data'. Option D is wrong because changing the effect from 'deny' to 'audit' would not cause the policy to fail to evaluate resources; it would only change the enforcement behavior, and the policy would still need to be assigned to a scope.

Practice this question →

462

MCQeasy

Your team uses Microsoft Defender XDR to manage incidents. You need to ensure that all incidents with a severity of 'High' are automatically assigned to a specific SOC analyst group. What should you configure?

A.Set up an advanced hunting query to detect high severity incidents and send email.

B.Create an automation rule in Microsoft Defender XDR to automatically assign incidents.

C.Configure a playbook in Microsoft Sentinel triggered by incidents.

D.Use the 'New-MTPIncidentAssignment' cmdlet in a scheduled task.

AnswerB

Automation rules in Microsoft Defender XDR are the built-in mechanism for automatically applying actions—including assigning incidents to a specific owner or team—based on conditions like severity, detection source, or category. When an incident is created or updated, the rule evaluates it in real time and executes the assigned action, eliminating manual triage. This is the correct, supported way to enforce ownership policies centrally.

Why this answer

Microsoft Defender XDR's automation rules allow you to define conditions (e.g., severity equals 'High') and actions (e.g., assign to a specific SOC analyst group) that are executed automatically when incidents are created or updated. This is the native, built-in mechanism for incident assignment without requiring external scripts, playbooks, or email-based workflows.

Exam trap

The trap here is that candidates often confuse Microsoft Sentinel playbooks with Defender XDR automation rules, assuming Sentinel's incident orchestration can be applied to Defender XDR incidents, but they are separate platforms with distinct automation mechanisms.

How to eliminate wrong answers

Option A is wrong because advanced hunting queries are read-only and cannot trigger actions like assignment; they only return data for analysis, and sending an email does not automate the assignment of the incident. Option C is wrong because Microsoft Sentinel playbooks are designed for Azure Sentinel incidents, not Microsoft Defender XDR incidents; Defender XDR has its own automation rules and does not natively integrate Sentinel playbooks for incident assignment. Option D is wrong because the 'New-MTPIncidentAssignment' cmdlet does not exist; the correct PowerShell module for Defender XDR is 'Microsoft 365 Defender' and there is no such cmdlet for incident assignment—assignment is done via the API or automation rules, not a scheduled task.

Practice this question →

463

MCQeasy

Your organization uses Microsoft Sentinel for security information and event management (SIEM). You need to ensure that all incidents from a specific analytics rule are automatically assigned to the 'SOC Tier 1' team. What should you configure in Microsoft Sentinel?

A.Configure alert enrichment in the analytics rule to add the owner.

B.Modify the analytics rule to write the incident to a custom table accessible by the SOC team.

C.Create a playbook that assigns the incident and attach it to the analytics rule.

D.Create an automation rule that triggers when the incident is created and sets the owner.

AnswerD

An automation rule can be configured to trigger when an incident is created, and its 'Set owner' action immediately assigns the incident to a designated user or group. This is the native, lightweight mechanism in Microsoft Sentinel for enforcing assignment policy at incident creation, and it can be scoped to the specific analytics rule. Because it directly updates the incident record's Owner property, it satisfies the requirement.

Why this answer

Automation rules in Microsoft Sentinel allow you to define conditions (such as incident creation) and actions (such as setting the owner) without requiring a playbook or custom code. This provides a lightweight, native way to automatically assign incidents from a specific analytics rule to the 'SOC Tier 1' team by filtering on the rule's name or ID in the automation rule's condition.

Exam trap

The trap here is that candidates often confuse automation rules with playbooks, thinking a playbook is always required for any automated action, when in fact automation rules can directly assign ownership without invoking a Logic App.

How to eliminate wrong answers

Option A is wrong because alert enrichment in an analytics rule is used to add custom details (like key-value pairs) to alerts, not to assign ownership or modify incident properties. Option B is wrong because writing an incident to a custom table does not assign ownership; it only stores data for querying, and incidents are already stored in the SecurityIncident table. Option C is wrong because while a playbook can assign an incident, it is an overengineered solution requiring additional Logic Apps cost and complexity; automation rules are the recommended and simpler method for this task.

Practice this question →

464

MCQmedium

You are a security operations analyst for a company that uses Microsoft Sentinel. The SOC manager wants to reduce alert fatigue by automatically closing incidents that are created by a specific analytics rule and contain only low-severity alerts. You need to configure this behavior with the least administrative effort. What should you do?

A.Configure a workbook that filters incidents by severity and analytics rule, and instruct analysts to manually close matching incidents during each shift.

B.Create a playbook that queries the Microsoft Sentinel incidents table with a KQL query for low-severity incidents and then calls the Microsoft Sentinel API to close them on a schedule.

C.Create an automation rule that runs when an incident is created, with a condition on the analytics rule name and severity, and an action to change the incident status to Closed.

D.Modify the analytics rule to set the incident creation setting to Disabled so that no incident is created for low-severity alerts.

AnswerC

Automation rules in Microsoft Sentinel can trigger on incident creation and evaluate conditions such as the analytics rule name and severity. The 'Change status' action can set the incident to Closed. This directly addresses the requirement without custom logic or manual triage, and it is the least-effort native approach.

Why this answer

Microsoft Sentinel automation rules are designed for lightweight incident handling and can trigger when an incident is created. By scoping conditions to the analytics rule name and severity, the rule targets only the intended low-severity incidents and uses the built-in status change action to close them. This avoids custom code, reduces manual triage, and meets the least-effort requirement.

Exam trap

The trap here is assuming that automation rules cannot change incident status and that a playbook is always required for any automated incident action.

Practice this question →