Courseiva

CCNA Mitigate Threats Using Microsoft Sentinel Questions

33 of 108 questions · Page 2/2 · Mitigate Threats Using Microsoft Sentinel topic · Answers revealed

Practice these questionsExam hubAll questions
76
MCQeasy

A SOC analyst needs to create an analytics rule in Microsoft Sentinel that triggers when a single user attempts to sign in from more than three different countries within 10 minutes. Which tables and KQL operators are needed?

A.SigninLogs, summarize make_set(Country) by UserPrincipalName, then where countof(Country) > 3
B.SigninLogs, summarize dcount(Country) by UserPrincipalName, bin(TimeGenerated, 10m) having dcount > 3
C.AADSignInEventsMicrosoft, summarize count() by UserPrincipalName
D.AzureActivity, summarize make_list(Country) by Caller
AnswerB

This correctly groups sign-in attempts by user and 10-minute bins, then counts distinct countries and filters for >3.

Why this answer

Option B is correct because it uses the `SigninLogs` table, which contains Azure AD sign-in events with geographic data, and the `summarize dcount(Country) by UserPrincipalName, bin(TimeGenerated, 10m)` pattern to count distinct countries per user within a 10-minute window. The `having dcount > 3` clause filters for users who signed in from more than three distinct countries, directly matching the requirement.

Exam trap

The trap here is that candidates confuse `count()` (total events) with `dcount()` (distinct values) and overlook the need for `bin()` to enforce the time window, leading them to choose Option A or C despite their invalid syntax or wrong table.

How to eliminate wrong answers

Option A is wrong because `make_set(Country)` creates a list of all countries, but `countof(Country)` is not a valid KQL operator; the correct approach is `dcount()` for distinct count, and the syntax `where countof(Country) > 3` would fail. Option C is wrong because `AADSignInEventsMicrosoft` is a table from Microsoft 365 Defender, not Sentinel's default sign-in logs, and `count()` aggregates total events per user without any country or time-window logic. Option D is wrong because `AzureActivity` logs Azure resource management operations, not user sign-ins, and `make_list(Country)` would not apply to sign-in geography.

Practice this question →
77
MCQmedium

An organization ingests Windows Security Events into Microsoft Sentinel via the Security Events connector. An analyst wants to create a scheduled analytics rule that alerts when more than 10 failed logon events (Event ID 4625) occur for the same user within a 5-minute window. Which KQL operator should the analyst use to count events per user in that time window?

A.summarize
B.extend
C.project
D.where
AnswerA

summarize groups rows and can compute aggregate values like count() per user and time bin.

Why this answer

The `summarize` operator is correct because it groups events by user and then applies an aggregation function (like `count()`) to calculate the number of failed logon events per user within the 5-minute window. This directly supports the rule's requirement to count events per user and compare the count to a threshold of 10.

Exam trap

The trap here is that candidates often confuse `summarize` with `extend` or `project`, mistakenly thinking that adding a calculated column or selecting columns can perform grouping and counting, when only `summarize` provides aggregation capabilities.

How to eliminate wrong answers

Option B (`extend`) is wrong because it creates new calculated columns for each row but does not group or aggregate data, so it cannot count events per user. Option C (`project`) is wrong because it selects or reorders columns without performing any aggregation or grouping. Option D (`where`) is wrong because it filters rows based on a condition but does not count or group events per user.

Practice this question →
78
MCQhard

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

A.SigninLogs | join ThreatIntelligence_IP on IPAddress | where UserId notin (ApprovedUsers | project UserId)
B.SigninLogs | where IPAddress in (ThreatIntelligence_IP | project IPAddress) and UserId !in (ApprovedUsers | project UserId)
C.SigninLogs | join kind=inner ThreatIntelligence_IP on IPAddress | join kind=leftanti (ApprovedUsers | project UserId) on $left.UserId == $right.UserId
D.SigninLogs | join ThreatIntelligence_IP on IPAddress | where not(UserId in (ApprovedUsers | project UserId))
AnswerC

This query first performs an inner join to keep only sign-ins from threat actor IPs, then a left anti join to exclude sign-ins from approved users. This is the most efficient and clear pattern.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
79
MCQhard

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

A.Use Azure Lighthouse to delegate management and then create rules in the managing workspace that use workspace() expressions
B.Create a KQL function that unions the relevant tables from all workspaces using the workspace() expression, then use that function in the analytics rule query
C.Configure the analytics rule to run in Log Analytics workspace manager and use cross-workspace queries native to Copilot for Security
D.Enable cross-workspace incident view in Sentinel settings and define the rule in the central workspace to automatically query all linked workspaces
AnswerB

A saved function can union data from multiple workspaces. The analytics rule can then query this function, effectively querying across workspaces.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
80
MCQhard

A SOC analyst is configuring a scheduled analytics rule in Microsoft Sentinel that detects sign-ins from IP addresses contained in a custom threat intelligence watchlist. The analyst wants to avoid creating multiple incidents for the same user and source IP address combination within a 6-hour window. Which configuration in the 'Incident creation' settings should the analyst use to achieve this suppression?

A.Using the 'Event grouping' option under 'Alert grouping' with a 6-hour re-open window
B.Setting a custom query threshold so that alerts are only generated once per time window
C.Enabling 'Suppression' on the 'Schedule' page to stop running the query after the first incident
D.Using the 'Custom' alert grouping and setting a time window for re-opening
AnswerA

Correct. 'Event grouping' (Group alerts into a single incident if they match criteria) allows you to deduplicate based on user and IP, and the re-open window prevents new incidents for the same combination within the selected time.

Why this answer

Option A is correct because the 'Event grouping' setting under 'Alert grouping' allows the analyst to group alerts that fire within a specified time window into a single incident. By setting the 'Re-open window' to 6 hours, any new alert matching the same user and source IP address combination will not create a new incident but will instead re-open the existing incident, effectively suppressing duplicate incidents within that window.

Exam trap

The trap here is confusing 'Suppression' on the Schedule page (which stops the query from running) with 'Event grouping' (which suppresses duplicate incidents while still allowing the query to run and detect new threats).

How to eliminate wrong answers

