Knowledge + Practice

CCNA Mitigate threats using Microsoft Sentinel Questions

75 of 108 questions · Page 1/2 · Mitigate threats using Microsoft Sentinel · Answers revealed

Practice these questions Domain overview All questions

1

MCQhard

A SOC team uses Microsoft Sentinel with multiple workspaces distributed across different regions. They need to create a single analytics rule that can query data from multiple workspaces to detect cross-tenant attacks. What is the recommended approach?

A.Create separate analytics rules for each workspace

B.Use cross-workspace queries in a single analytics rule with the workspace() function

C.Create a union workspace that ingests data from all workspaces

D.Use Azure Lighthouse to manage multiple workspaces and create rules on each

AnswerB

The KQL workspace() function allows a single analytics rule to query tables from multiple Log Analytics workspaces, enabling cross-workspace detection.

Why this answer

The recommended approach is to use cross-workspace queries in a single analytics rule with the workspace() function. This allows the rule to query data from multiple Sentinel workspaces in different regions without duplicating rules or ingesting data centrally. The workspace() function enables a single KQL query to reference tables from up to 100 workspaces, making it ideal for detecting cross-tenant attacks across distributed environments.

Exam trap

The trap here is that candidates may think Azure Lighthouse alone solves the problem, but it only provides management plane access; the actual query logic still requires the workspace() function to combine data in a single rule.

How to eliminate wrong answers

Option A is wrong because creating separate analytics rules for each workspace would require managing multiple rules, increasing complexity and failing to correlate events across workspaces in a single detection. Option C is wrong because creating a union workspace that ingests data from all workspaces would require duplicating data ingestion, increasing costs and latency, and is not a native Sentinel feature for cross-workspace queries. Option D is wrong because Azure Lighthouse provides cross-tenant management capabilities but does not allow a single analytics rule to query multiple workspaces; rules must still be created per workspace or use cross-workspace queries.

Practice this question →

2

MCQmedium

A SOC analyst is creating a scheduled analytics rule in Microsoft Sentinel to detect brute-force attacks on Microsoft Entra ID. The rule should generate an incident when a single user account fails to authenticate more than 10 times in 5 minutes from the same IP address. Which KQL operator is most appropriate to aggregate the count of failed sign-ins?

A.summarize

B.extend

C.project

D.where

AnswerA

summarize groups data by the specified columns (e.g., UserPrincipalName, IPAddress) and calculates an aggregate like count(), which is essential for detecting the threshold.

Why this answer

The `summarize` operator is the correct choice because it aggregates data into groups based on specified criteria, such as counting the number of failed sign-ins per user and IP address within a time window. In this scenario, you need to count events where `ResultType` indicates failure (e.g., 50053 or 50057), grouped by `UserPrincipalName` and `IPAddress`, and then filter for counts exceeding 10. The `summarize` operator with `count()` directly provides this aggregation, enabling the rule to trigger an incident when the threshold is met.

Exam trap

Microsoft often tests the distinction between row-level operators (`extend`, `project`, `where`) and aggregation operators (`summarize`, `make-series`), and the trap here is that candidates mistakenly choose `where` thinking it can count events by filtering for a threshold, but `where` only filters rows and cannot aggregate across multiple rows to produce a count.

How to eliminate wrong answers

Option B (`extend`) is wrong because it creates new calculated columns or modifies existing ones but does not perform any aggregation; it operates on individual rows, not groups, so it cannot count events across multiple rows. Option C (`project`) is wrong because it selects or reorders columns without any aggregation capability; it is used to shape the output, not to summarize data. Option D (`where`) is wrong because it filters rows based on a condition but does not group or count; it can only reduce the dataset to rows meeting a predicate, such as failed sign-ins, but cannot produce a count per user and IP.

Practice this question →

3

MCQeasy

A SOC analyst needs to create a basic analytics rule in Microsoft Sentinel to detect when an Azure VM is created with an open management port (e.g., SSH or RDP). Which data source should the analyst configure to get the VM creation events?

A.Azure Activity log (AzureActivity)

B.Azure Security Center alerts (SecurityAlert)

C.Microsoft Entra ID Audit logs (AuditLogs)

D.Azure Network Watcher logs (NetworkMonitoring)

AnswerA

The AzureActivity table, ingested via the Azure Activity connector, contains events such as VM creation, which can be used to detect open management ports.

Why this answer

The Azure Activity log (AzureActivity) captures all control-plane operations on Azure resources, including virtual machine creation events (e.g., Microsoft.Compute/virtualMachines/write). When a VM is created with an open management port like SSH (22) or RDP (3389), the activity log records the deployment details, making it the correct data source for triggering a basic analytics rule in Microsoft Sentinel to detect such events.

Exam trap

The trap here is that candidates often confuse Azure Activity logs with Azure Security Center alerts, mistakenly thinking that security alerts will fire on VM creation events, when in fact Activity logs are the only source for raw control-plane operations in Sentinel.

How to eliminate wrong answers

Option B is wrong because Azure Security Center alerts (SecurityAlert) are generated from security findings after resource creation, not from the raw creation event itself, and cannot be used to detect the initial VM creation action. Option C is wrong because Microsoft Entra ID Audit logs (AuditLogs) track identity and authentication activities within Entra ID, not Azure resource creation events like VM deployments. Option D is wrong because Azure Network Watcher logs (NetworkMonitoring) capture network-level traffic and diagnostics (e.g., NSG flow logs, connection monitors), not control-plane operations such as VM provisioning.

Practice this question →

4

MCQmedium

A security operations center (SOC) uses Microsoft Sentinel. The team wants to detect anomalous behavior for a specific user account that typically logs in only during business hours from a known IP range. They create a scheduled analytics rule that queries the SigninLogs table for logins outside that range or outside business hours. To reduce false positives, which of the following configurations should the analyst apply?

A.Set the alert threshold to 5 occurrences within the query lookback period.

B.Enable entity mapping for the user account to correlate with other data sources.

C.Increase the query scheduling frequency to every 5 minutes from every hour.

D.Group all events into a single alert and set the suppression limit to 1 hour.

AnswerA

Correct. Alert threshold sets a minimum number of matching events required to generate an alert, reducing noise from single anomalous but benign logins.

Why this answer

Option A is correct because setting an alert threshold (e.g., 5 occurrences within the query lookback period) reduces false positives by requiring the anomalous behavior to be persistent rather than a single outlier. In Microsoft Sentinel, the alert threshold filters out noise from occasional legitimate logins that might accidentally fall outside business hours or the known IP range, ensuring the rule only fires when the pattern is repeated enough to indicate a real threat.

Exam trap

The trap here is that candidates confuse alert suppression (which reduces duplicates) with alert threshold (which reduces false positives by requiring multiple occurrences), leading them to choose options like D that manage alert volume but do not filter out low-confidence events.

How to eliminate wrong answers

Option B is wrong because entity mapping does not reduce false positives; it enriches alerts with additional context (e.g., linking to user entities) for investigation but does not filter out low-confidence events. Option C is wrong because increasing the query scheduling frequency to every 5 minutes would generate more frequent alerts, potentially increasing false positives and noise, not reducing them. Option D is wrong because grouping events into a single alert with a suppression limit of 1 hour only prevents duplicate alerts for the same detected pattern; it does not address the underlying false-positive rate from single anomalous logins.

Practice this question →

5

Multi-Selectmedium

A SOC team in Microsoft Sentinel wants to automatically assign high-severity incidents to the 'SOC Tier 2' group and automatically close low-severity incidents that have not been updated in 7 days. Which two configuration elements are required in a single automation rule?

Select 2 answers

A.One condition for 'Severity equals High' with action 'Assign to SOC Tier 2' and add another condition for 'Severity equals Low' AND 'Last update time older than 7 days' with action 'Close incident'.

B.Create one rule for high severity assignments and another rule for low severity closure; you cannot combine different actions in one rule.

C.Use a condition 'Severity is one of High, Low' and then use a playbook that checks the severity and applies the appropriate action.

D.Set the automation rule to trigger on incident creation and then use a custom action to assign owner, but closure cannot be automated in an automation rule.

AnswersA, C

This correctly uses two conditions in a single rule to handle both scenarios. However, note that conditions are evaluated with OR logic; each condition triggers its own actions.

Why this answer

Option A is correct because a single Microsoft Sentinel automation rule can include multiple conditions using AND/OR logic, and each condition can trigger a different action (e.g., assign or close). This allows the SOC team to handle both high-severity assignment and low-severity auto-closure within one rule, meeting the requirement efficiently.

Exam trap

The trap here is that candidates may think automation rules can only have one condition or action per rule, but Microsoft Sentinel allows multiple conditions (with AND/OR) and multiple actions in a single rule, enabling complex workflows without playbooks.

Practice this question →

6

MCQmedium

A SOC team uses Microsoft Sentinel and ingests Windows Security Events from domain controllers using the Azure Monitor Agent (AMA). They want to create a scheduled analytics rule that generates an incident when a user account is created in a sensitive Active Directory group (e.g., Domain Admins) outside of approved change windows (e.g., after 9 PM). The required event IDs are 4728 (member added to security-enabled global group) and 4732 (member added to security-enabled local group). Which KQL query should the analyst use to filter for these specific events and the targeted group?

A.SecurityEvent | where EventID in (4728, 4732) | where TargetAccount contains 'Domain Admins'

B.SecurityEvent | where EventID == 4624 | where Account contains 'Admin'

C.SecurityEvent | where EventID == 4738 | where TargetAccount contains 'Domain Admins'

D.SecurityEvent | where EventID == 4670 | where ObjectName contains 'Domain Admins'

AnswerA

EventIDs 4728 and 4732 log member additions to security groups. Filtering by TargetAccount containing the group name isolates the desired group.

Why this answer

Option A is correct because it uses the `SecurityEvent` table with the `EventID` filter for 4728 and 4732, which are the exact event IDs for member additions to security-enabled global and local groups. The `TargetAccount` field contains the name of the group being modified, so filtering for 'Domain Admins' correctly identifies when a user is added to that sensitive group. This query directly matches the requirement to detect account creation in a sensitive AD group outside approved change windows.

Exam trap

The trap here is that candidates often confuse EventID 4738 (user account changed) or 4624 (logon) with group membership events, or they incorrectly assume the TargetAccount field contains the user account being added rather than the group name.

How to eliminate wrong answers

Option B is wrong because EventID 4624 corresponds to a successful logon event, not a group membership change, and filtering for 'Admin' in the Account field is too broad and unrelated to the target group. Option C is wrong because EventID 4738 is for a user account being changed (e.g., password reset or attribute modification), not for adding a member to a group. Option D is wrong because EventID 4670 is for permissions on an object being changed (e.g., ACL modification), not for group membership additions, and the ObjectName field does not reliably capture the group name in this context.

Practice this question →

7

MCQmedium

A SOC analyst wants to create a Microsoft Sentinel scheduled analytics rule that alerts when a user from a critical department (e.g., Finance) logs on from an IP address that is not in the company's approved IP address ranges. The analyst has an Azure Sentinel watchlist named 'FinanceApprovedIPs' containing the allowed IP ranges. Which KQL operator should be used in the rule's query to efficiently check if the IP address from SigninLogs falls within any of the watchlist ranges?

