Scenario practice questions

A security team uses Microsoft Sentinel to hunt for signs of credential theft. They want to detect when a user account has been used to log in from an unusual location and then immediately performs a password reset for another user. Which hunting approach is most effective for this scenario?

Trap 1: Use a Microsoft Sentinel playbook to automatically flag any…

Playbooks are for automation, not hunting.

Trap 2: Search the SigninLogs table for logins from unusual locations

This only addresses one part of the scenario and does not correlate with password resets.

Trap 3: Create a watchlist of known unusual locations and use it in a query…

Watchlists are static and do not correlate different event types.

A
Use a Microsoft Sentinel playbook to automatically flag any password reset
Why wrong: Playbooks are for automation, not hunting.
B
Write a KQL query that joins SigninLogs with AuditLogs on user principal name and times within a short window
This correlates the two events to detect the sequence of unusual login followed by password reset.
C
Search the SigninLogs table for logins from unusual locations
Why wrong: This only addresses one part of the scenario and does not correlate with password resets.
D
Create a watchlist of known unusual locations and use it in a query against AuditLogs
Why wrong: Watchlists are static and do not correlate different event types.

Read the full VPN explanation →

Question 2mediummultiple choice

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?

Trap 1: Near-real-time (NRT) rule

Near-real-time (NRT) rules are built for low-latency detection and execute approximately every minute, but they restrict query complexity to a limited set of KQL operators and support only a single data table. NRT rules do not permit multi-table joins, which immediately rules them out for correlating Syslog with other sources. They are best suited for simple threshold or pattern detections on one table, not for cross-source correlation.

Trap 2: Fusion rule

Fusion rules are Microsoft's prebuilt analytics that use machine learning to combine alerts across multiple security products into a multi-stage attack narrative. They are not customizable with KQL, nor do they allow you to define your own raw data sources or join logic. Since the question requires correlating Syslog data explicitly, a Fusion rule cannot be adapted to that purpose—you would be limited to the predefined alert-correlation patterns Microsoft provides.

Trap 3: Anomaly rule

Anomaly rules in Microsoft Sentinel are powered by built-in machine learning models that analyze temporal patterns in specific data sources to identify deviations from established baselines. They are not designed for custom KQL correlation logic, so you cannot write a query that joins Syslog with other tables like SecurityEvent or CommonSecurityLog. Because the underlying ML models and data source selections are predefined, anomaly rules cannot fulfill a requirement to correlate raw syslog events with additional signals across multiple tables.

A
Scheduled query rule
Scheduled query rules are the correct choice for correlating Syslog with other data sources because they accept fully custom KQL queries that can join, union, or aggregate multiple tables. You can schedule the query to run at any interval and define alert logic that matches your correlation criteria, such as joining Syslog and CommonSecurityLog on hostname or source IP. The alert generated includes the full query results, enabling analysts to investigate both sides of the correlation directly from the incident.
B
Near-real-time (NRT) rule
Why wrong: Near-real-time (NRT) rules are built for low-latency detection and execute approximately every minute, but they restrict query complexity to a limited set of KQL operators and support only a single data table. NRT rules do not permit multi-table joins, which immediately rules them out for correlating Syslog with other sources. They are best suited for simple threshold or pattern detections on one table, not for cross-source correlation.
C
Fusion rule
Why wrong: Fusion rules are Microsoft's prebuilt analytics that use machine learning to combine alerts across multiple security products into a multi-stage attack narrative. They are not customizable with KQL, nor do they allow you to define your own raw data sources or join logic. Since the question requires correlating Syslog data explicitly, a Fusion rule cannot be adapted to that purpose—you would be limited to the predefined alert-correlation patterns Microsoft provides.
D
Anomaly rule
Why wrong: Anomaly rules in Microsoft Sentinel are powered by built-in machine learning models that analyze temporal patterns in specific data sources to identify deviations from established baselines. They are not designed for custom KQL correlation logic, so you cannot write a query that joins Syslog with other tables like SecurityEvent or CommonSecurityLog. Because the underlying ML models and data source selections are predefined, anomaly rules cannot fulfill a requirement to correlate raw syslog events with additional signals across multiple tables.