Option B is wrong because setting a custom query threshold controls how many query results are needed to generate an alert, not how alerts are grouped or suppressed over time; it does not prevent multiple incidents for the same user and IP combination within a 6-hour window. Option C is wrong because enabling 'Suppression' on the 'Schedule' page stops the query from running entirely after the first incident is created, which would prevent detection of any new sign-ins from that IP for the entire suppression period, not just suppress duplicate incidents. Option D is wrong because 'Custom' alert grouping allows you to define how alerts are grouped into incidents, but it does not include a 're-open window' setting; the re-open window is a feature of 'Event grouping', not 'Custom' grouping.

Practice this question →
81
MCQeasy

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

A.bin()
B.summarize
C.count
D.where
AnswerA

The bin() function is used to group time series data into time intervals, such as 5-minute buckets.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
82
MCQhard

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

A.Create an automation rule that triggers a playbook directly.
B.Create a scheduled analytics rule that runs a playbook.
C.Create an automation rule that triggers on incident creation and runs a playbook that uses the Azure Firewall connector to add a rule.
D.Configure a Logic App to poll Sentinel alerts and block IPs.
AnswerC

This is correct: automation rule triggers on incident creation, invokes a playbook that uses Azure Firewall connector to block the IP.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
83
MCQhard

A KQL query detects brute-force attempts by summarizing failed sign-ins by user, IP address, and five-minute time bins. Which operator is most appropriate for this aggregation?

A.summarize.
B.project-away.
C.parse_json.
D.extend.
AnswerA

summarize is used for aggregation such as count() by user, IP, and bin(TimeGenerated, 5m).

Why this answer

The `summarize` operator is the correct choice because it groups rows by specified columns (user, IP address, and five-minute time bins) and applies an aggregation function (e.g., `count()`) to detect brute-force patterns. In KQL, `summarize` is the only operator that can create time-binned aggregations using the `bin()` function, which is essential for grouping failed sign-ins into fixed five-minute intervals. This directly supports the brute-force detection requirement by counting failed attempts per user/IP/time window.

Exam trap

The trap here is that candidates may confuse `extend` with `summarize` because both can create new columns, but only `summarize` performs grouping and aggregation, which is essential for detecting brute-force patterns over time bins.

How to eliminate wrong answers

Option B is wrong because `project-away` removes columns from the result set, but it does not perform any aggregation or grouping, so it cannot summarize failed sign-ins by user, IP, and time bins. Option C is wrong because `parse_json` extracts values from JSON strings into structured fields, but it has no aggregation capability and cannot group or count events over time. Option D is wrong because `extend` adds new calculated columns to each row without reducing or grouping rows, so it cannot produce the summarized counts needed for brute-force detection.

Practice this question →
84
MCQmedium

A SOC analyst needs to create an analytics rule in Microsoft Sentinel that triggers when a user logs in from an IP address outside of the organization's typical geographic locations, based on a learned baseline. Which type of analytics rule is best suited for this scenario?

A.Scheduled rule
B.NRT (Near-Real-Time) rule
C.Anomaly rule
D.Fusion rule
AnswerC

Anomaly rules leverage machine learning to learn normal patterns and alert on outliers, making them perfect for detecting unusual sign-in locations.

Why this answer

An Anomaly rule in Microsoft Sentinel uses machine learning to establish a baseline of normal user behavior, such as typical geographic login locations. When a login event deviates from that learned baseline (e.g., from an unusual IP address outside the expected regions), the rule triggers an alert. This is the only rule type specifically designed for behavior-based anomaly detection without requiring static thresholds or predefined patterns.

Exam trap

The trap here is that candidates confuse Anomaly rules with Scheduled rules, thinking a scheduled query with a geographic filter (e.g., 'where ip_geo not in allowed list') can achieve the same result, but they miss that Anomaly rules dynamically learn and adapt the baseline without manual maintenance of allowed location lists.

How to eliminate wrong answers

Option A is wrong because a Scheduled rule runs on a fixed schedule (e.g., every 5 minutes) and relies on static KQL queries with explicit thresholds, not on a dynamically learned baseline of geographic locations. Option B is wrong because an NRT (Near-Real-Time) rule processes streaming data with low latency but still requires a predefined query and threshold, not machine learning-based anomaly detection. Option D is wrong because a Fusion rule correlates multiple low-fidelity alerts across different products to identify advanced attacks, but it does not learn a baseline of normal user behavior or detect single-event geographic anomalies.

Practice this question →
85
MCQmedium

A SOC analyst wants to use Microsoft Sentinel's User and Entity Behavior Analytics (UEBA) to identify a user who is performing suspicious actions, such as accessing a high number of resources outside of their normal pattern. What must be enabled for UEBA to function correctly in Microsoft Sentinel?

A.Enable Microsoft Entra ID Identity Protection and ensure the Microsoft Sentinel workspace has UEBA enabled.
B.Enable Microsoft Entra ID Audit Logs and Sign-in Logs streaming directly to the Sentinel workspace.
C.Install the Microsoft 365 Defender connector and enable UEBA in Microsoft 365 Defender.
D.Deploy the Azure Sentinel UEBA solution from Content Hub and configure watchlists for user baselines.
AnswerA

Correct. UEBA requires Microsoft Entra ID Identity Protection for baseline user behavior, and the Sentinel workspace must have the UEBA feature turned on.

Why this answer

UEBA in Microsoft Sentinel relies on data sources that provide user activity logs, such as Microsoft Entra ID Audit Logs and Sign-in Logs, to establish behavioral baselines and detect anomalies. However, for UEBA to function correctly, the Microsoft Sentinel workspace must have UEBA enabled at the workspace level, and Microsoft Entra ID Identity Protection must be enabled to provide the necessary risk signals and enrichments that feed into the anomaly detection engine. Without Identity Protection, UEBA lacks the contextual risk data required to identify suspicious actions like accessing a high number of resources outside normal patterns.

Exam trap

The trap here is that candidates often assume simply enabling data connectors (like Audit Logs or Microsoft 365 Defender) is sufficient for UEBA, but they overlook the requirement to explicitly enable UEBA at the Sentinel workspace level and to enable Microsoft Entra ID Identity Protection for risk signal integration.

How to eliminate wrong answers