A.join kind=inner (watchlist) on $left.IPAddress $right.IPRange with condition using ipv4_is_in_range() or ipv4_lookup()

B.where IPAddress has any (watchlist)

C.where IPAddress in (watchlist)

D.where IPAddress startswith (watchlist)

AnswerA

This pattern joins the sign-in data with the watchlist and uses IP range comparison functions to check if the IP falls within any allowed range.

Why this answer

Option A is correct because the `ipv4_lookup()` function (or `ipv4_is_in_range()` used with a join) is specifically designed to efficiently check whether an IP address falls within a range defined in a watchlist. In Microsoft Sentinel, watchlists store data as tables, and `ipv4_lookup()` performs a range-based lookup using CIDR notation, which is far more efficient than string-based or exact-match operators. This allows the query to match the `IPAddress` from `SigninLogs` against the `IPRange` column in the `FinanceApprovedIPs` watchlist without iterating over every possible address.

Exam trap

The trap here is that candidates often confuse string-based operators like `has`, `in`, or `startswith` with IP-specific functions, failing to recognize that IP range matching requires subnet-aware logic (CIDR) rather than simple text comparison.

How to eliminate wrong answers

Option B is wrong because the `has` operator performs a substring search, not an IP range match; it would incorrectly match partial strings (e.g., '10.0.0.1' would match '10.0.0.15') and cannot evaluate CIDR ranges. Option C is wrong because the `in` operator performs exact string matching, which cannot handle IP ranges or CIDR notation; it would only match if the IP address literally equals a watchlist entry (e.g., '192.168.1.0/24' would never match '192.168.1.5'). Option D is wrong because `startswith` checks if the IP address string begins with a specified prefix, which is not suitable for range-based matching and would produce false positives (e.g., '10.0.0.1' would match '10.0.0.0/24' but also '10.0.0.100' incorrectly).

Practice this question →

8

Multi-Selecthard

A SOC analyst needs to create a custom watchlist in Microsoft Sentinel to use in an analytics rule. Order the following steps from first to last to correctly create and use the watchlist (Choose 4.)

Select 4 answers

A.1. Create a new watchlist in Microsoft Sentinel (e.g., from Sentinel > Watchlists > Add new).

B.2. Import a CSV file containing the data (e.g., IP addresses or domains) into the watchlist.

C.3. Write the KQL query for the analytics rule that uses the `_GetWatchlist('WatchlistAlias')` function to reference the watchlist.

D.4. Create a scheduled analytics rule, paste the KQL query, and configure the alert details (e.g., severity, entity mapping).

AnswersA, B, C, D

First step: define the watchlist name, alias, and data source.

Why this answer

Option A is correct because creating a new watchlist in Microsoft Sentinel is the initial step to define a custom data source for threat intelligence or reference data. This is done via Sentinel > Watchlists > Add new, where you specify the alias, description, and other metadata before uploading data. Without this step, there is no container to import the CSV file into, making it the logical first action.

Exam trap

The trap here is that candidates might think the KQL query must be written before importing the CSV, but the watchlist alias must already exist in Sentinel for the _GetWatchlist function to reference it correctly, making the import step second.

How to eliminate wrong answers

All options A, B, C, and D are correct steps in the correct order, so there are no wrong options to eliminate. The question asks to order the steps from first to last, and the provided sequence (A → B → C → D) is accurate: create the watchlist, import the CSV, write the KQL query using _GetWatchlist, then create the scheduled analytics rule with that query.

Practice this question →

9

MCQeasy

A security analyst wants to create a custom detection rule in Microsoft Sentinel that alerts when a user logs in from an IP address that is not in the company's approved IP range. The analyst has an existing watchlist named 'ApprovedIPs' containing the allowed ranges. Which KQL operator should the analyst use to compare the IP address from the SigninLogs table against the watchlist?

A.join

B.lookup

C.evaluate

D.where

AnswerB

Correct. The 'lookup' operator seamlessly enriches query results with data from a watchlist, making it ideal for comparing IP addresses against known approved ranges.

Why this answer

The `lookup` operator is the correct choice because it is specifically designed to enrich or filter data in one table based on a dimension table (like a watchlist) without requiring a full merge of columns. In this scenario, the analyst needs to compare IP addresses from the SigninLogs table against the ApprovedIPs watchlist to find logins from non-approved ranges, and `lookup` performs this efficiently by matching on a key field (the IP address) and returning only rows that do not have a match in the watchlist when used with a `kind=leftanti` parameter.

Exam trap

The trap here is that candidates often confuse `lookup` with `join` because both can combine data from two sources, but `lookup` is the correct operator for watchlist-based enrichment in Microsoft Sentinel, while `join` is overkill and less efficient for this specific use case.

How to eliminate wrong answers

Option A is wrong because `join` merges two tables based on a key, but it requires both tables to be fully materialized in the query and can introduce performance overhead and duplicate rows; it is not optimized for simple lookups against a small dimension table like a watchlist. Option C is wrong because `evaluate` is used to invoke plugins or functions (e.g., `evaluate bag_unpack()`) and is not an operator for comparing data between tables or watchlists. Option D is wrong because `where` is a filtering operator that evaluates a Boolean expression on a single table; it cannot directly reference or compare against an external watchlist without first using another operator to bring the watchlist data into the query context.

Practice this question →

10

MCQhard

Arrange the steps in the correct order to create and save a custom hunting query in Microsoft Sentinel.

A.Open the Microsoft Sentinel workspace in the Azure portal → Navigate to the Hunting blade in the Sentinel menu → Click on the 'New Query' button → Write the KQL query in the query editor → Run the query to verify results → Save the query with a meaningful name and description

B.Verify results before configuring the source or rule settings.

C.Configure alert grouping before defining the detection query or source.

D.Skip validation and enable the rule or plan immediately.

AnswerA

This order follows the required configuration sequence and verifies the result last.

Why this answer

Option A is correct because creating a custom hunting query in Microsoft Sentinel requires first accessing the workspace, then navigating to the Hunting blade, clicking 'New Query', writing the KQL query, running it to validate results, and finally saving it with a meaningful name and description. This sequence ensures the query is tested before being stored, aligning with Sentinel's workflow for ad-hoc threat hunting.

Exam trap

The trap here is that candidates confuse the workflow for creating an analytics rule (which involves configuring source, alert grouping, and rule settings) with the simpler, validation-focused process for creating a hunting query, leading them to select options B, C, or D that describe rule creation steps rather than hunting query steps.

How to eliminate wrong answers

Option B is wrong because it describes verifying results before configuring source or rule settings, which is irrelevant to creating a hunting query—hunting queries are not tied to alert rules or data sources; they are standalone KQL searches. Option C is wrong because alert grouping is a configuration step for analytics rules, not for hunting queries; hunting queries do not involve alert grouping or detection logic. Option D is wrong because skipping validation and enabling the rule or plan immediately ignores the necessary step of running the query to verify its syntax and results, which is critical for ensuring the query returns meaningful data before saving.

Practice this question →

11

MCQeasy

A SOC analyst wants to create a scheduled analytics rule in Microsoft Sentinel that runs every hour and detects multiple failed user login attempts from a single IP address within a 5-minute window. Which KQL function should be used in the query to group the failed events by 5-minute time intervals?

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

B.summarize count() by IPAddress, TimeGenerated

C.extend interval = datetime_diff('minute', TimeGenerated, ago(5m))

D.scan with (match all events within 5m by IPAddress)

AnswerA

Correct. bin() creates 5-minute buckets for time-based aggregation.

Why this answer

Option A is correct because the `bin()` function in KQL is specifically designed to group data into fixed-size time buckets, such as 5-minute intervals. By using `summarize count() by IPAddress, bin(TimeGenerated, 5m)`, the query counts failed login attempts per IP address within each 5-minute window, which directly meets the requirement for a scheduled rule that detects multiple failures from a single IP in a 5-minute period.

Exam trap

The trap here is that candidates often confuse the `bin()` function with simple grouping by timestamp (Option B) or mistakenly think that `datetime_diff` (Option C) can be used to group events, when in fact only `bin()` provides the correct fixed-interval bucketing required for time-windowed aggregations.

How to eliminate wrong answers

Option B is wrong because it groups by the exact `TimeGenerated` value (including seconds and milliseconds), not by 5-minute intervals, so it would produce separate counts for each individual timestamp rather than aggregating over the desired window. Option C is wrong because `datetime_diff` calculates the difference between two timestamps, but it does not group or bucket events; it only returns a scalar value for each row, making it unsuitable for aggregating events into time intervals. Option D is wrong because the `scan` operator is used for sequence analysis (e.g., detecting patterns across ordered events), not for simple time-based grouping; it is overly complex and not designed for bucketing by fixed time intervals.

Practice this question →

12

MCQhard

A security analyst is configuring Microsoft Sentinel scheduled analytics rules to detect brute-force attacks on Microsoft Entra ID. Arrange the steps in the correct order from first to last.

A.Create a query using KQL to count failed sign-ins. → Set the rule schedule (run every 5 minutes). → Set the alert threshold (e.g., >5 failed sign-ins from same IP in 5 minutes). → Define incident properties (title, severity, tactics). → Configure grouping settings to group alerts into incidents.

B.Verify results before configuring the source or rule settings.

C.Configure alert grouping before defining the detection query or source.

D.Skip validation and enable the rule or plan immediately.

AnswerA

This order follows the required configuration sequence and verifies the result last.

Why this answer

Option A is correct because the standard workflow for creating a scheduled analytics rule in Microsoft Sentinel begins with defining the detection logic via a KQL query, then configuring the schedule and threshold, followed by incident properties and grouping settings. This sequence ensures the rule has a valid query before setting operational parameters like run frequency and alert aggregation.

Exam trap

The trap here is that candidates often assume alert grouping or incident configuration can be done before the detection query is written, but Microsoft Sentinel requires the query to be defined first because grouping settings depend on the query's output schema.

How to eliminate wrong answers

Option B is wrong because verifying results (e.g., via the 'Run Query' button) should occur after the query is written, not before configuring the source or rule settings; the order implies skipping essential configuration steps. Option C is wrong because alert grouping (how alerts are combined into incidents) must be configured after the detection query and threshold are defined, as grouping depends on the alert output structure. Option D is wrong because skipping validation and enabling the rule immediately violates best practices; validation (testing the query and reviewing alerts) is critical to avoid false positives or missed detections.

Practice this question →

13

MCQmedium

A SOC analyst is creating a Microsoft Sentinel scheduled analytics rule to detect failed sign-in attempts from a specific list of known malicious IP addresses. The IP addresses are stored in a CSV file that is updated weekly. The analyst uploads the file as a new table in the Log Analytics workspace. Which KQL operator should the analyst use to reference this table within the rule's query?

A.Use the custom table name directly in the query, e.g., 'MaliciousIPs_CL'.

B.Use 'externaldata()' to point to the CSV file in Azure Blob storage.

C.Use 'union' with the workspace name to include the CSV data.