Question 3mediummultiple choice

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

Trap 1: Scheduled rule

Scheduled rules execute a KQL query at fixed intervals, such as every 5 minutes or hourly, and compare results against static thresholds defined in the query. They lack a learning phase or adaptive baseline, so they would require manually pre-defining what constitutes a normal sign-in location for every user, which is impractical for dynamic behavioral patterns. Consequently, they cannot autonomously detect unusual sign-in locations that deviate from an established baseline.

Trap 2: NRT (Near-Real-Time) rule

Near-Real-Time (NRT) rules provide low-latency detection, typically querying data every minute, but they rely on static detection logic like pattern matching or fixed thresholds. They do not employ machine learning to establish a baseline of normal user sign-in behavior, so they would miss novel or evolving location anomalies that differ from historical patterns. The minimal delay in data processing does not compensate for the absence of adaptive learning, making NRT rules unsuitable for this scenario.

Trap 3: Fusion rule

Fusion rules are designed to correlate multiple security alerts and signals across various data sources to detect multi-stage attacks or kill chains, such as an initial compromise leading to lateral movement and data exfiltration. A single anomalous sign-in location represents an individual event, not a chain of correlated activities, so Fusion would not have enough context to trigger. Additionally, Fusion does not learn a personalized baseline for normal sign-in behavior; it relies on aggregating existing alerts, making it unsuitable for this single-event anomaly detection requirement.

A
Scheduled rule
Why wrong: Scheduled rules execute a KQL query at fixed intervals, such as every 5 minutes or hourly, and compare results against static thresholds defined in the query. They lack a learning phase or adaptive baseline, so they would require manually pre-defining what constitutes a normal sign-in location for every user, which is impractical for dynamic behavioral patterns. Consequently, they cannot autonomously detect unusual sign-in locations that deviate from an established baseline.
B
NRT (Near-Real-Time) rule
Why wrong: Near-Real-Time (NRT) rules provide low-latency detection, typically querying data every minute, but they rely on static detection logic like pattern matching or fixed thresholds. They do not employ machine learning to establish a baseline of normal user sign-in behavior, so they would miss novel or evolving location anomalies that differ from historical patterns. The minimal delay in data processing does not compensate for the absence of adaptive learning, making NRT rules unsuitable for this scenario.
C
Anomaly rule
Anomaly rules in Microsoft Sentinel leverage built-in machine learning models to learn the baseline of normal sign-in behavior for users and entities over a specified time window. They then flag sign-in events that deviate significantly from that learned baseline, such as sign-ins from geographically unusual locations, impossible travel, or previously unseen IP addresses. This adaptive, self-learning approach eliminates the need for manually configured thresholds, making anomaly rules the appropriate choice for detecting unusual sign-in locations.
D
Fusion rule
Why wrong: Fusion rules are designed to correlate multiple security alerts and signals across various data sources to detect multi-stage attacks or kill chains, such as an initial compromise leading to lateral movement and data exfiltration. A single anomalous sign-in location represents an individual event, not a chain of correlated activities, so Fusion would not have enough context to trigger. Additionally, Fusion does not learn a personalized baseline for normal sign-in behavior; it relies on aggregating existing alerts, making it unsuitable for this single-event anomaly detection requirement.

Question 4mediummultiple choice

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

Trap 1: EmailPostDeliveryEvents and DeviceLogonEvents

EmailPostDeliveryEvents is the wrong counterpart because it only tracks actions that occur after an email is delivered, such as user clicks, forwards, or deletion, and it contains no sender identity or transmit metadata. DeviceLogonEvents, meanwhile, logs local interactive and remote logons to Windows endpoints using the Defender for Endpoint sensor, not Microsoft Entra ID cloud authentication. Therefore, this pair could show you that a recipient clicked a link and then logged into a workstation, but it will not reveal who sent the phishing email or expose an attacker's cloud sign-in.