Option B is wrong because simply streaming Microsoft Entra ID Audit Logs and Sign-in Logs to Sentinel provides raw data but does not enable UEBA; UEBA requires the workspace-level UEBA setting to be turned on and Identity Protection for risk scoring. Option C is wrong because installing the Microsoft 365 Defender connector and enabling UEBA in Microsoft 365 Defender does not enable UEBA in Microsoft Sentinel; UEBA in Sentinel is a separate feature that must be enabled within the Sentinel workspace, not in Microsoft 365 Defender. Option D is wrong because there is no 'Azure Sentinel UEBA solution' in Content Hub; UEBA is a built-in feature of Sentinel that is enabled via the workspace settings, not through a solution deployment, and watchlists are used for custom entity enrichment, not for enabling UEBA.

Practice this question →
86
MCQeasy

A security analyst wants to quickly check the number of incidents created in Microsoft Sentinel in the last 7 days, grouped by severity. Which KQL query should the analyst use?

A.SecurityIncident | where TimeGenerated > ago(7d) | summarize count() by Severity
B.SecurityAlert | where TimeGenerated > ago(7d) | summarize count() by Severity
C.SigninLogs | where TimeGenerated > ago(7d) | summarize count() by Status
D.DeviceEvents | where TimeGenerated > ago(7d) | summarize count() by ActionType
AnswerA

Correct. This query filters incidents from the last 7 days and counts them per severity.

Why this answer

Option A is correct because the SecurityIncident table in Microsoft Sentinel stores incident records, and the query filters for incidents created in the last 7 days using `where TimeGenerated > ago(7d)`, then groups them by severity with `summarize count() by Severity`. This directly answers the analyst's need to check the number of incidents grouped by severity.

Exam trap

The trap here is confusing the SecurityIncident table (for incidents) with the SecurityAlert table (for alerts), as many candidates mistakenly use SecurityAlert when the question explicitly asks for incident counts.

How to eliminate wrong answers

Option B is wrong because SecurityAlert contains alert data, not incidents; alerts can be grouped into incidents but are not the same entity, so this query would count alerts, not incidents. Option C is wrong because SigninLogs tracks user sign-in events and uses Status (e.g., success/failure), not incident severity, so it is irrelevant to incident counts. Option D is wrong because DeviceEvents logs device-level activities and uses ActionType (e.g., 'CreateProcess'), not incident severity, making it unrelated to incident management.

Practice this question →
87
MCQmedium

A SOC team wants to automate response to incidents detected by Microsoft Sentinel. When a new incident is created with severity "High" and contains a specific tag "malware", they want to run a playbook that isolates the affected device. What is the correct way to configure this automation?

A.Create an automation rule that triggers on "When incident is created" and set conditions for severity equals High and tag contains "malware", then set a playbook action.
B.Create a custom analytics rule that runs the playbook directly when triggered.
C.Configure a logic app with a trigger on "When a Microsoft Sentinel incident is created" and use conditions inside the logic app.
D.Use the Microsoft Sentinel API to create a webhook that triggers the playbook.
AnswerA

This correctly uses automation rules to trigger the playbook based on incident properties.

Why this answer

Option A is correct because automation rules in Microsoft Sentinel are specifically designed to trigger playbooks based on incident creation events and conditions like severity and tag. By setting the trigger to 'When incident is created' and conditions for severity equals 'High' and tag contains 'malware', the rule will invoke the playbook to isolate the affected device automatically, without manual intervention.

Exam trap

The trap here is that candidates may think a custom analytics rule or a direct Logic App trigger is equivalent to an automation rule, but Microsoft Sentinel's automation rules are the intended and most efficient way to conditionally invoke playbooks based on incident properties like severity and tags.

How to eliminate wrong answers

Option B is wrong because custom analytics rules generate alerts or incidents based on query results, but they do not directly run playbooks; playbooks are invoked by automation rules or as part of incident response. Option C is wrong because while a Logic App with a 'When a Microsoft Sentinel incident is created' trigger can work, it bypasses the native automation rule framework and requires manual condition handling inside the Logic App, making it less efficient and not the recommended configuration for this scenario. Option D is wrong because using the Microsoft Sentinel API to create a webhook is an indirect, custom integration method that lacks the built-in triggering and condition evaluation of automation rules, and is not the standard way to automate incident response.

Practice this question →
88
MCQmedium

A SOC team wants to automatically categorize incidents in Microsoft Sentinel with MITRE ATT&CK tactics (e.g., 'Initial Access', 'Execution') when an analytics rule triggers. How can they achieve this?

A.Use the incident details custom fields
B.Map MITRE ATT&CK tactics in the analytics rule
C.Use automation rule to set tactics
D.Use playbook to update incident
AnswerB

Correct: The analytics rule configuration includes an option to select MITRE ATT&CK tactics, which are then applied to generated incidents.

Why this answer

Option B is correct because Microsoft Sentinel analytics rules include a dedicated 'MITRE ATT&CK' configuration section where you can map specific tactics (e.g., Initial Access, Execution) to the rule. When the rule triggers and generates an incident, Sentinel automatically populates the incident's MITRE ATT&CK tactics field based on this mapping, enabling automated categorization without additional configuration.

Exam trap

Microsoft often tests the distinction between native analytics rule configuration (which directly sets MITRE ATT&CK tactics) versus post-processing methods like automation rules or playbooks, leading candidates to overcomplicate the solution when the simplest, built-in option is correct.

How to eliminate wrong answers

Option A is wrong because incident details custom fields are user-defined fields for storing arbitrary data, not a mechanism to automatically set MITRE ATT&CK tactics from an analytics rule trigger. Option C is wrong because automation rules can modify incident properties (e.g., severity, status) but cannot directly set MITRE ATT&CK tactics; they lack a dedicated action for MITRE ATT&CK fields. Option D is wrong because while a playbook (Azure Logic App) could theoretically update incident tactics via the Microsoft Sentinel API, this is an indirect, complex approach that requires custom code and is not the intended or simplest method—the native analytics rule mapping is the correct design.

Practice this question →
89
MCQeasy

A SOC analyst wants to create a scheduled analytics rule in Microsoft Sentinel that detects when a user is added to a privileged Microsoft Entra ID role (e.g., Global Administrator). Which data table is essential for the query?

A.AuditLogs
B.SigninLogs
C.SecurityEvent
D.CommonSecurityLog
AnswerA

Correct. The AuditLogs table in Microsoft Sentinel (via Microsoft Entra ID connector) contains directory audit events, including changes to privileged role memberships.