D.Use 'watchlist' function, because CSV files are automatically treated as watchlists.

AnswerA

Once the CSV is ingested as a custom table (with '_CL' suffix), it can be referenced directly like any other table.

Why this answer

Option A is correct because when a CSV file is uploaded as a new table in the Log Analytics workspace, it becomes a custom table with a '_CL' suffix (e.g., 'MaliciousIPs_CL'). The analyst can then reference this table directly in the KQL query, just like any other table in the workspace. This is the standard method for using custom log data ingested via the Log Analytics agent or direct upload.

Exam trap

The trap here is that candidates may confuse the 'externaldata()' operator (used for ad-hoc queries on external files) with the direct table reference for already-ingested custom logs, or assume that any uploaded CSV becomes a watchlist, when in fact watchlists require explicit creation and are accessed via a dedicated function.

How to eliminate wrong answers

Option B is wrong because 'externaldata()' is used to query data from external storage (like Azure Blob or ADLS) without ingesting it into the workspace, but the CSV has already been uploaded as a table, so externaldata() is unnecessary and would bypass the ingested table. Option C is wrong because 'union' is used to combine results from multiple tables or queries, not to reference a single table; the custom table can be queried directly without union. Option D is wrong because CSV files are not automatically treated as watchlists; watchlists are a separate feature in Microsoft Sentinel that must be explicitly created and managed via the watchlist UI or API, and they are accessed using the '_GetWatchlist()' function, not by direct table reference.

Practice this question →

14

MCQmedium

A SOC team ingests Microsoft 365 Defender advanced hunting data into Microsoft Sentinel. They want to create a scheduled analytics rule that detects when a user receives more than 5 emails from an external sender containing a specific attachment name within 1 hour. Which KQL tables and approach should the analyst use?

A.EmailEvents and EmailAttachmentInfo; summarize count() by AccountUpn, AttachmentFileName, bin(Timestamp,1h)

B.EmailEvents and EmailUrlInfo; summarize count() by SenderObjectId

C.EmailEvents only; filter by AttachmentFileName

D.EmailPostDeliveryEvents; summarize count() by RecipientEmailAddress

AnswerA

EmailEvents provides email metadata like sender and recipient; EmailAttachmentInfo provides the file name. Joining these and counting by recipient and filename with a 1-hour bin is the correct approach.

Why this answer

Option A is correct because the detection requires joining EmailEvents (which contains sender/recipient metadata) with EmailAttachmentInfo (which contains attachment file names) to filter by external senders and a specific attachment name, then using summarize count() with bin(Timestamp,1h) to group events into 1-hour windows and identify users receiving more than 5 such emails. This approach directly maps to the requirement: external sender, attachment name, user identity (AccountUpn), and time-based aggregation.

Exam trap

The trap here is that candidates often assume EmailEvents contains all email data including attachments, but attachment details are stored in a separate table (EmailAttachmentInfo) and require a join to access the file name.

How to eliminate wrong answers

Option B is wrong because EmailUrlInfo contains URL data, not attachment names, and summarizing by SenderObjectId does not capture the recipient user or attachment name. Option C is wrong because EmailEvents alone does not include attachment file names; that data resides in EmailAttachmentInfo, so filtering by AttachmentFileName on EmailEvents is invalid. Option D is wrong because EmailPostDeliveryEvents tracks post-delivery actions (like phishing report or delete), not the original email receipt or attachment metadata, and summarizing by RecipientEmailAddress ignores the attachment name and external sender filter.

Practice this question →

15

MCQhard

A SOC analyst is configuring a multi-region deployment of Microsoft Sentinel. The requirement is to ingest security logs from Azure resources located in three different Azure regions. The analyst needs to create the workspace in one region and then use cross-workspace queries to view data from all regions. What is the correct sequence of steps?

A.Step 1: Create Log Analytics workspaces in each region. Step 2: Enable Sentinel on each workspace. Step 3: Connect data sources. Step 4: Configure cross-workspace queries.

B.Step 1: Enable Sentinel in one region. Step 2: Create workspaces in other regions. Step 3: Connect data sources. Step 4: Configure cross-workspace queries.

C.Step 1: Connect data sources. Step 2: Create workspaces. Step 3: Enable Sentinel. Step 4: Configure cross-workspace queries.

D.Step 1: Create a central workspace. Step 2: Enable Sentinel on it. Step 3: Connect data sources from all regions to the central workspace. Step 4: Configure cross-workspace queries.

AnswerA

Correct. This sequence ensures all prerequisites are met before configuring queries.

Why this answer

Option A is correct because to use cross-workspace queries in Microsoft Sentinel, you must first create a Log Analytics workspace in each region, enable Sentinel on each workspace, connect the data sources to their respective regional workspaces, and then configure cross-workspace queries to unify the data. This sequence ensures that each region's logs are ingested locally, which is required for cross-workspace queries to reference them via the `workspace()` expression.

Exam trap

The trap here is that candidates often assume a single central workspace can ingest logs from all regions, but the question explicitly requires using cross-workspace queries, which necessitates separate workspaces per region.

How to eliminate wrong answers

Option B is wrong because you cannot enable Sentinel on a workspace that does not yet exist; the workspace must be created first before Sentinel can be enabled on it. Option C is wrong because data sources cannot be connected before the workspaces are created and Sentinel is enabled, as the data connectors depend on the workspace and Sentinel being provisioned. Option D is wrong because connecting all data sources from multiple regions to a single central workspace violates the requirement to ingest logs from each region into their own regional workspace, and cross-workspace queries are used to query across separate workspaces, not within a single workspace.

Practice this question →

16

Multi-Selectmedium

Which of the following detection scenarios can be implemented using a scheduled analytics rule in Microsoft Sentinel? (Select all that apply.) (Choose 2.)

Select 2 answers

A.Identifying sign-ins from IP addresses listed in a custom threat intelligence watchlist.

B.Detecting anomalous sign-in behavior based on user entity behavior.

C.Correlating Windows Security Events to detect brute-force attacks.

D.Automatically blocking malicious IPs on a firewall.

AnswersA, C

Scheduled rules can reference watchlists in KQL queries to match sign-in IPs against threat intelligence.

Why this answer

Option A is correct because scheduled analytics rules in Microsoft Sentinel can be configured to run queries at regular intervals, and these queries can reference watchlists, including custom threat intelligence watchlists. By querying sign-in logs and joining them with a watchlist of known malicious IPs, the rule can identify sign-ins from those IPs and generate alerts. This is a common pattern for leveraging external threat intelligence within Sentinel's detection capabilities.

Exam trap

The trap here is that candidates may confuse detection scenarios with response actions, or assume that all behavioral detection (like UEBA) can be done with scheduled rules, when in fact scheduled rules are only for static, query-based detection, not for machine learning or automated remediation.

Practice this question →

17

MCQeasy

A SOC analyst is configuring a scheduled analytics rule in Microsoft Sentinel. The rule runs every hour and queries the SigninLogs table for failed sign-ins. The analyst wants to avoid generating multiple incidents for the same user and IP address within a 1-hour window. Which configuration should the analyst use in the 'Incident creation' section of the rule?

A.Set 'Alert per rule run' to 'Single alert per run' and enable 'Grouping' with 'Group all alerts into a single incident' and time window of 1 hour.

B.Set 'Alert per rule run' to 'Every event' and disable grouping.

C.Set 'Alert per rule run' to 'Single alert per run' and disable grouping.

D.Configure the rule to use 'Supply chain' analytics rule type.

AnswerA

This setting ensures that all alerts generated by the rule within the grouping time window are combined into one incident, avoiding duplicate incidents for the same pattern.

Why this answer

Option A is correct because setting 'Alert per rule run' to 'Single alert per run' ensures that all matching query results from a single run are bundled into one alert. Enabling 'Grouping' with 'Group all alerts into a single incident' and a 1-hour time window then merges alerts across multiple runs for the same user and IP into one incident, preventing duplicate incidents within that window. This directly meets the requirement to avoid multiple incidents for the same user and IP within an hour.

Exam trap

The trap here is that candidates often confuse 'Alert per rule run' settings with incident deduplication, mistakenly thinking 'Every event' or disabling grouping will reduce incidents, when in fact only the combination of 'Single alert per run' and enabled grouping with a time window achieves the desired deduplication.

How to eliminate wrong answers

Option B is wrong because 'Every event' generates a separate alert for each row returned by the query, and disabling grouping means each alert becomes its own incident, causing many duplicate incidents for the same user and IP. Option C is wrong because while 'Single alert per run' bundles alerts per run, disabling grouping prevents merging alerts across runs, so each hour's alert would create a new incident for the same user and IP, still generating duplicates. Option D is wrong because 'Supply chain' analytics rule type is not a valid configuration in Microsoft Sentinel; the correct types are 'Scheduled' or 'NRT', and this option is a distractor with no relevance to incident deduplication.

Practice this question →

18

Multi-Selectmedium

A SOC team uses Microsoft Sentinel and wants to automate the response to high-severity incidents. When a new incident of severity 'High' is created, they need to send an email notification to the on-call analyst and assign the incident to that analyst. Which two components must be configured together to achieve this? (Choose the best answer.)

Select 2 answers

A.Scheduled analytics rule and a playbook

B.Automation rule and a playbook

C.Fusion rule and a playbook

D.Watchlist and an automation rule

AnswersB, C

An automation rule can trigger a playbook when specific conditions (e.g., severity High) are met, enabling automated notification and assignment.

Why this answer

Automation rules in Microsoft Sentinel allow you to define triggers based on incident creation or update, including severity conditions. By configuring an automation rule to trigger when a 'High' severity incident is created, you can run a playbook that sends an email to the on-call analyst and assigns the incident to them. This combination provides a no-code or low-code automated response without requiring a scheduled or Fusion rule.

Exam trap

The trap here is that candidates often think a scheduled analytics rule or Fusion rule can directly perform automated actions, but they only generate alerts or incidents; automation rules are the required trigger mechanism to invoke playbooks for response actions.

Practice this question →

19

MCQhard

A SOC analyst wants to create a watchlist in Microsoft Sentinel from a CSV file that contains IP addresses. The analyst needs to configure the watchlist so that it can be efficiently queried using IP address comparison operators (e.g., IP prefix matching). Which data type should be set for the key column?

A.ipaddress

B.string

C.dynamic

D.guid

AnswerA

Correct. The ipaddress data type in KQL allows native IP address functions and efficient comparisons (e.g., subnet matching). Using this type on the watchlist column enables direct use in queries with ipv4_is_match.

Why this answer

The 'ipaddress' data type is correct because it enables Microsoft Sentinel to parse and index the column values as IP addresses, allowing efficient use of IP-specific operators such as 'has_ip_prefix()' for prefix matching. Without this type, the watchlist would treat IPs as plain strings, preventing optimized IP comparison queries.

Exam trap

The trap here is that candidates assume 'string' is sufficient for all text-based data, overlooking that Microsoft Sentinel requires specific data types like 'ipaddress' to enable optimized IP comparison operators and avoid query performance degradation.

How to eliminate wrong answers