Trap 2: EmailAttachmentInfo and IdentityLogonEvents

EmailAttachmentInfo is limited to enumerating attachment filenames, hashes, and sizes from email messages, so it lacks the sender and recipient data needed to identify the source of a malicious send. IdentityLogonEvents is produced by Microsoft Defender for Identity and represents on-premises Active Directory authentication attempts via NTLM or Kerberos, not Microsoft Entra ID sign-in logs. This combination would at best let you attribute a suspicious attachment to a particular mailbox while seeing only on-premises auth, leaving the cloud sign-in correlation completely unanswered.

Trap 3: EmailUrlInfo and CloudAppEvents

EmailUrlInfo captures only the URLs embedded in email bodies and metadata like URL chain, verdict, and click status; it does not record sender identity or message routing information for the send. CloudAppEvents is an aggregated activity log for Microsoft 365 and third-party cloud applications, such as file downloads or permission changes, but it does not enumerate Microsoft Entra ID sign-in events like those found in AADSignInEventsBeta. Thus, this pair would inform you about URL reputation and app usage but cannot connect an individual sender's email to a subsequent authentication event.

A
EmailEvents and AADSignInEventsBeta
EmailEvents is the correct source for the send side of a business email compromise because it records the sender's SMTP address, recipient, subject, and send timestamp for every outbound message. AADSignInEventsBeta is equally essential for the sign-in side, capturing interactive and non-interactive authentication events against Microsoft Entra ID with fields like UserPrincipalName, IP address, and risk level. Joining on the sender's SMTP address to the sign-in UPN lets you correlate an anomalous sign-in with a suspicious email sent by that account, which directly ties the initial phish to attacker authentication.
B
EmailPostDeliveryEvents and DeviceLogonEvents
Why wrong: EmailPostDeliveryEvents is the wrong counterpart because it only tracks actions that occur after an email is delivered, such as user clicks, forwards, or deletion, and it contains no sender identity or transmit metadata. DeviceLogonEvents, meanwhile, logs local interactive and remote logons to Windows endpoints using the Defender for Endpoint sensor, not Microsoft Entra ID cloud authentication. Therefore, this pair could show you that a recipient clicked a link and then logged into a workstation, but it will not reveal who sent the phishing email or expose an attacker's cloud sign-in.
C
EmailAttachmentInfo and IdentityLogonEvents
Why wrong: EmailAttachmentInfo is limited to enumerating attachment filenames, hashes, and sizes from email messages, so it lacks the sender and recipient data needed to identify the source of a malicious send. IdentityLogonEvents is produced by Microsoft Defender for Identity and represents on-premises Active Directory authentication attempts via NTLM or Kerberos, not Microsoft Entra ID sign-in logs. This combination would at best let you attribute a suspicious attachment to a particular mailbox while seeing only on-premises auth, leaving the cloud sign-in correlation completely unanswered.
D
EmailUrlInfo and CloudAppEvents
Why wrong: EmailUrlInfo captures only the URLs embedded in email bodies and metadata like URL chain, verdict, and click status; it does not record sender identity or message routing information for the send. CloudAppEvents is an aggregated activity log for Microsoft 365 and third-party cloud applications, such as file downloads or permission changes, but it does not enumerate Microsoft Entra ID sign-in events like those found in AADSignInEventsBeta. Thus, this pair would inform you about URL reputation and app usage but cannot connect an individual sender's email to a subsequent authentication event.

Question 5easymultiple choice

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

Trap 1: summarize