Why this answer

The AuditLogs table in Microsoft Sentinel captures all directory-level audit activities, including modifications to Microsoft Entra ID (formerly Azure AD) role assignments. When a user is added to a privileged role like Global Administrator, the event is logged as an 'Add member to role' activity in the AuditLogs table. This makes AuditLogs the essential data source for detecting such privileged role changes.

Exam trap

Microsoft often tests the distinction between sign-in logs (SigninLogs) and audit logs (AuditLogs), trapping candidates who confuse authentication events with directory configuration changes.

How to eliminate wrong answers

Option B (SigninLogs) is wrong because it records user authentication events (sign-ins), not directory configuration changes like role assignments. Option C (SecurityEvent) is wrong because it contains Windows security events from on-premises or Azure VMs, not Microsoft Entra ID role activities. Option D (CommonSecurityLog) is wrong because it aggregates syslog-style logs from third-party security appliances (e.g., firewalls, IDS/IPS), not Microsoft Entra ID audit data.

Practice this question →
90
MCQmedium

A SOC analyst has created a custom scheduled analytics rule in Microsoft Sentinel that runs every hour and generates an incident when a certain pattern is detected. The analyst notices that the same set of events is causing a new incident every hour, leading to duplicates. What should the analyst configure to prevent duplicate incident generation from the same events?

A.Set the alert suppression setting in the analytics rule
B.Use an automation rule to close duplicates
C.Modify the query to use the 'summarize' operator
D.Change the query to use the 'take' operator
AnswerA

Correct: Alert suppression prevents duplicate alerts from the same events within a specified period.

Why this answer

Option A is correct because the alert suppression setting in a Microsoft Sentinel scheduled analytics rule allows you to configure a time window during which duplicate alerts from the same events are suppressed. When enabled, Sentinel will not generate a new incident from the same set of events until the suppression window expires, preventing the hourly duplication the analyst observed.

Exam trap

The trap here is that candidates often confuse alert suppression (preventing duplicate alerts) with incident closing mechanisms (automation rules), leading them to choose Option B instead of the correct suppression setting.

How to eliminate wrong answers

Option B is wrong because automation rules can close incidents after they are created, but they do not prevent the generation of duplicate incidents from the same events; duplicates would still be created and then closed, which is inefficient and does not address the root cause. Option C is wrong because using the 'summarize' operator in the query would aggregate events but would not prevent the same events from being evaluated again in the next hourly run; it could also alter the detection logic and miss patterns. Option D is wrong because the 'take' operator limits the number of rows returned by the query, which would arbitrarily drop events and could cause missed detections, not prevent duplicates from the same events.

Practice this question →
91
Multi-Selecthard

A Microsoft Sentinel incident contains alerts from multiple analytics rules. The analyst suspects the same compromised account performed impossible travel followed by suspicious mailbox access. Which two actions best help correlate identity and mailbox activity?

Select 2 answers
A.Query SigninLogs for the account around the alert timestamps
B.Delete the incident to force it to regenerate
C.Disable all analytics rules that contributed alerts
D.Query OfficeActivity or relevant Microsoft 365 Defender email/cloud activity tables for mailbox operations
AnswersA, D

SigninLogs provide Microsoft Entra sign-in events, locations, risk details, and timestamps for identity correlation.

Why this answer

Option A is correct because querying SigninLogs for the account around the alert timestamps directly retrieves Azure AD authentication events, which are essential for identifying the source IP addresses, locations, and timestamps that define the impossible travel pattern. This data is the primary evidence for the first part of the suspected compromise.

Exam trap

The trap here is that candidates may think deleting or disabling rules will fix the correlation gap, but the correct approach is to manually query the relevant data sources (SigninLogs and OfficeActivity) to perform the correlation, as Sentinel does not automatically link identity and mailbox events across different data connectors.

Practice this question →
92
MCQeasy

A SOC manager wants to quickly view the number of incidents generated in Microsoft Sentinel over the past 7 days, grouped by Azure subscription. Which KQL query should be used on the SecurityIncident table?

A.SecurityIncident | where CreatedTime > ago(7d) | summarize count() by SubscriptionId
B.SecurityAlert | where TimeGenerated > ago(7d) | summarize count() by SubscriptionId
C.SecurityIncident | where TimeGenerated > ago(7d) | summarize count() by SubscriptionId
D.SecurityIncident | where CreatedTime > ago(7d) | summarize count() by WorkspaceSubscriptionId
AnswerA

Correct. This query filters incidents created in the last 7 days and groups by subscription.

Why this answer

Option A is correct because the SecurityIncident table stores incident records, and the CreatedTime field records when each incident was generated. Filtering with `where CreatedTime > ago(7d)` limits results to the past 7 days, and `summarize count() by SubscriptionId` groups the count by the Azure subscription that owns the resources involved in the incident. This directly meets the SOC manager's requirement to view the number of incidents per subscription over the last week.

Exam trap

The trap here is confusing the SecurityIncident table's SubscriptionId with WorkspaceSubscriptionId, or using the wrong time field (TimeGenerated instead of CreatedTime), leading candidates to pick options that either query the wrong table or group by the wrong subscription identifier.

How to eliminate wrong answers

Option B is wrong because it queries the SecurityAlert table instead of SecurityIncident, which contains alerts rather than incidents; incidents are the higher-level grouping of alerts, so this would not show incident counts. Option C is wrong because it uses TimeGenerated on the SecurityIncident table, but SecurityIncident does not have a TimeGenerated column; this would cause a query error or return no results. Option D is wrong because it groups by WorkspaceSubscriptionId, which is the subscription of the Log Analytics workspace, not the Azure subscription associated with the incident's resources; the SOC manager specifically needs incidents grouped by the subscription where the resources reside, which is SubscriptionId.

Practice this question →
93
MCQeasy

A security analyst needs to identify incidents in Microsoft Sentinel that are related to IP addresses known to be associated with a specific threat actor. The analyst has a CSV file containing a list of these IP addresses. Which feature should the analyst use to make this list available for queries in Sentinel?

A.Custom Log
B.Watchlist
C.Threat Intelligence indicator
D.Bookmark
AnswerB

Watchlists allow you to upload CSV lists and make them available as tables that can be referenced in KQL queries, making them the easiest way to use a custom IP list.

Why this answer