Option B is wrong because 'string' would store IP addresses as plain text, forcing the use of string comparison operators (e.g., 'contains') that cannot perform efficient IP prefix matching or leverage IP-specific functions. Option C is wrong because 'dynamic' is used for complex nested data structures (e.g., JSON arrays or objects), not for a simple column of IP addresses, and would require parsing overhead. Option D is wrong because 'guid' is a globally unique identifier format, intended for unique IDs, not for IP addresses, and would not support IP comparison operators.

Practice this question →

20

MCQeasy

A security analyst in Microsoft Sentinel wants to create a scheduled analytics rule to detect repeated failed HTTP requests to an Azure Application Gateway, indicating a possible brute force attack. Which Azure Monitor table should the analyst query to capture the access and error logs from the Application Gateway?

A.AzureActivity

B.AzureDiagnostics

C.AzureMetrics

D.SecurityEvent

AnswerB

Correct: AzureDiagnostics contains diagnostic logs from Azure resources, including Application Gateway access and error logs.

Why this answer

AzureDiagnostics is the correct table because it stores resource-level logs for Azure services, including Application Gateway access and error logs. These logs contain detailed HTTP request data (e.g., client IP, URI, status code) necessary to detect repeated failed requests indicative of a brute force attack. Other tables like AzureActivity, AzureMetrics, or SecurityEvent do not capture this specific HTTP-level telemetry.

Exam trap

The trap here is that candidates confuse AzureActivity (control plane) with diagnostic logs (data plane), or assume AzureMetrics contains detailed HTTP error data when it only stores aggregated performance counters.

How to eliminate wrong answers

Option A is wrong because AzureActivity stores subscription-level control plane audit logs (e.g., resource creation, policy changes), not data plane HTTP access logs from Application Gateway. Option C is wrong because AzureMetrics only stores numerical performance counters (e.g., requests per second, latency) and lacks the detailed request/response fields needed to identify failed HTTP status codes. Option D is wrong because SecurityEvent collects Windows security events (e.g., logon attempts, process creation) from virtual machines, not HTTP traffic logs from a network gateway.

Practice this question →

21

MCQhard

A threat hunter in Microsoft Sentinel writes a KQL query in the Logs blade to find possible data exfiltration. The query uses the CommonSecurityLog table to look for large outbound file transfers from a specific IP address. The analyst wants to include only events where the total bytes sent in a 5-minute window exceed 100 MB. Which KQL operator combination would best achieve this?

A.CommonSecurityLog | where SourceIp == '10.0.0.1' | summarize totalBytes = sum(BytesSent) by bin(TimeGenerated, 5m) | where totalBytes > 100000000

B.CommonSecurityLog | where SourceIp == '10.0.0.1' | extend bin = bin(TimeGenerated, 5m) | where BytesSent > 100000000

C.CommonSecurityLog | where SourceIp == '10.0.0.1' | summarize make_list(BytesSent) by TimeGenerated | where array_length(make_list) > 100000000

D.CommonSecurityLog | where SourceIp == '10.0.0.1' | project BytesSent, TimeGenerated | summarize sum(BytesSent) by bin(TimeGenerated, 5m) | where sum_BytesSent > 100000000

AnswerA

Correct. This groups events by 5-minute windows, sums bytes sent per window, and filters those windows exceeding 100 MB (100000000 bytes).

Why this answer

Option A is correct because it first filters the CommonSecurityLog table for the specific source IP, then uses `summarize` with `bin(TimeGenerated, 5m)` to aggregate total bytes sent in 5-minute windows, and finally filters for windows where the sum exceeds 100 MB (100,000,000 bytes). This correctly implements a time-windowed aggregation to detect large outbound transfers, which is the standard pattern for identifying data exfiltration over a period.

Exam trap

The trap here is that candidates often confuse filtering individual events (Option B) with aggregating over a time window (Option A), or they misuse list functions (Option C) instead of sum aggregation, failing to recognize that data exfiltration detection requires cumulative byte totals over a period, not per-event thresholds.

How to eliminate wrong answers

Option B is wrong because it uses `extend bin = bin(TimeGenerated, 5m)` without any aggregation, then filters individual events where `BytesSent > 100000000` — this looks for single events exceeding 100 MB, not the total over a 5-minute window, missing the requirement for cumulative exfiltration. Option C is wrong because `make_list(BytesSent)` creates a list of all bytes sent per timestamp (not binned), and `array_length(make_list)` returns the number of events, not the sum of bytes; it also incorrectly compares the array length to 100,000,000, which is a count of events, not bytes. Option D is wrong because after `summarize sum(BytesSent) by bin(TimeGenerated, 5m)`, the resulting column is named `sum_BytesSent` by default, but the `where` clause references `sum_BytesSent` — while this syntax is valid in KQL, the option fails to include the initial `where SourceIp == '10.0.0.1'` filter before the `project` step, and the `project` step is unnecessary; more critically, the `where` clause uses the wrong column name (it should be `sum_BytesSent` but the option writes `sum_BytesSent` correctly, so the real issue is that the `project` step discards the `TimeGenerated` column needed for binning, and the filter on IP is missing from the final query as written.

Practice this question →

22

MCQmedium

A SOC analyst is building a scheduled analytics rule in Microsoft Sentinel to detect PowerShell downloads from external IPs. The rule queries the DeviceProcessEvents table from Microsoft Defender for Endpoint forwarded to Sentinel. The analyst wants to reduce alert fatigue by excluding processes initiated by known system accounts (e.g., SYSTEM). Which KQL operator should the analyst use in the query?

A.where InitiatingProcessAccountName !contains "SYSTEM"

B.where InitiatingProcessAccountName !startswith "NT AUTHORITY"

C.where InitiatingProcessAccountName !has "NT AUTHORITY\SYSTEM"

D.where InitiatingProcessAccountName !matches regex "^NT AUTHORITY\\SYSTEM$"

AnswerC

This filters out records where the account name contains the exact substring 'NT AUTHORITY\SYSTEM', effectively excluding the SYSTEM account.

Why this answer

Option C is correct because the `!has` operator performs a case-sensitive substring match, which is the most reliable way to exclude the exact string `NT AUTHORITY\SYSTEM` from the `InitiatingProcessAccountName` field. This ensures that only processes started by the SYSTEM account (as reported by Microsoft Defender for Endpoint) are filtered out, reducing alert fatigue without accidentally excluding other accounts that might contain similar substrings.

Exam trap

The trap here is that candidates often confuse `!contains` (case-insensitive) with `!has` (case-sensitive) or use `!startswith` without accounting for the full account name format, leading to either over-filtering or under-filtering of the SYSTEM account.

How to eliminate wrong answers

Option A is wrong because `!contains` performs a case-insensitive substring match, which could inadvertently exclude accounts with 'SYSTEM' in their name (e.g., 'SYSTEM32' or 'DOMAIN\SYSTEMUSER'), leading to missed detections. Option B is wrong because `!startswith` only checks if the field begins with 'NT AUTHORITY', but the actual account name in the DeviceProcessEvents table is typically formatted as 'NT AUTHORITY\SYSTEM' (with a backslash), so this would not exclude the SYSTEM account if the field starts with 'NT AUTHORITY\' but the operator does not match the full string. Option D is wrong because `!matches regex` is overly precise and can fail if the account name includes a domain or other variations (e.g., 'NT AUTHORITY\SYSTEM' might appear as 'NT AUTHORITY\SYSTEM' with a trailing space or different casing), and regex is unnecessary for this simple exclusion.

Practice this question →

23

MCQmedium

A SOC analyst is creating a scheduled analytics rule in Microsoft Sentinel to detect potential account compromise. The rule should trigger when a user account is created in Microsoft Entra ID and, within one hour, that same account is used to sign in from an unfamiliar location. The queries use the AuditLogs table for account creation and the SigninLogs table for sign-ins. Which KQL operator should be used to correlate these two events from different tables within a specific time window?

A.where

B.join

C.union

D.summarize

AnswerB

Correct. The 'join' operator can combine rows from two tables based on a common key and a time window, enabling correlation of account creation and sign-in events.

Why this answer

The correct answer is B (join) because the scenario requires correlating two events from different tables (AuditLogs and SigninLogs) based on a common field (e.g., UserPrincipalName) and within a specific time window (one hour). The join operator in KQL allows you to combine rows from two tables by matching keys, and you can use the 'where' clause on the time fields to enforce the one-hour window. This is the only operator that supports row-wise correlation across tables with a time constraint.

Exam trap

The trap here is that candidates often confuse union (which stacks rows) with join (which correlates rows), especially when the question mentions 'different tables' and 'time window' — union cannot enforce a time-based relationship between rows from separate tables.

How to eliminate wrong answers

Option A (where) is wrong because the where operator filters rows in a single table based on conditions; it cannot correlate events from two different tables. Option C (union) is wrong because union concatenates rows from multiple tables into a single result set without matching or correlating rows by a common key or time window. Option D (summarize) is wrong because summarize aggregates data (e.g., counts, averages) over groups; it does not perform row-level correlation between two tables.

Practice this question →

24

MCQeasy

A security analyst is configuring a Microsoft Sentinel workspace. The analyst needs to connect a third-party firewall that sends logs via Syslog and supports a common event format (CEF). Which data connector should the analyst use to ingest these logs?

A.Common Event Format (CEF) via AMA

B.Windows Security Events via AMA

C.Azure Activity Log

D.Office 365 connector

AnswerA

This connector ingests CEF-formatted logs from syslog sources.

Why this answer

The Common Event Format (CEF) via AMA data connector is specifically designed to ingest logs from security appliances that send Syslog messages in CEF format. CEF is an industry-standard format that allows firewalls and other devices to send structured event data, and the Azure Monitor Agent (AMA) replaces the older Log Analytics Agent for this purpose. This connector parses the CEF headers and maps the fields to the appropriate Microsoft Sentinel tables, enabling efficient threat detection and analysis.

Exam trap

The trap here is that candidates may confuse the older Log Analytics Agent (which also supports CEF) with the newer AMA-based connector, or mistakenly think that any Syslog connector can handle CEF without the specific parsing logic, leading them to choose a generic Syslog option not listed here.

How to eliminate wrong answers

Option B is wrong because Windows Security Events via AMA is used to collect security logs from Windows machines, not from third-party firewalls sending Syslog/CEF data. Option C is wrong because the Azure Activity Log connector ingests subscription-level events from Azure itself, such as resource creation or policy changes, not external firewall logs. Option D is wrong because the Office 365 connector collects audit and activity logs from Microsoft 365 services like Exchange and SharePoint, not from third-party network devices.

Practice this question →

25

MCQmedium

A SOC team uses Microsoft Sentinel and wants to ingest custom log events from an on-premises Linux application that writes to a local file. The team sets up the Log Analytics agent on the Linux server and configures a data connector. Which of the following is the necessary configuration step to collect the custom log file?

A.Create a Syslog data connector and specify the facility and severity to filter the application logs from /var/log.

B.Configure the Log Analytics agent to collect performance counters for the application process.

C.Use the Custom Logs feature in the Log Analytics workspace to specify the path to the application log file and define the log type name.

D.Deploy a Log Analytics gateway and configure the application to write directly to the gateway using the HTTP Data Collector API.

AnswerC

Correct. Custom Logs allow ingestion of text files by monitoring specified file paths and parsing lines into custom logs.

Why this answer

Option C is correct because the Custom Logs feature in the Log Analytics workspace is specifically designed to ingest text-based log files from on-premises Linux servers via the Log Analytics agent. You must specify the exact file path (e.g., /var/log/myapp.log) and define a custom log type name (e.g., MyApp_CL) to parse the file and send the data to a custom table in the Log Analytics workspace. This is the only method that directly collects custom application log files without requiring syslog or API-based ingestion.

Exam trap

The trap here is that candidates confuse syslog data connectors with custom log file collection, assuming any Linux log file can be ingested via syslog, when in fact syslog only handles logs sent to the syslog daemon, not arbitrary application files.

How to eliminate wrong answers

Option A is wrong because Syslog data connectors collect system logs using the syslog protocol (RFC 5424) from /var/log/syslog or /var/log/messages, not arbitrary application log files; they filter by facility and severity, not by file path. Option B is wrong because performance counters collect metrics like CPU or memory usage, not log file content; they are used for performance monitoring, not log ingestion. Option D is wrong because a Log Analytics gateway is a proxy for forwarding data to Azure, not a collection endpoint; the HTTP Data Collector API requires custom code in the application to send JSON payloads, not file-based collection.

Practice this question →

26

MCQmedium

A SOC analyst needs to create a Microsoft Sentinel scheduled analytics rule that triggers when an Microsoft Entra ID user performs more than 10 failed sign-in attempts from different IP addresses within 15 minutes, using the SigninLogs table. Which KQL query aggregate pattern should be used?

A.SigninLogs | summarize FailedCount = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 15m) | where FailedCount > 10