summarize is a KQL aggregation operator that groups rows by one or more key columns, but it does not automatically create time intervals. To achieve time-based grouping, you must explicitly include a computed column like bin(TimeGenerated, 5m) in the group-by clause; otherwise, summarize will treat every distinct timestamp as its own bucket, yielding an overwhelming number of groups that are useless for interval-based analytics. For example, `summarize count() by TimeGenerated` returns a separate count for each exact second, not a 5-minute aggregate. Thus, summarize is a necessary companion to bin(), but it cannot perform the interval bucketing on its own.

Trap 2: count

count is an aggregate function used inside a summarize block to count rows, typically written as `summarize count() by ...`. It calculates the number of events in each group but has no ability to define what those groups are, nor does it perform any time-based transformation. In a scheduled analytics rule, count is useful for measuring event volume per bucket, but it must be combined with a group key such as bin(TimeGenerated, 5m) to provide the interval structure. Using count alone, without a proper grouping field, will simply return a total count of all matching events, which does not satisfy the need for time-interval grouping.

Trap 3: where

where is a KQL filtering operator that narrows a result set to rows meeting a specified condition, such as `where EventID == 4625`. It is used to select only relevant events before aggregation, but it has no grouping capability and cannot create time intervals. In a scheduled analytics rule, a where clause might filter for a specific security event type, but you would still need bin() to partition those filtered events into time buckets for further analysis. Confusing where with bin() would mean you merely restrict the dataset, never producing the time-series structure required for interval-based detections.

A
bin()
The bin() function in KQL is a scalar function that rounds a datetime value down to the nearest multiple of the specified interval, such as 5 minutes (e.g., bin(TimeGenerated, 5m)). This creates uniform time buckets that allow a scheduled analytics rule to aggregate events into fixed windows, making it essential for time-series analysis, rate detection, and anomaly identification. Without bin(), time values remain continuous and ungrouped, so patterns across discrete intervals would be impossible to discern. In practice, you pair bin() with summarize, as in `summarize count() by bin(TimeGenerated, 5m)`, to produce the time-bucketed aggregates the rule needs.
B
summarize
Why wrong: summarize is a KQL aggregation operator that groups rows by one or more key columns, but it does not automatically create time intervals. To achieve time-based grouping, you must explicitly include a computed column like bin(TimeGenerated, 5m) in the group-by clause; otherwise, summarize will treat every distinct timestamp as its own bucket, yielding an overwhelming number of groups that are useless for interval-based analytics. For example, `summarize count() by TimeGenerated` returns a separate count for each exact second, not a 5-minute aggregate. Thus, summarize is a necessary companion to bin(), but it cannot perform the interval bucketing on its own.
C
count
Why wrong: count is an aggregate function used inside a summarize block to count rows, typically written as `summarize count() by ...`. It calculates the number of events in each group but has no ability to define what those groups are, nor does it perform any time-based transformation. In a scheduled analytics rule, count is useful for measuring event volume per bucket, but it must be combined with a group key such as bin(TimeGenerated, 5m) to provide the interval structure. Using count alone, without a proper grouping field, will simply return a total count of all matching events, which does not satisfy the need for time-interval grouping.
D
where
Why wrong: where is a KQL filtering operator that narrows a result set to rows meeting a specified condition, such as `where EventID == 4625`. It is used to select only relevant events before aggregation, but it has no grouping capability and cannot create time intervals. In a scheduled analytics rule, a where clause might filter for a specific security event type, but you would still need bin() to partition those filtered events into time buckets for further analysis. Confusing where with bin() would mean you merely restrict the dataset, never producing the time-series structure required for interval-based detections.

Question 6mediummultiple choice

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?

Trap 1: where

The `where` operator filters rows in a single input table based on a predicate expression, such as `TimeGenerated > ago(1d)`. It cannot reference columns from another table unless that table has already been joined, nor can it bring in account creation and sign-in events for comparison. Filtering alone never correlates or merges separate data sources, so using `where` would not enable the analysis.

Trap 2: union

The `union` operator stacks rows from multiple tables vertically, returning a single result set that contains all records from each input. It requires that both tables share a similar schema, but it does not align or correlate individual records; an account-creation row and a sign-in row remain separate rows with no relationship. Consequently, `union` cannot reveal whether a sign-in follows an account creation, making it unsuitable for this rule.