A Watchlist in Microsoft Sentinel allows you to import a CSV file containing IP addresses and use it directly in KQL queries via the _GetWatchlist() function. This is the correct feature because it is specifically designed for storing and querying static reference data, such as known threat actor IPs, without requiring custom ingestion or transformation.

Exam trap

The trap here is that candidates often confuse Threat Intelligence indicators with a simple CSV import, but TI indicators require a structured format and integration with a TI platform, whereas a Watchlist is the direct, low-friction solution for static reference data.

How to eliminate wrong answers

Option A is wrong because a Custom Log is used to ingest raw data from a custom source into a Log Analytics workspace, requiring a defined schema and ingestion pipeline; it is not designed for quick, queryable reference lists from a CSV file. Option C is wrong because Threat Intelligence indicators are structured objects (e.g., STIX format) that integrate with threat intelligence platforms and are used for correlation with Sentinel's TI analytics rules, not for importing a simple CSV list of IPs. Option D is wrong because a Bookmark is used to save specific search results or hunting queries for later investigation, not to store or make a static list of IP addresses available for queries.

Practice this question →
94
MCQmedium

An organization uses Microsoft Sentinel to monitor Microsoft Entra ID sign-ins. A SOC analyst creates a scheduled analytics rule that runs every 15 minutes and uses the following KQL query: SigninLogs | where TimeGenerated > ago(30m) | summarize count() by IPAddress | where count_ > 10. The rule is intended to detect brute-force attacks from a single IP address. However, the analyst notices that alerts are generated even when IP addresses are within the company's trusted corporate network range. What is the most appropriate fix to reduce false positives?

A.Modify the query to exclude IP addresses from the corporate network by adding '| where IPAddress notin (dynamic(['10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16']))' or by using a watchlist
B.Increase the threshold from 10 to 20 failed attempts
C.Decrease the rule's run frequency to every 5 minutes
D.Change the data source to AADNonInteractiveUserSignInLogs
AnswerA

This filters out trusted IP ranges, reducing false positives while retaining detection of external brute-force attempts.

Why this answer

Option A is correct because the query currently counts all sign-in attempts, including those from trusted corporate IP ranges, which generates false positives for brute-force detection. By adding a filter to exclude corporate IP addresses (e.g., RFC 1918 ranges) or using a watchlist, the rule only alerts on external IPs that exceed the threshold, reducing noise. This directly addresses the root cause—internal traffic being incorrectly flagged—without altering detection logic or data sources.

Exam trap

The trap here is that candidates may think increasing the threshold (Option B) is a valid tuning approach, but it fails to address the root cause—internal IPs being included—and instead reduces detection sensitivity for all IPs, which is not a targeted fix.

How to eliminate wrong answers

Option B is wrong because increasing the threshold to 20 does not exclude corporate IPs; it only reduces sensitivity, potentially missing real attacks from external IPs while still generating alerts for high-volume internal traffic. Option C is wrong because decreasing the run frequency to 5 minutes does not filter out corporate IPs; it only increases query execution rate, which may cause performance issues and still produce false positives from internal addresses. Option D is wrong because changing the data source to AADNonInteractiveUserSignInLogs targets non-interactive sign-ins (e.g., service principals), which are irrelevant to user-based brute-force attacks and would not resolve false positives from corporate IPs in interactive sign-in logs.

Practice this question →
95
MCQeasy

A SOC analyst wants to create a visual dashboard in Microsoft Sentinel to monitor sign-in activity trends over the past 30 days. Which feature should the analyst use?

A.Analytics rules
B.Workbooks
C.Playbooks
D.Threat Intelligence
AnswerB

Workbooks allow creation of visual dashboards and reports using KQL queries on ingested data.

Why this answer

Workbooks in Microsoft Sentinel provide a flexible canvas for creating custom visual dashboards using Azure Monitor Workbooks. They allow the analyst to query Log Analytics workspaces (e.g., SigninLogs table) and render time-series charts, trend lines, and other visualizations to monitor sign-in activity over the past 30 days. This is the correct feature for building a visual dashboard.

Exam trap

The trap here is that candidates often confuse Workbooks with Analytics rules, thinking that detection rules can also produce visual dashboards, but Analytics rules are solely for alert generation, not visualization.

How to eliminate wrong answers

Option A is wrong because Analytics rules are used to generate alerts and incidents based on threat detection logic, not to create visual dashboards or trend charts. Option C is wrong because Playbooks are automated response workflows (based on Azure Logic Apps) triggered by alerts or incidents, not a dashboarding or visualization tool. Option D is wrong because Threat Intelligence is a data source and management feature for ingesting and correlating threat indicators, not a feature for building visual dashboards.

Practice this question →
96
MCQhard

A SOC analyst creates a scheduled analytics rule in Microsoft Sentinel that uses the following KQL query to detect impossible travel: SigninLogs | where TimeGenerated > ago(1d) | summarize Countries = make_set(Location) by UserPrincipalName | where array_length(Countries) > 1 However, the analyst notices that the rule generates too many false positives for users who travel legitimately. What is the best way to refine the rule to reduce false positives without missing actual impossible travel?

A.Add a condition to filter out VPN IP addresses from the Log Analytics workspace.
B.Instead of using make_set, use the dcount() function to estimate distinct countries.
C.Use the time series anomaly detection function series_decompose() on the signin data.
D.Modify the query to include a time difference condition using the partition operator or a join to find sign-ins from different countries within a short time window.
AnswerD

This correctly adds a temporal constraint to identify truly impossible travel.

Why this answer

Option D is correct because impossible travel detection requires correlating sign-ins from different geographic locations within a time window that is too short for physical travel. By using the partition operator or a join to compare timestamps between sign-ins from different countries, the query can distinguish between legitimate sequential travel (e.g., a user flying from New York to London over 8 hours) and truly impossible simultaneous sign-ins (e.g., sign-ins from New York and London within 30 minutes). This reduces false positives while still catching actual impossible travel.

Exam trap

The trap here is that candidates may think filtering by VPN or using aggregation functions like make_set or dcount() is sufficient, but they fail to recognize that impossible travel detection fundamentally requires a time-based correlation between geographically distinct sign-in events.

How to eliminate wrong answers