B.SigninLogs | summarize DistinctIPs = dcount(IPAddress) by UserPrincipalName, bin(TimeGenerated, 15m) | where DistinctIPs > 10

C.SigninLogs | summarize DistinctIPs = count() by UserPrincipalName, IPAddress | where DistinctIPs > 10

D.SigninLogs | where Status contains 'Failed' | summarize by UserPrincipalName, IPAddress | count > 10

AnswerB

This correctly calculates distinct IPs per user per 15-minute bin and filters for more than 10.

Why this answer

Option B is correct because the query uses `dcount(IPAddress)` to count distinct IP addresses per user within a 15-minute time window, then filters for users with more than 10 distinct IPs. This directly matches the requirement to detect failed sign-ins from different IP addresses, not just total failed attempts.

Exam trap

The trap here is that candidates often confuse counting total events with counting distinct values, leading them to pick Option A which counts all failures instead of distinct IPs.

How to eliminate wrong answers

Option A is wrong because it counts total failed sign-ins per user and IP address, not distinct IPs; a user could have 12 failures from the same IP and trigger the rule incorrectly. Option C is wrong because it lacks a time bin, so it aggregates over all historical data instead of the required 15-minute window. Option D is wrong because it uses invalid KQL syntax (`count > 10` is not a valid filter) and does not count distinct IPs or apply a time range.

Practice this question →

27

MCQhard

A security analyst is preparing to use a Jupyter notebook for threat hunting in Microsoft Sentinel. Which of the following sequences of actions is correct to start executing the notebook?

A.Provision compute → Clone Sentinel notebooks → Connect to workspace → Execute cells

B.Clone Sentinel notebooks → Provision compute → Connect to workspace → Execute cells

C.Connect to workspace → Provision compute → Clone Sentinel notebooks → Execute cells

D.Provision compute → Connect to workspace → Clone Sentinel notebooks → Execute cells

AnswerA

This order follows the recommended setup: compute first, then notebooks, then workspace connection, then execution.

Why this answer

Option A is correct because the correct sequence to start executing a Jupyter notebook for threat hunting in Microsoft Sentinel is to first provision compute (i.e., create a compute instance in Azure Machine Learning), then clone the Sentinel notebooks from the official GitHub repository, connect to the Sentinel workspace using the msticpy library, and finally execute the cells. This order ensures the compute environment is ready before loading the notebooks and establishing the workspace connection.

Exam trap

The trap here is that candidates often assume the workspace connection should be established first (as in typical cloud workflows), but in Sentinel notebooks, the compute environment must be ready before any authentication or file operations can occur.

How to eliminate wrong answers

Option B is wrong because cloning Sentinel notebooks before provisioning compute would fail, as there is no compute environment to store or run the notebooks. Option C is wrong because connecting to the workspace before provisioning compute is impossible without a compute instance to authenticate and establish the connection. Option D is wrong because connecting to the workspace before cloning the notebooks would result in missing notebook files to execute, and the connection step requires the notebooks to be present for context.

Practice this question →

28

MCQhard

A SOC analyst is creating an automation rule in Microsoft Sentinel to trigger a playbook when a new incident is created. The analyst wants the rule to apply only to incidents that have a severity of 'High' and where the 'User' entity is present. Which condition configuration should the analyst use?

A.Set 'Incident severity equals High' and 'Incident tag contains User'

B.Set 'Incident severity equals High' and 'Entity type contains User'

C.Set 'Alert severity equals High' and 'Alert entity type contains User'

D.Set 'Incident provider equals Microsoft Sentinel' and 'Entity type contains User'

AnswerB

This correctly uses incident severity and entity type conditions. The rule will trigger only for high-severity incidents that contain a user entity.

Why this answer

Option B is correct because Microsoft Sentinel automation rules evaluate conditions at the incident level, not the alert level. The 'Incident severity equals High' condition filters by incident severity, and 'Entity type contains User' checks that the incident's entities include a User entity, which is required for the playbook to receive entity context.

Exam trap

The trap here is that candidates confuse incident-level conditions (severity, entity type) with alert-level conditions (alert severity, alert entity type), leading them to select Option C, which would not work because automation rules evaluate at the incident scope.

How to eliminate wrong answers

Option A is wrong because 'Incident tag contains User' is not a valid condition; tags are custom labels, not entity types, and cannot be used to verify the presence of a User entity. Option C is wrong because 'Alert severity' and 'Alert entity type' operate at the alert level, not the incident level, and automation rules trigger on incidents, not individual alerts. Option D is wrong because 'Incident provider equals Microsoft Sentinel' is a valid condition but does not filter by severity, and it would apply to all incidents from Microsoft Sentinel regardless of severity or entity presence.

Practice this question →

29

MCQhard

A security analyst is configuring a Microsoft Sentinel playbook to automatically respond to phishing incidents. The playbook should only run when an incident of severity 'High' is created and the incident is not already assigned to a user. Which automation rule condition and trigger configuration should the analyst use?

A.Configure an automation rule with trigger 'When incident is created', conditions for severity equals High and 'Assigned to' is empty, and action to run the playbook.

B.Configure a playbook trigger 'When an incident is updated' and add a condition in the playbook logic app to check severity and assignment.

C.Schedule the playbook to run every 5 minutes and query for new incidents with required properties.

D.Configure an automation rule with trigger 'When incident is created' and only condition for severity equals High; the playbook will handle unassigned checks internally.

AnswerA

This correctly triggers on incident creation with the specified conditions.

Why this answer

Option A is correct because the automation rule trigger 'When incident is created' ensures the playbook runs immediately upon incident creation, and the conditions for severity equals 'High' and 'Assigned to' is empty filter incidents precisely as required. This configuration offloads the filtering to Sentinel's automation rule engine, which is more efficient and reliable than handling it inside the playbook logic.

Exam trap

The trap here is that candidates often think the playbook itself should handle all logic (like checking assignment) via conditions inside the Logic App, but the automation rule's condition engine is designed for this filtering and is more efficient, leading them to choose Option D instead of A.

How to eliminate wrong answers

Option B is wrong because using the trigger 'When an incident is updated' would cause the playbook to run on every update, not just creation, and adding conditions inside the Logic App is less efficient and can introduce latency or missed triggers. Option C is wrong because scheduling a playbook to run every 5 minutes with a query is a polling approach that introduces delay and is not event-driven, violating the requirement for immediate response. Option D is wrong because while the automation rule triggers on creation and filters severity, it does not include the 'Assigned to' condition; relying on the playbook to check assignment internally is less efficient and can cause the playbook to run unnecessarily for assigned incidents, consuming resources and potentially causing unintended actions.

Practice this question →

30

MCQeasy

A security operations analyst is creating a scheduled analytics rule in Microsoft Sentinel to detect brute force attempts on Microsoft Entra ID authentication. Which data source is most appropriate for this rule?

A.Azure Activity Logs

B.SigninLogs

C.Office Activity Logs

D.SecurityEvent

AnswerB

SigninLogs contain successful and failed sign-in events needed to detect brute force attacks.

Why this answer

SigninLogs captures user authentication attempts to Microsoft Entra ID, including failed sign-ins, which are essential for detecting brute force attacks. This data source provides detailed properties such as IP address, application, and status codes (e.g., 50076 for invalid password), enabling accurate detection of repeated failed attempts. Azure Activity Logs, Office Activity Logs, and SecurityEvent do not contain Entra ID authentication events.

Exam trap

The trap here is that candidates often confuse Azure Activity Logs (control plane) with SigninLogs (authentication plane), assuming all Azure-related logs are in Activity Logs, but Entra ID sign-in events are a separate data source.

How to eliminate wrong answers

Option A is wrong because Azure Activity Logs record control-plane operations (e.g., resource creation, role assignments) on Azure resources, not user authentication events to Entra ID. Option C is wrong because Office Activity Logs capture actions within Microsoft 365 services (e.g., SharePoint, Exchange), not Entra ID sign-in attempts. Option D is wrong because SecurityEvent logs Windows security events from on-premises or Azure VMs, such as logon type 3 for network logins, and does not include cloud-based Entra ID authentication.

Practice this question →

31

MCQhard

A SOC analyst needs to write a KQL query for a Microsoft Sentinel scheduled analytics rule that detects impossible travel activity. The rule should alert when a user signs in from two different countries within 60 minutes. The analyst has the SigninLogs table with columns: UserPrincipalName, IPAddress, Location (country), TimeGenerated. Which KQL query pattern correctly triggers an alert for each pair of sign-ins meeting the condition?

A.Self-join SigninLogs on UserPrincipalName, where TimeGenerated difference < 60m and Location != Location, then summarize by bin(TimeGenerated, 1h).

B.Use the `make_list()` function to aggregate all locations per user within a 60-minute window and check if the list has more than one distinct value.

C.Use the `series_decompose()` function to detect outliers in location sequences.

D.Use the `rolling_join()` function to compare each sign-in with the previous one per user.

AnswerA

This pattern correctly identifies pairs and can be used to generate an alert for each pair.

Why this answer

Option A is correct because it uses a self-join on the SigninLogs table to compare each sign-in event with every other sign-in event for the same user (UserPrincipalName). The join condition filters for pairs where the absolute time difference is less than 60 minutes (TimeGenerated difference < 60m) and the locations are different (Location != Location). This directly identifies any two sign-ins from different countries within the 60-minute window, which is the exact definition of impossible travel.