Trap 3: summarize

The `summarize` operator aggregates rows within a single table by grouping on a key and calculating aggregates like `count()` or `max()`. It cannot ingest a second table, so it has no way to bring in account-creation data separately from sign-in data. Even if you first joined the tables, `summarize` would only produce a summary—not preserve the row-level detail needed to flag a newly created account that signs in.

A
where
Why wrong: The `where` operator filters rows in a single input table based on a predicate expression, such as `TimeGenerated > ago(1d)`. It cannot reference columns from another table unless that table has already been joined, nor can it bring in account creation and sign-in events for comparison. Filtering alone never correlates or merges separate data sources, so using `where` would not enable the analysis.
B
join
The `join` operator is the correct choice because it merges columns from two tables into a single row when a common key matches, such as joining `SecurityEvent` (account creation) to `SigninLogs` on `AccountName`. Using a `kind` like `innerjoin` and optionally comparing timestamps within a `where` clause allows the analyst to detect accounts that were created and then immediately signed in, directly correlating the two event streams. This row-level merge is exactly what the analytics rule needs.
C
union
Why wrong: The `union` operator stacks rows from multiple tables vertically, returning a single result set that contains all records from each input. It requires that both tables share a similar schema, but it does not align or correlate individual records; an account-creation row and a sign-in row remain separate rows with no relationship. Consequently, `union` cannot reveal whether a sign-in follows an account creation, making it unsuitable for this rule.
D
summarize
Why wrong: The `summarize` operator aggregates rows within a single table by grouping on a key and calculating aggregates like `count()` or `max()`. It cannot ingest a second table, so it has no way to bring in account-creation data separately from sign-in data. Even if you first joined the tables, `summarize` would only produce a summary—not preserve the row-level detail needed to flag a newly created account that signs in.

Question 7mediummultiple choice

A company uses Microsoft Defender for Cloud to protect their Azure resources. They have enabled the enhanced security features on a subscription that contains several Azure SQL databases. They want to be alerted if a user attempts to perform SQL injection attacks against these databases. Which Defender for Cloud plan specifically enables SQL injection detection alerts?

Trap 1: Defender for Servers

Defender for Servers is a plan that secures Linux and Windows machines, whether in Azure or on-premises, with endpoint detection and response, file integrity monitoring, and vulnerability management. However, it does not ingest SQL database audit logs or query-level telemetry, so it cannot generate the SQL injection attempt alerts the company needs. The SQL-specific threat intelligence and alert logic reside exclusively in Defender for SQL.

Trap 2: Defender for App Service

Defender for App Service focuses on web applications running in Azure App Service, detecting threats such as web shells, suspicious code execution, and brute-force attempts against web endpoints. Its detection engine relies on App Service traffic and runtime signals, not on database transaction logs or SQL queries. Because the company's need is explicitly for SQL database protection, this plan would leave SQL databases without the required threat alerts.

Trap 3: Defender for Storage

Defender for Storage monitors Azure Storage accounts for anomalies like unusual access patterns, egress to unusual IPs, and malware uploaded to Blob containers. It works on storage telemetry and control-plane events, which cannot reveal SQL injection or database query anomalies. Therefore, deploying this plan would secure the storage layer only and fail to emit alerts for SQL database threats.