Option A is wrong because filtering out VPN IP addresses does not address the core issue of legitimate travel; VPNs may be used for remote access and do not inherently indicate impossible travel, and this approach could miss actual threats where an attacker uses a VPN to mask their location. Option B is wrong because using dcount() instead of make_set only changes how distinct countries are counted (approximate vs. exact) and does not add any time-based logic to differentiate between sequential and simultaneous sign-ins. Option C is wrong because series_decompose() is designed for time series anomaly detection on numeric metrics (e.g., count of sign-ins over time), not for correlating geographic locations across user sign-in events to detect impossible travel.

Practice this question →
97
MCQeasy

A SOC analyst wants to create an automation rule in Microsoft Sentinel that runs a playbook to disable a user's Microsoft Entra ID account every time an incident is created with a specific 'User' entity (e.g., compromised user). Which condition should be configured in the automation rule?

A.When incident is created, if entity type equals 'Account' and entity value equals 'user@domain.com'
B.When incident is created, if the incident contains a 'User' entity
C.When incident is created with severity High
D.When incident is created, the playbook automatically runs without conditions
AnswerA

This condition ensures the automation rule triggers only when the incident contains the specific user account as an entity. The playbook can then use that entity to disable the user.

Why this answer

Option A is correct because the automation rule must trigger specifically when an incident is created that contains a 'User' entity with a specific value (e.g., user@domain.com). By setting the condition to 'entity type equals Account' and 'entity value equals user@domain.com', the rule ensures the playbook only runs for incidents involving that exact compromised user, preventing unnecessary or incorrect automation. This matches the requirement to disable a specific user's Microsoft Entra ID account based on the entity present in the incident.

Exam trap

The trap here is that candidates often confuse the generic 'contains a User entity' condition (Option B) with the need for a specific entity value, failing to realize that without the exact value, the rule would apply to all incidents with any user entity, not just the targeted compromised user.

How to eliminate wrong answers

Option B is wrong because checking if the incident contains a 'User' entity without specifying the exact entity value would trigger the playbook for any incident with any user entity, not just the targeted compromised user, leading to false positives and potential account lockouts. Option C is wrong because severity High is unrelated to the user entity; the condition must be based on the entity type and value, not the incident severity, to target the specific user. Option D is wrong because automation rules require explicit conditions to run playbooks; running a playbook unconditionally on every incident creation would violate the requirement to target only incidents with the specific 'User' entity.

Practice this question →
98
Matchingmedium

Match each Microsoft Sentinel feature to its purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Define conditions that generate incidents

Visualize data using custom dashboards

Proactively search for threats

Automate responses using Azure Logic Apps

Detect anomalous behavior based on entity analytics

Why these pairings

These features are core to Microsoft Sentinel's SIEM/SOAR capabilities.

Practice this question →
99
MCQhard

A SOC team uses Microsoft Sentinel. They receive a large volume of low-severity incidents from a specific analytics rule that causes alert fatigue. They want to automatically close incidents that match certain criteria (e.g., originating from a known test IP). Which feature should they configure?

A.Automation rules with a condition to close incidents
B.Playbook with a timer trigger
C.Watchlist integration
D.Fusion rule
AnswerA

Automation rules can be configured with conditions (e.g., if the source IP is in a watchlist) and an action to close the incident, effectively suppressing unwanted alerts.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically close incidents based on specific conditions, such as a known test IP address. This directly addresses alert fatigue by suppressing low-severity incidents without manual intervention. Unlike playbooks, automation rules are lightweight and run natively within Sentinel without requiring a Logic Apps instance.

Exam trap

Microsoft often tests the distinction between automation rules (native, condition-based actions) and playbooks (external Logic Apps workflows), leading candidates to incorrectly choose a playbook when a simpler automation rule suffices.

How to eliminate wrong answers

Option B is wrong because a playbook with a timer trigger runs on a schedule, not in response to an incident being created; it cannot automatically close incidents based on real-time criteria like source IP. Option C is wrong because a watchlist is a data reference object used for enrichment or correlation in queries and rules, not a mechanism to automatically close incidents. Option D is wrong because a Fusion rule is a correlation-based analytics rule that reduces alert fatigue by combining alerts into high-fidelity incidents, but it does not close existing incidents based on custom criteria like a test IP.

Practice this question →
100
MCQmedium

A security analyst wants to configure a playbook in Microsoft Sentinel that runs automatically when a specific alert is generated. Which trigger concept is used to invoke the playbook?

A.Azure Logic Apps trigger
B.Sentinel trigger
C.Alert trigger
D.Automation rule trigger
AnswerA

Playbooks are Logic Apps workflows; they use a built-in Logic Apps trigger to respond to Sentinel alerts.

Why this answer

In Microsoft Sentinel, playbooks are built on Azure Logic Apps, and the correct trigger to invoke a playbook automatically when an alert is generated is the Azure Logic Apps trigger. This trigger listens for the Sentinel alert creation event and initiates the playbook workflow. The other options are not valid trigger concepts within Sentinel's architecture.

Exam trap

The trap here is that candidates may confuse the automation rule (which invokes the playbook) with the actual trigger mechanism, leading them to choose 'Automation rule trigger' instead of recognizing that the playbook itself is triggered by an Azure Logic Apps trigger.

How to eliminate wrong answers

Option B is wrong because 'Sentinel trigger' is not a defined trigger type; the actual trigger is an Azure Logic Apps trigger that uses the Sentinel connector. Option C is wrong because 'Alert trigger' is a generic term and not the specific trigger concept used in Sentinel; the trigger is implemented via Logic Apps. Option D is wrong because 'Automation rule trigger' is a misnomer; automation rules can invoke playbooks, but the trigger itself is the Azure Logic Apps trigger, not an automation rule trigger.

Practice this question →
101
MCQmedium

An organization ingests its Palo Alto firewall logs into a custom table named 'PaloAlto_CL' in Microsoft Sentinel. A security analyst wants to create a scheduled analytics rule that triggers an incident when a single source IP is involved in more than 100 outbound connections to different destinations in 1 minute. Which KQL query and configuration would trigger the alert correctly?

A.summarize count() by SourceIP, bin(TimeGenerated,1m) and set threshold >100
B.summarize dcount(DestinationIP) by SourceIP, bin(TimeGenerated,1m) and set threshold >100
C.summarize count() by DestinationIP and threshold >100
D.summarize dcount(SourceIP) by DestinationIP, bin(TimeGenerated,1m) and threshold >100
AnswerB