The subsequent summarize by bin(TimeGenerated, 1h) groups the results into hourly buckets to trigger a single alert per detection window, as required by a scheduled analytics rule.

Exam trap

The trap here is that candidates may assume a simple aggregation (like `make_list()`) is sufficient, but they overlook the need for a pairwise comparison with a sliding 60-minute window, which only a self-join can correctly implement in KQL.

How to eliminate wrong answers

Option B is wrong because using `make_list()` to aggregate all locations per user within a 60-minute window and checking for more than one distinct value would only detect that multiple locations exist in that window, but it would not ensure that the sign-ins occurred within 60 minutes of each other (the window is fixed, not sliding) and would not pair specific sign-ins, potentially missing the exact 60-minute constraint or alerting on stale data. Option C is wrong because `series_decompose()` is a time-series decomposition function used for anomaly detection on numerical sequences (e.g., counts over time), not for comparing categorical location data across sign-in events; it cannot detect impossible travel based on pairwise location differences. Option D is wrong because KQL does not have a built-in `rolling_join()` function; the correct approach for comparing each sign-in with the previous one per user would involve the `prev()` function with a partition, not a join, and the option misrepresents the available KQL syntax.

Practice this question →

32

Matchingmedium

Match each Microsoft Sentinel data connector to its data source.

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

Concepts

Matches

Subscription-level events from Azure Resource Manager

Sign-in logs and audit logs from Azure Active Directory

Security events from Windows machines

Events from Linux and network devices

Exchange Online and SharePoint Online logs

Why these pairings

These connectors ingest data into Microsoft Sentinel from common sources.

Practice this question →

33

MCQeasy

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

A.Palo Alto Networks (via Syslog CEF)

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

C.Syslog (without CEF)

D.Custom Text Logs

AnswerA

This connector is pre-built to ingest Palo Alto firewall logs formatted in CEF over Syslog.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

34

MCQmedium

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

A.Incident tag contains

B.Incident severity

C.Alert product name

D.Entity type

AnswerA

This condition matches incidents that include the specified custom tag.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

35

MCQmedium

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

A.Incident grouping settings

B.Entity mapping

C.Alert details

D.Query scheduling

AnswerA

This setting controls how alerts are grouped into incidents, including time-based grouping and entity matching.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

36

MCQmedium

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

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

B.summarize count(UserPrincipalName) by IPAddress

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

D.make-set(UserPrincipalName) by IPAddress

AnswerA

This groups records by IPAddress and 5-minute bins, then counts distinct user accounts for each, which is exactly what is needed.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

37

MCQmedium

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

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

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

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

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

AnswerA

Correct. Automation rules can be configured to trigger when an incident is created and match conditions on entity types (e.g., 'User'). This allows the playbook to run automatically for incidents involving the specified user.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

38

Multi-Selectmedium

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

Select 2 answers

A.Incident severity equals High

B.Incident title contains Phishing

C.Incident status is New

D.Incident owner is Unassigned

AnswersA, B

Correct. This condition filters incidents with severity High.

Why this answer

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

Exam trap

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

Practice this question →

39

MCQeasy

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

A.Scheduled

B.Microsoft Security

C.Fusion

D.Machine Learning (ML)

AnswerA

Correct. The built-in template for detecting additions to the Global Administrator role is a Scheduled rule template that queries AzureADAuditLogs or AuditLogs on a schedule.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

40

Multi-Selecthard

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

Select 2 answers

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

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

C.Disable the data connector.

D.Delete the Log Analytics workspace.

AnswersA, B

Grouping related alerts/incidents reduces duplicate investigation objects.

Why this answer

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

Exam trap

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

Practice this question →

41

MCQhard

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

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

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

C.Use the BehaviorAnalytics table which already identifies new devices

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

AnswerA

Correct. By summarizing the earliest sign-in time for each user-device pair and joining back, you can identify sign-ins that are the first for that combination, effectively detecting new device usage.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

42

MCQmedium

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

A.Scheduled query rule

B.Near-real-time (NRT) rule

C.Fusion rule

D.Anomaly rule

AnswerA

Scheduled query rules support custom KQL queries that join multiple tables and can be scheduled at any interval, making them suitable for cross-source correlation.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

43

Drag & Dropmedium

Arrange the steps to configure a Microsoft Sentinel playbook (automation) using Azure Logic Apps.

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

Steps

Order

Why this order

Playbooks are Logic Apps that automate responses; they must be created and then linked to Sentinel automation rules.

Practice this question →

44

MCQmedium

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

A.SigninLogs

B.BehaviorAnalytics

C.IdentityInfo

D.AADUserRiskEvents

AnswerB

Correct. The BehaviorAnalytics table stores enriched behavioral data, including geographic anomalies, device information, and time-based patterns computed by the UEBA engine.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

45

MCQmedium

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

A.externaldata()

B._GetWatchlist()

C.lookup()

D.invoke()

AnswerB

_GetWatchlist() is the built-in function that returns the content of a watchlist by name, allowing the query to join or compare against the watchlist data.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

46

Multi-Selectmedium

A SOC analyst is building a scheduled analytics rule in Microsoft Sentinel to detect when a user is added to a privileged Microsoft Entra ID role (e.g., Global Administrator). Which two tables must be included in the KQL query to capture the role assignment event and to retrieve user details? (Choose 2.)

Select 2 answers

A.AADAuditLogs

B.SigninLogs

C.AzureActivity

D.IdentityInfo

AnswersA, D

Correct. This table logs all Microsoft Entra ID audit activities, including role assignments.

Why this answer

AADAuditLogs captures all directory audit events, including role assignment activities such as adding a user to a privileged Microsoft Entra ID role. This table is essential because it records the 'Add member to role' operation with details like the target user, role name, and initiating actor, which are required to detect the security event.

Exam trap

The trap here is that candidates often confuse SigninLogs (which only records authentication attempts) with AADAuditLogs (which records administrative changes), or they overlook IdentityInfo as a separate table needed for user details, assuming the audit log alone provides all necessary user attributes.

Practice this question →

47

MCQmedium

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

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

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

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

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

AnswerC

ipv4_is_in_range(stringIP, stringRange) evaluates whether the IP is within the CIDR range. By passing the watchlist values, the analyst can match sign-in IPs against the stored ranges.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

48

MCQeasy

A SOC team uses Microsoft Sentinel and needs to ingest custom logs from an on-premises Linux server that writes events to a local text file. The team installs the Azure Monitor Agent (AMA) on the Linux server. Which configuration step is required in Sentinel to collect the custom log file?

A.Create a custom table in the Log Analytics workspace and configure a Data Collection Rule (DCR) to ingest the file

B.Use the Syslog connector and map the file to a facility

C.Install the Log Analytics agent (MMA) and configure Custom Logs in the agent settings

D.Create a scheduled analytics rule that reads the file via an API

AnswerA

AMA uses DCRs to ingest custom logs; you must define the table and transformation.

Why this answer