A
Defender for Servers
Why wrong: Defender for Servers is a plan that secures Linux and Windows machines, whether in Azure or on-premises, with endpoint detection and response, file integrity monitoring, and vulnerability management. However, it does not ingest SQL database audit logs or query-level telemetry, so it cannot generate the SQL injection attempt alerts the company needs. The SQL-specific threat intelligence and alert logic reside exclusively in Defender for SQL.
B
Defender for SQL
Defender for SQL is the dedicated plan that protects Azure SQL Database, SQL Managed Instance, and SQL on Azure VMs by surfacing database-level threats. It analyzes SQL audit logs and query activity to detect SQL injection attempts, anomalous access patterns, brute-force attacks, and other database-specific vulnerabilities. This plan also provides vulnerability assessment and data discovery/classification, making it the only option here that directly addresses the requirement for SQL security alerts.
C
Defender for App Service
Why wrong: Defender for App Service focuses on web applications running in Azure App Service, detecting threats such as web shells, suspicious code execution, and brute-force attempts against web endpoints. Its detection engine relies on App Service traffic and runtime signals, not on database transaction logs or SQL queries. Because the company's need is explicitly for SQL database protection, this plan would leave SQL databases without the required threat alerts.
D
Defender for Storage
Why wrong: Defender for Storage monitors Azure Storage accounts for anomalies like unusual access patterns, egress to unusual IPs, and malware uploaded to Blob containers. It works on storage telemetry and control-plane events, which cannot reveal SQL injection or database query anomalies. Therefore, deploying this plan would secure the storage layer only and fail to emit alerts for SQL database threats.

Question 8mediummultiple choice

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?

Trap 1: extend

extend adds new calculated columns to each existing row without grouping or reducing the number of rows. Because it performs row-wise transformations, such as adding a computed field like TotalBytes = Bytes * 2, it cannot aggregate multiple events into per-entity totals, making it impossible to evaluate a detection threshold across a time window.

Trap 2: project

project selects a subset of columns from the input table, similar to a SQL SELECT clause, and can optionally rename or compute columns, but it preserves the row count. Since it does not collapse multiple rows into groups or perform any kind of aggregation, it cannot produce the counts needed to evaluate a threshold condition like 'more than 5 events from one IP address.'

Trap 3: where

where filters the input set by applying a boolean condition to each row, retaining only matching rows, analogous to a WHERE clause in SQL. It reduces the number of rows but does not group them or calculate counts, so while it can be used to narrow down events before aggregation, on its own it cannot satisfy the requirement to summarize data for threshold comparison.

A
summarize
summarize is the KQL aggregation operator that groups rows by specified columns, such as UserPrincipalName or IPAddress, and computes aggregates like count(), sum(), or avg() across each group. In a scheduled analytics rule, this is exactly what enables threshold detection by producing per-entity event counts that can be compared against a threshold, such as more than 5 failed sign-ins for a single user.
B
extend
Why wrong: extend adds new calculated columns to each existing row without grouping or reducing the number of rows. Because it performs row-wise transformations, such as adding a computed field like TotalBytes = Bytes * 2, it cannot aggregate multiple events into per-entity totals, making it impossible to evaluate a detection threshold across a time window.
C
project
Why wrong: project selects a subset of columns from the input table, similar to a SQL SELECT clause, and can optionally rename or compute columns, but it preserves the row count. Since it does not collapse multiple rows into groups or perform any kind of aggregation, it cannot produce the counts needed to evaluate a threshold condition like 'more than 5 events from one IP address.'
D
where
Why wrong: where filters the input set by applying a boolean condition to each row, retaining only matching rows, analogous to a WHERE clause in SQL. It reduces the number of rows but does not group them or calculate counts, so while it can be used to narrow down events before aggregation, on its own it cannot satisfy the requirement to summarize data for threshold comparison.

Question 9mediummultiple choice

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

Trap 1: Run a hunting query.

Hunting is for proactive search.

Trap 2: Review the analytics rule that generated the incident.

Analytics rules don't show related alerts.

Trap 3: Use the Incident workbook.

Workbooks are for reporting, not dynamic investigation.

A
Run a hunting query.
Why wrong: Hunting is for proactive search.
B
Open the incident investigation graph.
Investigation graph shows relationships.
C
Review the analytics rule that generated the incident.
Why wrong: Analytics rules don't show related alerts.
D
Use the Incident workbook.
Why wrong: Workbooks are for reporting, not dynamic investigation.