This correctly counts distinct destination IPs per source IP per minute and triggers when that count exceeds 100.

Why this answer

Option B is correct because the requirement is to count distinct destination IPs per source IP per minute, not total connections. Using `dcount(DestinationIP)` with `bin(TimeGenerated,1m)` ensures we count unique destinations, and setting the threshold to >100 triggers when a single source IP connects to more than 100 different destinations in one minute, exactly matching the alert condition.

Exam trap

The trap here is confusing `count()` (total events) with `dcount()` (distinct values), leading candidates to select Option A, which would trigger on repeated connections to the same destination rather than the specified condition of different destinations.

How to eliminate wrong answers

Option A is wrong because `count()` counts all outbound connections, including repeated connections to the same destination, which would overcount and could trigger false positives. Option C is wrong because it groups by DestinationIP only, missing the per-source-IP requirement and the 1-minute time window, and uses a threshold without proper aggregation. Option D is wrong because it uses `dcount(SourceIP)` by DestinationIP, which counts distinct source IPs per destination, the inverse of what is needed, and the threshold >100 would incorrectly trigger on destinations receiving connections from many sources.

Practice this question →
102
MCQmedium

A security analyst is configuring a Microsoft Sentinel playbook to automate the response to phishing incidents. When an incident is created based on a phishing analytics rule, the playbook needs to execute an action in Microsoft 365 Defender, such as blocking the sender email address. Which connector should the analyst add to the playbook to interact with Microsoft 365 Defender?

A.Microsoft 365 Defender connector
B.Microsoft Entra ID connector
C.Azure DevOps connector
D.Teams connector
AnswerA

This connector provides actions to interact with Microsoft 365 Defender, such as blocking email senders or isolating devices.

Why this answer

The Microsoft 365 Defender connector is the correct choice because it provides the necessary actions to interact directly with Microsoft 365 Defender components, such as blocking a sender email address via the Advanced Hunting or action APIs. This connector enables the playbook to trigger remediation actions like email quarantine or sender block within the Microsoft 365 Defender portal, which is essential for automating responses to phishing incidents in Microsoft Sentinel.

Exam trap

The trap here is that candidates often confuse the Microsoft 365 Defender connector with the Microsoft Entra ID connector, assuming identity actions can block email senders, but Entra ID lacks the email security APIs required for such remediation.

How to eliminate wrong answers

Option B is wrong because the Microsoft Entra ID connector is designed for identity and access management actions (e.g., revoking user sessions, disabling accounts), not for email security actions like blocking a sender in Microsoft 365 Defender. Option C is wrong because the Azure DevOps connector is used for managing work items, pipelines, and repositories in Azure DevOps, not for security response actions in Microsoft 365 Defender. Option D is wrong because the Teams connector is used for sending messages or notifications to Microsoft Teams channels, not for executing remediation actions like blocking a sender email address.

Practice this question →
103
MCQmedium

A SOC analyst in Microsoft Sentinel is creating a scheduled analytics rule to detect anomalous Microsoft Entra ID sign-ins. The rule runs every 5 minutes and queries the SigninLogs table for sign-ins from IP addresses outside the organization's known country codes. To avoid duplicates, the rule should generate an incident only once for a particular user-IP combination until the combination is not seen for 60 minutes. Which configuration should the analyst use in the analytics rule wizard?

A.Alert details section
B.Query scheduling section
C.Incident settings tab - Grouping configuration
D.Entity mapping section
AnswerC

The grouping configuration allows resetting the grouping window, preventing duplicate incidents for repeated events within that window.

Why this answer

Option C is correct because the Incident settings tab's Grouping configuration allows you to group alerts into a single incident based on specific criteria, such as user-IP combination, and to suppress re-creation of an incident for a defined time window (e.g., 60 minutes) after the last occurrence. This directly addresses the requirement to avoid duplicate incidents for the same user-IP pair until it is not seen for 60 minutes.

Exam trap

The trap here is that candidates often confuse the Query scheduling section's 'Run query every' and 'Lookup data from the last' settings with deduplication, not realizing that those control query frequency and data range, not incident grouping or suppression based on entity combinations.

How to eliminate wrong answers

Option A is wrong because the Alert details section is used to configure the alert's name, description, severity, and tactics, not to control incident grouping or deduplication logic. Option B is wrong because the Query scheduling section defines how often the rule runs and the query lookback period, but it does not provide settings to group alerts or suppress duplicates based on entity combinations. Option D is wrong because Entity mapping section maps query results to entities (e.g., user, IP) for correlation and investigation, but it does not include any grouping or deduplication configuration.

Practice this question →
104
MCQhard

Match each Microsoft Sentinel data connector on the left with the table name it populates on the right.

A.Microsoft Entra ID → SigninLogs; Windows Security Events via AMA → SecurityEvent; Cisco ASA via Syslog → CommonSecurityLog; Azure Activity → AzureActivity
B.The first and last mappings are swapped.
C.Every item maps to the same log table or feature category.
D.Only identity-related items are mapped; workload and network items are omitted.
AnswerA

This is the correct mapping based on the documented function of each item.

Why this answer

Option A is correct because it accurately maps each Microsoft Sentinel data connector to its corresponding log table. Microsoft Entra ID populates the SigninLogs table, Windows Security Events via AMA populates the SecurityEvent table, Cisco ASA via Syslog populates the CommonSecurityLog table (which is the standard schema for syslog-based security appliances), and Azure Activity populates the AzureActivity table. These mappings are defined by the data connectors themselves and are fundamental to querying the correct data in Sentinel.

Exam trap

The trap here is that candidates often confuse the CommonSecurityLog table with the Syslog table, but Cisco ASA via Syslog specifically populates CommonSecurityLog (not Syslog) because Sentinel normalizes syslog data from security appliances into a common schema for easier correlation.

How to eliminate wrong answers

Option B is wrong because it suggests the first and last mappings are swapped, but Microsoft Entra ID correctly maps to SigninLogs (not AzureActivity) and Azure Activity correctly maps to AzureActivity (not SigninLogs); swapping them would be incorrect. Option C is wrong because it claims every item maps to the same log table or feature category, which is false as each connector populates a distinct table (SigninLogs, SecurityEvent, CommonSecurityLog, AzureActivity) with different schemas and purposes. Option D is wrong because it states only identity-related items are mapped, but the set includes Windows Security Events (workload security) and Cisco ASA (network security), which are not identity-related; all four items are correctly mapped.