Option A is correct because Azure Monitor Agent (AMA) requires a Data Collection Rule (DCR) to define the data source (custom log file path) and the destination table in the Log Analytics workspace. Since the log is a custom text file (not syslog or a standard Windows event), you must first create a custom table (using the workspace's schema or via the 'Create custom log' wizard) and then configure the DCR to ingest the file into that table. This is the only supported method for AMA-based custom log ingestion.

Exam trap

The trap here is that candidates confuse the legacy MMA custom log configuration (which used the agent's own settings) with the modern AMA approach, which requires a DCR and a custom table — or they incorrectly assume Syslog can ingest any text file by simply mapping it to a facility.

How to eliminate wrong answers

Option B is wrong because the Syslog connector is designed for standard syslog messages (RFC 3164/5424) sent over UDP/TCP, not for reading arbitrary text files; mapping a file to a facility is not possible and would not parse the custom log format. Option C is wrong because the Log Analytics agent (MMA) is legacy and not recommended for new deployments; the question explicitly states the team installed AMA, so using MMA would be a step backward and incompatible with the stated agent choice. Option D is wrong because scheduled analytics rules query data already in Log Analytics; they cannot directly read files from a server via an API — that would require a custom data connector or a separate ingestion pipeline, not a rule.

Practice this question →

49

MCQmedium

A SOC analyst is creating a scheduled analytics rule in Microsoft Sentinel to detect when a user is added to the Global Administrator role in Microsoft Entra ID. The analyst also needs to capture the user who performed the addition. Which Microsoft Entra ID table should the analyst query in the rule's KQL query?

A.SigninLogs

B.AuditLogs

C.IdentityInfo

D.BehaviorAnalytics

AnswerB

AuditLogs captures directory changes, including role assignment, with information about the actor and target.

Why this answer

The AuditLogs table in Microsoft Entra ID (formerly Azure AD) records all directory-level changes, including role assignments like adding a user to the Global Administrator role. Each audit log entry contains the 'InitiatedBy' property, which captures the user or service principal who performed the action, meeting the analyst's requirement to identify the actor. SigninLogs only tracks authentication events, not administrative changes, making AuditLogs the correct choice for this detection.

Exam trap

The trap here is that candidates confuse SigninLogs (which tracks who logged in) with AuditLogs (which tracks who made a change), assuming the actor's identity is always found in sign-in records rather than in directory audit trails.

How to eliminate wrong answers

Option A is wrong because SigninLogs captures user sign-in events (authentication) and does not include directory modification records such as role assignments. Option C is wrong because IdentityInfo provides user profile and attribute data (e.g., job title, department) but does not log administrative actions or role changes. Option D is wrong because BehaviorAnalytics contains user and entity behavior analytics (UEBA) insights derived from other logs, not raw audit records of role additions.

Practice this question →

50

MCQmedium

A SOC analyst creates a scheduled analytics rule in Microsoft Sentinel to detect anomalous Microsoft Entra ID sign-ins. The rule uses the SigninLogs table and runs every 15 minutes. The analyst wants to alert when a user signs in from a country that is not in the allowed list (['US', 'CA']). Which KQL query pattern should be used in the rule?

A.SigninLogs | where Location.countryOrRegion !in (dynamic(['US','CA']))

B.SigninLogs | where Country !in ('US','CA')

C.SigninLogs | where location != 'US' and location != 'CA'

D.SigninLogs | where geoLocation !in (dynamic(['US','CA']))

AnswerA

Location is a dynamic field containing countryOrRegion. The !in operator with a dynamic array correctly checks for countries not in the allowed list.

Why this answer

Option A is correct because the SigninLogs table stores the sign-in location in the `Location.countryOrRegion` field, which is a nested property of the `Location` dynamic object. The KQL operator `!in` with `dynamic(['US','CA'])` correctly performs a case-sensitive comparison against a list of string values, ensuring that only sign-ins from countries outside the allowed list trigger the alert.

Exam trap

The trap here is that candidates often confuse the flat field name `Country` or `location` with the correct nested property `Location.countryOrRegion`, leading them to choose options that reference non-existent or incorrectly named columns.

How to eliminate wrong answers

Option B is wrong because the `Country` field does not exist in the SigninLogs table; the correct field is `Location.countryOrRegion`. Option C is wrong because it uses the `location` field (which is a string like 'US' or 'CA' but not the correct property path) and the `!=` operator performs a case-sensitive comparison, but more critically it does not use the correct nested field name. Option D is wrong because `geoLocation` is not a valid field in SigninLogs; the correct field is `Location.countryOrRegion`, and the `!in` operator with `dynamic()` is syntactically correct but applied to the wrong column.

Practice this question →

51

MCQeasy

A SOC analyst is creating a new analytics rule in Microsoft Sentinel to detect when a user account is disabled. The analyst needs to select a rule template that uses Microsoft Entra ID audit logs. Which rule type should the analyst choose?

A.Scheduled

B.NRT (Near-Real-Time)

C.Anomaly

D.Fusion

AnswerA

Correct. Scheduled rules query data at regular intervals and can use any table in the workspace, including AuditLogs from Microsoft Entra ID.

Why this answer

A scheduled query rule is the correct choice because it allows the analyst to define a KQL query that runs on a fixed interval (e.g., every 5 minutes) against Microsoft Entra ID audit logs, which are stored in the AuditLogs table. This is the standard approach for detecting patterns like account disable events, as it provides full control over the query logic and scheduling frequency.

Exam trap

The trap here is that candidates often confuse NRT rules with scheduled rules, assuming NRT provides faster detection for all data sources, but NRT rules cannot query AuditLogs because they are limited to tables with high ingestion velocity like CommonSecurityLog or SecurityEvent.

How to eliminate wrong answers

Option B (NRT) is wrong because NRT rules are designed for near-real-time detection with a 1-minute latency and limited KQL functions, but they cannot query Microsoft Entra ID audit logs directly; they are optimized for high-frequency data like security events. Option C (Anomaly) is wrong because anomaly rules use machine learning to detect unusual patterns based on baseline behavior, not static events like account disablement, and they require specific anomaly detection configurations. Option D (Fusion) is wrong because Fusion is a correlation-based rule that automatically combines alerts from multiple sources to detect multi-stage attacks, and it does not allow custom KQL queries against audit logs.

Practice this question →

52

Multi-Selecthard

A SOC analyst in Microsoft Sentinel needs to create an automation rule that triggers a playbook when a new incident is created and the incident severity is 'High'. Additionally, the playbook should only run if the incident is not already assigned to an analyst. Which two conditions must the analyst include in the automation rule? (Select all that apply.) (Choose 2.)

Select 2 answers

A.Condition: 'Severity' equals 'High'

B.Condition: 'Assigned to' equals 'null'

C.Condition: 'Status' equals 'New'

D.Condition: 'Provider' contains 'Microsoft Sentinel'

AnswersA, B

This filters incidents by severity level.

Why this answer

Option A is correct because the automation rule must trigger only when the incident severity is 'High'. In Microsoft Sentinel, automation rules evaluate conditions against incident properties, and the 'Severity' condition filters incidents by their assigned severity level. This ensures the playbook runs exclusively for high-severity incidents, aligning with the SOC's requirement to prioritize critical alerts.

Exam trap

The trap here is that candidates often confuse the 'Status' condition with the 'Assigned to' condition, thinking a 'New' status is necessary, but the automation rule triggers on incident creation by default, and the 'Assigned to' null check is the precise way to enforce the unassigned requirement.

Practice this question →

53

MCQhard

A SOC analyst needs to create an automated response in Microsoft Sentinel that, when a specific type of incident is created, automatically creates a ticket in ServiceNow and blocks the source IP address in Azure Firewall. The analyst already has a playbook that performs these actions. What is the correct configuration to trigger this playbook?

A.Attach the playbook to an automation rule that includes the condition for the target incident type.

B.Configure the playbook to run on a scheduled recurrence every 5 minutes.

C.Add the playbook to the incident's comments as a quick link.

D.Use a separate Power Automate flow with a trigger that watches for new Sentinel incidents.

AnswerA

Correct. Automation rules are the recommended method to trigger playbooks automatically on incident creation or update based on defined conditions.

Why this answer

Automation rules in Microsoft Sentinel are the correct mechanism to trigger a playbook automatically when an incident is created. By attaching the playbook to an automation rule with a condition that matches the specific incident type (e.g., based on incident title or tag), the rule executes the playbook immediately upon incident creation, fulfilling the requirement without manual intervention.

Exam trap

The trap here is that candidates may confuse automation rules (which trigger on incident lifecycle events) with scheduled playbooks or external flows, overlooking that automation rules are the native, event-driven mechanism for incident-triggered automation in Sentinel.

How to eliminate wrong answers

Option B is wrong because configuring the playbook on a scheduled recurrence every 5 minutes would run it periodically regardless of incident creation, leading to unnecessary executions and failing to trigger specifically on new incidents. Option C is wrong because adding the playbook as a quick link in incident comments only provides a manual clickable action for analysts, not an automated trigger. Option D is wrong because while a separate Power Automate flow can watch for new Sentinel incidents via the connector, it is an indirect, less integrated approach compared to using native automation rules, which are the designed and recommended method for automated incident-triggered playbook execution.

Practice this question →

54

Drag & Dropmedium

Order the steps to configure a Microsoft Sentinel analytics rule using a scheduled query.

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

Steps

Order

Why this order

Scheduled query rules run on a schedule and generate alerts based on query results meeting a threshold.

Practice this question →

55

MCQeasy

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

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

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

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

D.Restart the Log Analytics agent on the Linux forwarder

AnswerA

This query quickly reveals if any CommonSecurityLog records have been ingested in the last hour, indicating logs are reaching the workspace.

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

56

MCQeasy

A SOC analyst needs to create a custom scheduled analytics rule in Microsoft Sentinel that detects when a user attempts to sign in from an IP address not in the organization's allowlist. The rule should run every 5 minutes. Which table should the analyst query?

A.SigninLogs

B.AADNonInteractiveUserSignInLogs

C.AuditLogs

D.AzureActivity

AnswerA

SigninLogs captures interactive user sign-in events, which is the correct data source for detecting sign-in attempts from specific IP addresses.

Why this answer

The SigninLogs table in Microsoft Sentinel captures interactive user sign-in events, including the source IP address. Since the rule needs to detect user sign-in attempts from non-allowlisted IPs, SigninLogs is the correct table to query. It provides the necessary fields like UserPrincipalName, IPAddress, and ResultType to build the detection logic.

Exam trap

The trap here is that candidates may confuse AuditLogs or AzureActivity with sign-in logs, but only SigninLogs contains the interactive user sign-in data with source IP addresses needed for this detection.

How to eliminate wrong answers

Option B is wrong because AADNonInteractiveUserSignInLogs captures non-interactive sign-ins (e.g., service-to-service authentication), not the interactive user sign-in attempts the rule targets. Option C is wrong because AuditLogs records administrative actions and changes in Azure AD (e.g., user creation, role changes), not sign-in events. Option D is wrong because AzureActivity logs Azure resource management operations (e.g., VM creation, resource group changes), not user authentication events.

Practice this question →

57

MCQeasy

A security analyst needs to create a custom watchlist in Microsoft Sentinel to correlate IP addresses known to be used by a threat actor. The watchlist will be uploaded from a CSV file. Which data type should the analyst specify for the watchlist alias?

A.String

B.Integer

C.DateTime

D.Boolean

AnswerA

IP addresses are stored as strings.

Why this answer

The watchlist alias in Microsoft Sentinel is a string identifier used to reference the watchlist in KQL queries. Since IP addresses are stored as text values in CSV files and are not numeric integers, dates, or boolean flags, the correct data type for the alias is String. This ensures the alias can be used in join or lookup operations without type mismatch errors.

Exam trap

The trap here is that candidates may confuse the data type of the alias with the data type of the IP address values in the CSV, assuming IPs should be integers, but the alias is purely a metadata label and must be a string.

How to eliminate wrong answers

Option B is wrong because Integer is a numeric data type, but IP addresses are not integers and cannot be meaningfully represented as such without conversion. Option C is wrong because DateTime is used for date/time values, not for IP addresses which are textual identifiers. Option D is wrong because Boolean is a true/false data type, which cannot represent an IP address or serve as a watchlist alias.

Practice this question →

58

MCQhard

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

A.Scheduled

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

C.Anomaly detection

D.NRT (Near-Real-Time)

AnswerC

Anomaly detection rules apply machine learning models to identify deviations from historical patterns, making them suitable for detecting rare operations.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

59

MCQmedium

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

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

B.Alert threshold set to a value of 10

C.Query scheduling set to run every 5 minutes

D.Entity mapping for source IP address

AnswerB

The alert threshold specifies the minimum number of query results needed to generate an incident, ensuring only high-count patterns trigger alerts.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

60

MCQmedium

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

61

MCQmedium

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

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

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

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

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

AnswerC

The Account entity type represents user accounts. This condition ensures the playbook runs only on incidents that include a user entity, which is appropriate for disabling a compromised user.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

62

MCQeasy

A SOC analyst wants to ingest firewall logs from a Palo Alto Networks appliance into Microsoft Sentinel using the Common Event Format (CEF) connector. The analyst has already set up a Linux syslog forwarder. What is the next required step to complete the data ingestion?

A.Install the Azure Monitor Agent on the Linux forwarder.

B.Run the installation script provided by the Sentinel CEF connector page on the Linux forwarder.

C.Create a Syslog data connector in Sentinel and specify the Palo Alto facility.

D.Enable Azure Arc on the firewall appliance.

AnswerB

This script configures the forwarder to listen for CEF messages and forward them to Sentinel.

Why this answer

The CEF connector for Palo Alto Networks in Microsoft Sentinel requires a Linux syslog forwarder to have the CEF agent installed and configured. The installation script provided on the Sentinel CEF connector page automates the setup of the Log Analytics agent (formerly OMS agent) with the correct syslog daemon configuration to parse and forward CEF-formatted logs. Since the forwarder is already deployed, running this script is the immediate next step to enable log ingestion.

Exam trap

The trap here is that candidates confuse the CEF connector's agent installation step with the Azure Monitor Agent (AMA) or think that creating the data connector in the portal alone is sufficient, when in fact the Linux forwarder must first run the CEF installation script to enable log parsing and forwarding.

How to eliminate wrong answers

Option A is wrong because the Azure Monitor Agent (AMA) is not used for the CEF connector; the CEF connector relies on the legacy Log Analytics agent (OMS agent) installed via the CEF installation script. Option C is wrong because creating a Syslog data connector in Sentinel is a separate step that configures the data source in the portal, but it does not install or configure the forwarder; the installation script must be run first to set up the agent on the Linux machine. Option D is wrong because Azure Arc is not required for CEF log ingestion; the firewall appliance sends syslog to the Linux forwarder, and the forwarder communicates directly with the Log Analytics workspace without needing Azure Arc.

Practice this question →

63

MCQhard

Match each Microsoft Sentinel analytics rule type to its correct description.

A.Scheduled → Runs a KQL query on a schedule and generates alerts based on the query results.; Fusion → Correlates multiple high-fidelity alerts from various sources to create a single, comprehensive incident.; Anomaly → Uses machine learning to identify unusual patterns in activity by analyzing entity behavior over time.; Microsoft Security → Creates incidents from alerts generated by Microsoft security products such as Microsoft Defender for Endpoint.

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 describes the four distinct Microsoft Sentinel analytics rule types. Scheduled rules execute KQL queries at defined intervals to generate alerts based on query results. Fusion rules use advanced machine learning to correlate multiple high-fidelity alerts from different sources into a single incident, reducing alert fatigue.

Anomaly rules leverage machine learning to detect unusual patterns by analyzing entity behavior over time. Microsoft Security rules automatically create incidents from alerts generated by Microsoft security products like Microsoft Defender for Endpoint, integrating native security signals.

Exam trap

The trap here is that candidates often confuse the 'Fusion' rule type with 'Microsoft Security' rules, thinking Fusion only correlates Microsoft security alerts, when in fact Fusion correlates alerts from any source (including third-party) and uses ML, while Microsoft Security rules specifically handle native Microsoft security product alerts without ML correlation.

How to eliminate wrong answers

Option B is wrong because it claims the first and last mappings are swapped, which would incorrectly assign the 'Microsoft Security' description to the 'Scheduled' rule type and vice versa; however, the descriptions in Option A are correctly matched, so swapping them would break the accurate mapping. Option C is wrong because it suggests every item maps to the same log table or feature category, which is false; each rule type targets different data sources and purposes—Scheduled uses custom KQL queries, Fusion correlates alerts from multiple sources, Anomaly analyzes entity behavior, and Microsoft Security ingests alerts from Defender products. Option D is wrong because it states only identity-related items are mapped and workload/network items are omitted; in reality, Microsoft Sentinel rule types cover a broad range of telemetry including network, workload, and identity data, and the descriptions in Option A correctly include all relevant categories.

Practice this question →

64

Matchingmedium

Match each Microsoft Purview compliance feature to its description.

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

Concepts

Matches

Prevents accidental sharing of sensitive data

Searches and exports data for legal cases

Logs user and admin activities

Classifies and protects sensitive data with labels

Manages retention and disposal of records

Why these pairings

These features are part of Microsoft Purview for compliance.

Practice this question →

65

MCQmedium

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

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

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

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

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

AnswerC

_GetWatchlist() is the built-in function to retrieve watchlist data. It efficiently caches the data and automatically reflects updates without changing the rule query.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

66

MCQmedium

An organization uses Microsoft Sentinel with the Microsoft Defender for Cloud connector enabled. A security analyst receives an alert from Defender for Cloud about a potential brute-force attack on an Azure VM. The analyst wants to automatically create an incident in Sentinel and trigger a playbook that blocks the attacker's IP using a firewall. Which type of Sentinel automation rule should the analyst configure?

A.Analytics rule automation

B.Incident automation rule

C.Playbook trigger

D.Custom log ingestion

AnswerB

Incident automation rules run on incident creation or update and can trigger playbooks to respond to threats, such as blocking an IP.

Why this answer

Incident automation rules in Microsoft Sentinel allow you to automatically trigger a playbook when an incident is created or updated. Since the Defender for Cloud alert generates an incident in Sentinel, an incident automation rule can be configured to run a playbook that blocks the attacker's IP via a firewall, meeting the requirement without needing to modify the analytics rule itself.

Exam trap

The trap here is confusing 'analytics rule automation' with 'incident automation rule'—candidates often think the automation must be tied to the rule that generated the alert, but Sentinel separates alert generation (analytics rules) from incident-level actions (incident automation rules).

How to eliminate wrong answers

Option A is wrong because analytics rule automation is used to automatically run a playbook when an analytics rule generates an alert, not when an incident is created from an existing alert (like from Defender for Cloud). Option C is wrong because a playbook trigger is not a type of Sentinel automation rule; playbooks are triggered by automation rules or directly from incidents/alerts, but 'Playbook trigger' is not a valid rule type. Option D is wrong because custom log ingestion is a data collection method, not an automation rule, and cannot trigger playbooks based on incidents.

Practice this question →

67

MCQeasy

A security analyst in Microsoft Sentinel wants to create a custom analytics rule that triggers when more than 10 failed logon attempts from a single source IP address occur within 5 minutes. The analyst writes a KQL query to aggregate sign-in logs. Which KQL operator should the analyst use to group events by source IP and count each failure?

A.extend

B.project

C.summarize

D.where

AnswerC

summarize groups rows by specified columns and applies aggregation functions like count(), making it the correct operator for this use case.

Why this answer

The `summarize` operator is correct because it groups rows by a specified key (source IP) and applies an aggregation function (like `count()`) to produce a single output row per group. In this scenario, the analyst needs to count failed logon attempts per source IP, which requires grouping and counting—exactly what `summarize` does.

Exam trap

The trap here is that candidates often confuse `extend` or `project` with aggregation, thinking they can count events by adding a column, but only `summarize` performs the required grouping and counting operation.

How to eliminate wrong answers

Option A is wrong because `extend` adds a new calculated column to each row but does not group or aggregate data; it would not produce a count per IP. Option B is wrong because `project` selects or reorders columns without any aggregation or grouping; it cannot count events. Option D is wrong because `where` filters rows based on a condition but does not group or aggregate; it would only reduce the dataset without producing counts per IP.

Practice this question →

68

Drag & Dropmedium

Arrange the steps to run a Microsoft 365 Defender advanced hunting query and create a custom detection rule from it.

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

Steps

Order

Why this order

After running a query in Advanced hunting, you can create a detection rule directly from the results to alert on future matches.

Practice this question →

69

MCQhard

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

70

MCQmedium

A SOC team wants to automatically run a playbook that retrieves threat intelligence details whenever a high-severity incident is created in Microsoft Sentinel. Which type of automation should they configure?

A.Automation rule with incident trigger

B.Automation rule with alert trigger

C.Playbook with manual trigger

D.Logic app with recurrence

AnswerA

Incident trigger automation rules execute playbooks when an incident is created, matching the requirement.

Why this answer

Automation rules in Microsoft Sentinel can be configured with an incident trigger to automatically run playbooks when incidents are created or updated. Since the requirement is to run a playbook on high-severity incidents, an automation rule with an incident trigger allows you to filter by severity (e.g., High) and invoke the playbook without manual intervention.

Exam trap

The trap here is confusing the incident trigger with the alert trigger; candidates often select alert trigger because they think alerts are the primary event, but incidents are the higher-level object that SOC teams triage, and the question explicitly says 'incident is created'.

How to eliminate wrong answers

Option B is wrong because an automation rule with an alert trigger runs when an alert is generated, not when an incident is created; incidents aggregate alerts, so this would not meet the requirement to act on incident creation. Option C is wrong because a playbook with a manual trigger requires a human to run it, which contradicts the 'automatically' requirement. Option D is wrong because a Logic App with a recurrence trigger runs on a schedule (e.g., every hour) and cannot respond to real-time incident creation events in Sentinel.

Practice this question →

71

MCQmedium

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

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

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

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

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

AnswerB

This correctly filters by event ID and time first, then summarizes counts per account.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

72

MCQhard

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

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

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

C.Configure a watchlist to filter incidents

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

AnswerA

Automation rules can evaluate incident properties; setting a condition on Owner to 'Unassigned' ensures the rule triggers only for unassigned High severity incidents.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

73

MCQmedium

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

A.Common Event Format (CEF)

B.Syslog

C.Windows Firewall

D.Cisco ASA via API

AnswerA

The CEF connector is designed to parse syslog messages in Common Event Format, which Cisco ASA supports, enabling detailed log ingestion.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

74

MCQmedium

A SOC analyst creates a scheduled analytics rule in Microsoft Sentinel with the following KQL query: SigninLogs | where TimeGenerated > ago(1h) | summarize StartTime = min(TimeGenerated), EndTime = max(TimeGenerated) by UserPrincipalName, IPAddress | where EndTime - StartTime < 5m and count_IPAddress > 1 The intended purpose is to detect users logging in from multiple IP addresses in a short time (impossible travel). However, the rule does not generate any alerts. What is the most likely cause?

A.The query references a column 'count_IPAddress' that does not exist. The summarize operator does not create a column with that name.

B.The query does not filter for failed sign-ins (e.g., ResultType == 0).

C.The rule should use a longer time range, such as 24 hours.

D.The rule needs to use the 'make_set' function to correctly count distinct IP addresses.

AnswerA

The summarize creates columns from the aggregate expressions and group-by columns. 'count_IPAddress' is not defined, so the where clause always evaluates to false.

Why this answer

The query uses `summarize ... by UserPrincipalName, IPAddress` which groups by both fields, so it does not create a column named `count_IPAddress`. The `where` clause then references `count_IPAddress`, which does not exist, causing the query to fail silently or return no results. This is why no alerts are generated.

Exam trap

The trap here is that candidates may focus on the logic of impossible travel detection (e.g., time range, distinct IPs) and overlook the simple syntax error of referencing a column that was never created by the `summarize` operator.

How to eliminate wrong answers

Option B is wrong because filtering for failed sign-ins (ResultType == 0) is irrelevant; the rule is designed to detect impossible travel from successful sign-ins, and the issue is a syntax error, not a missing filter. Option C is wrong because the time range (1 hour) is sufficient for detecting short-interval multiple IP logins; extending it would not fix the missing column error. Option D is wrong because `make_set` is used to create an array of distinct values, not to count them; the correct function to count distinct IPs would be `dcount` or `count_distinct`, but the core problem is the non-existent column reference.

Practice this question →

75

MCQmedium

A SOC analyst is creating a scheduled analytics rule in Microsoft Sentinel to detect when a user account is added to a privileged role in Microsoft Entra ID. The analyst wants to correlate with the user's previous role assignments to identify potential privilege escalation. Which table should the analyst query?

A.AuditLogs

B.SigninLogs

C.AzureActivity

D.SecurityEvent

AnswerA

AuditLogs captures Microsoft Entra ID events such as 'Add member to role', which is essential for detecting privilege escalations.

Why this answer

The AuditLogs table in Microsoft Sentinel captures directory activity, including changes to privileged role assignments in Microsoft Entra ID (formerly Azure AD). By querying AuditLogs, the analyst can correlate the current role addition with historical role assignment events to detect potential privilege escalation. SigninLogs, AzureActivity, and SecurityEvent do not contain the specific role assignment audit data needed for this correlation.

Exam trap

The trap here is that candidates may confuse AzureActivity (which logs Azure resource operations) with Microsoft Entra ID audit logs, or assume SigninLogs contains role assignment data because it includes directory roles in sign-in token claims.

How to eliminate wrong answers

Option B is wrong because SigninLogs records user sign-in events, not directory changes like role assignments. Option C is wrong because AzureActivity logs Azure resource management operations (e.g., VM creation), not Microsoft Entra ID role assignments. Option D is wrong because SecurityEvent collects Windows security events from on-premises or Azure VMs, not cloud directory role changes.

Practice this question →

Page 1 of 2 · 108 questions totalNext →

Ready to test yourself?

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

Start 20-question session