Practice this question →
105
MCQhard

A SOC analyst in Microsoft Sentinel is creating a scheduled analytics rule to detect a possible password spray attack. The rule must trigger when a single source IP address has more than 10 failed logon attempts on different user accounts within a 30-minute window. The analyst writes a KQL query starting with 'SigninLogs | where ResultType == 50057' (failed logon). Which operator should the analyst use to group events by source IP and count distinct user accounts, then filter for counts above 10?

A.summarize
B.where
C.extend
D.project
AnswerA

The 'summarize' operator groups rows and applies aggregate functions like dcount() or count() to calculate distinct user counts per IP.

Why this answer

The `summarize` operator is required to group events by source IP address and count distinct user accounts using `dcount()` or `count()`. After summarizing, you apply a `where` clause to filter for counts above 10, which meets the rule's threshold. This is the standard pattern for aggregation in KQL.

Exam trap

The trap here is that candidates often confuse `summarize` with `extend` or `project`, thinking they can achieve aggregation without an explicit grouping operator, or they mistakenly use `where` after a simple filter instead of performing the required count and threshold check.

How to eliminate wrong answers

Option B is wrong because `where` filters rows based on conditions but cannot perform grouping or counting; it would only filter individual sign-in events, not aggregate them. Option C is wrong because `extend` adds new calculated columns to each row without any aggregation or grouping, so it cannot count distinct users per IP. Option D is wrong because `project` selects or reorders columns but does not group or count data; it would merely reduce the columns returned.

Practice this question →
106
MCQhard

A SOC team wants to use Microsoft Sentinel to detect when a user logs in from a new country not previously seen for that user. They have the SigninLogs table. Which KQL function is most appropriate to build this anomaly detection?

A.timechart()
B.make_set() with lookup
C.dcount()
D.startofday()
AnswerB

make_set() creates an array of previously seen countries per user. Using a join or lookup operation, you can compare a new login's country against that set to detect anomalies.

Why this answer

The `make_set()` function creates a dynamic array of distinct values (e.g., countries) per user over a specified time window. By using `lookup` to compare the current sign-in's country against the historical set, you can flag logins from countries not previously seen. This directly implements the 'new country' anomaly detection pattern in KQL.

Exam trap

Microsoft often tests the distinction between aggregate functions that return counts (`dcount`) versus those that return the actual set of values (`make_set`), leading candidates to choose `dcount` when they need to compare individual values against a historical list.

How to eliminate wrong answers

Option A is wrong because `timechart()` is a rendering function used to plot time-series data visually; it does not perform set-based anomaly detection or comparison logic. Option C is wrong because `dcount()` returns an approximate distinct count of values, not the actual set of values needed to check if a specific country has been seen before. Option D is wrong because `startofday()` is a datetime function that truncates timestamps to the start of the day; it has no capability to build or compare historical sets of countries.

Practice this question →
107
MCQeasy

A SOC analyst needs to create a custom alert in Microsoft Sentinel that triggers when a specific user logs in from an unusual geographic location, compared to a learned baseline of normal locations. Which type of analytics rule is best suited for this scenario?

A.Scheduled query
B.Near-real-time (NRT) rule
C.Anomaly detection rule (machine learning)
D.Fusion rule
AnswerC

Correct: This rule type uses ML to learn normal patterns and trigger alerts on deviations.

Why this answer

Option C is correct because anomaly detection rules in Microsoft Sentinel use machine learning to establish a baseline of normal user behavior, such as typical geographic login locations. When a login event deviates significantly from this learned baseline, the rule triggers an alert. This is the only rule type specifically designed for detecting behavioral anomalies without requiring static thresholds or predefined patterns.

Exam trap

The trap here is that candidates often confuse scheduled queries (Option A) with anomaly detection, assuming a KQL query using 'where Location != 'US'' can replace ML-based baseline learning, but scheduled queries cannot dynamically adapt to changing user behavior over time.

How to eliminate wrong answers

Option A is wrong because scheduled queries run on a fixed schedule (e.g., every 5 minutes) and rely on static KQL queries with hardcoded thresholds or lists, not on a learned baseline of normal locations. Option B is wrong because near-real-time (NRT) rules process streaming data with minimal latency but still require explicit query logic and cannot adaptively learn a baseline of normal behavior. Option D is wrong because Fusion rules correlate alerts from multiple security products to detect multi-stage attacks, not to detect single-user geographic anomalies against a learned baseline.

Practice this question →
108
MCQeasy

A security operations center (SOC) uses Microsoft Sentinel. The team wants to automatically assign incidents to the appropriate analyst based on the severity level of the alert. Which feature should be configured to achieve this automation?

A.Automation rules
B.Playbooks
C.Analytics rules
D.Watchlists
AnswerA

Automation rules can automatically assign incidents to analysts based on criteria like severity, reducing manual triage effort.

Why this answer

Automation rules in Microsoft Sentinel allow you to define conditions (such as alert severity) and corresponding actions (like assigning an incident to a specific analyst or group) without requiring custom code. This directly meets the SOC's requirement to automatically route incidents based on severity levels, as automation rules can trigger on incident creation or update and perform assignment actions.

Exam trap

The trap here is that candidates often confuse playbooks with automation rules, thinking playbooks are required for any automated action, but automation rules handle simple, condition-based assignments natively without needing a Logic App.

How to eliminate wrong answers

Option B is wrong because playbooks are automated workflows (often using Azure Logic Apps) that execute complex, multi-step responses, but they are not the primary feature for simple, rule-based assignment; they are typically triggered by automation rules for advanced orchestration. Option C is wrong because analytics rules are used to generate alerts and incidents from data sources (e.g., KQL queries), not to manage incident assignment or routing after creation. Option D is wrong because watchlists are collections of static data (e.g., IP addresses, usernames) used for correlation or enrichment in analytics rules, not for automating incident assignment actions.

Practice this question →
← PreviousPage 2 of 2 · 108 questions total

Ready to test yourself?

Try a timed practice session using only Mitigate Threats Using Microsoft Sentinel questions.

Start 20-question session