Scenario practice questions

You have an Azure virtual machine that hosts a web application. You need to allow inbound HTTP (80) and HTTPS (443) traffic from the internet to this VM only. You also need to allow outbound traffic to the internet from the VM. You want to use a managed Azure service with minimal configuration. What should you use?

Trap 1: Azure Application Gateway

Azure Application Gateway is a layer-7 load balancer and Web Application Firewall designed to route inbound HTTP/HTTPS traffic to backend pools based on URL paths, host headers, or other L7 attributes. For a single VM needing basic per-VM connectivity rules, it introduces significant operational overhead—you must configure listeners, routing rules, and health probes—and it does not manage outbound internet access from the VM. Therefore, while it could technically proxy incoming web traffic, it is not the minimal, direct security control required here.

Trap 2: Azure Firewall

Azure Firewall is not the appropriate choice here because it is designed for centralised network security across multiple workloads or virtual networks, not for securing a single VM directly with minimal configuration. Implementing it for a lone VM would introduce unnecessary routing complexity and cost. However, it is tempting as a managed firewall service, and would be the correct option for enterprise-grade scenarios requiring advanced, centralised traffic filtering, threat intelligence, and policy enforcement for an entire network.

Trap 3: Azure Bastion

Azure Bastion is a fully managed platform-as-a-service offering that provides secure, browser-based RDP and SSH connectivity to virtual machines over the Azure portal. It does not filter general application traffic such as HTTP/HTTPS, nor does it govern outbound internet access from the workload—it only mediates interactive administrative sessions. Deploying Bastion for this requirement would be both functionally irrelevant and an unnecessary cost, as it is not a network security control for application data plane traffic.

A
Azure Application Gateway
Why wrong: Azure Application Gateway is a layer-7 load balancer and Web Application Firewall designed to route inbound HTTP/HTTPS traffic to backend pools based on URL paths, host headers, or other L7 attributes. For a single VM needing basic per-VM connectivity rules, it introduces significant operational overhead—you must configure listeners, routing rules, and health probes—and it does not manage outbound internet access from the VM. Therefore, while it could technically proxy incoming web traffic, it is not the minimal, direct security control required here.
B
Azure Firewall
Why wrong: Azure Firewall is not the appropriate choice here because it is designed for centralised network security across multiple workloads or virtual networks, not for securing a single VM directly with minimal configuration. Implementing it for a lone VM would introduce unnecessary routing complexity and cost. However, it is tempting as a managed firewall service, and would be the correct option for enterprise-grade scenarios requiring advanced, centralised traffic filtering, threat intelligence, and policy enforcement for an entire network.
C
Network Security Group (NSG)
A Network Security Group (NSG) is the correct, lightweight choice because it acts as a stateful, distributed packet filter that you can attach directly to the VM's NIC or its subnet. You can define allow/deny rules for inbound HTTP/HTTPS (e.g., ports 80/443) while relying on the default outbound internet access that NSGs permit unless you explicitly block it. It is free, requires no additional infrastructure, and its simplicity aligns perfectly with the requirement to secure a single VM hosting a web application.
D
Azure Bastion
Why wrong: Azure Bastion is a fully managed platform-as-a-service offering that provides secure, browser-based RDP and SSH connectivity to virtual machines over the Azure portal. It does not filter general application traffic such as HTTP/HTTPS, nor does it govern outbound internet access from the workload—it only mediates interactive administrative sessions. Deploying Bastion for this requirement would be both functionally irrelevant and an unnecessary cost, as it is not a network security control for application data plane traffic.

Study the full multicast explanation →

Question 2mediummultiple choice

A company uses Azure AD Privileged Identity Management (PIM) to manage the 'Global Administrator' role. The security team wants to ensure that when a user activates the role, they must provide a justification, and the activation request must be approved by a specific group of security administrators. They have already configured the role for activation with a maximum duration of 8 hours. Which additional PIM settings should they configure?

Trap 1: Set 'Require Azure Multi-Factor Authentication' to 'On'

Setting 'Require Azure Multi-Factor Authentication' to 'On' only strengthens the identity verification of the user making the activation request; it validates that the caller is who they claim to be. It does not introduce a second party who reviews and consents to the elevation. Since no other individual or group must sign off, the role can still be activated automatically after authentication, leaving no approval control at all.

Trap 2: Set 'Require justification on activation' to 'On' and also enable…

Requiring justification and ticket information on activation forces the user to supply business context, which is valuable for auditing, but these are merely mandatory text fields during the request. Once the user enters a reason and ticket number, PIM does not route the request to any other person for authorization—it proceeds with activation according to the role's settings. Thus these options collect data but create no approver workflow.

Trap 3: Create a separate PIM request workflow using Azure Logic Apps

While you could architect a custom approval pipeline with Azure Logic Apps that reacts to PIM audit events and triggers external sign-offs, this is not a native PIM configuration and would introduce significant custom code and identity handling complexity. PIM has a built-in approval feature that is the intended, supported path, and using Logic Apps instead ignores the actual product capability. Custom workflows also risk inconsistencies with PIM's role activation state, whereas the native approval integrates directly with the role lifecycle.

A
Enable 'Require approval to activate' and select the security group as approver
Enabling 'Require approval to activate' in PIM forces any eligible user's activation request to enter a pending state until a designated approver explicitly approves it. By selecting the security group as the approver, you guarantee that a human decision point exists outside the requesting user, so the security group enforces separation of duties. This is the native, built-in PIM approval mechanism that directly implements the required governance control.
B
Set 'Require Azure Multi-Factor Authentication' to 'On'
Why wrong: Setting 'Require Azure Multi-Factor Authentication' to 'On' only strengthens the identity verification of the user making the activation request; it validates that the caller is who they claim to be. It does not introduce a second party who reviews and consents to the elevation. Since no other individual or group must sign off, the role can still be activated automatically after authentication, leaving no approval control at all.
C
Set 'Require justification on activation' to 'On' and also enable 'Require ticket information'
Why wrong: Requiring justification and ticket information on activation forces the user to supply business context, which is valuable for auditing, but these are merely mandatory text fields during the request. Once the user enters a reason and ticket number, PIM does not route the request to any other person for authorization—it proceeds with activation according to the role's settings. Thus these options collect data but create no approver workflow.
D
Create a separate PIM request workflow using Azure Logic Apps
Why wrong: While you could architect a custom approval pipeline with Azure Logic Apps that reacts to PIM audit events and triggers external sign-offs, this is not a native PIM configuration and would introduce significant custom code and identity handling complexity. PIM has a built-in approval feature that is the intended, supported path, and using Logic Apps instead ignores the actual product capability. Custom workflows also risk inconsistencies with PIM's role activation state, whereas the native approval integrates directly with the role lifecycle.

Question 3mediummulti select

You are designing security for an Azure SQL Database that will store personally identifiable information (PII). The database will be accessed by multiple applications, some of which are legacy and cannot use Azure AD authentication. Your requirements include: encrypting data at rest, encrypting data in transit, and dynamically masking PII columns for non-privileged users. Which THREE features should you implement?

Trap 1: Implement Always Encrypted for the PII columns.

Always Encrypted is a client-side encryption feature where the database engine operates on ciphertext but never has the keys; it requires client driver support and can break legacy applications that don't support the feature. It cannot satisfy a server-level encrypt-in-transit requirement because it doesn't control the TLS handshake or connection security. Moreover, it limits queryability (e.g., equality checks only) and is not a substitute for forcing all connections to use TLS 1.2.

Trap 2: Apply Azure Information Protection labels to the database.

Azure Information Protection (AIP) is an information-protection solution that applies classification labels and optional usage restrictions to documents/emails, not to an Azure SQL Database at rest or in transit. It does not change the database's connection security settings, nor does it mask or encrypt T-SQL result-set values. Enabling AIP labels on a database is not a supported mechanism to enforce TLS or protect PII within SQL tables; it merely adds metadata.

A
Configure Dynamic Data Masking (DDM) for the PII columns.
Dynamic Data Masking (DDM) hides sensitive PII from non-privileged users by applying masking rules (e.g., email or credit-card patterns) at query runtime without altering the underlying data. It is a server/database-level security feature that can be enabled on specific columns, and privileged users can still see the full values. DDM does not protect data in transit or at rest—it only addresses unauthorized viewing by presenting masked values to certain principals.
B
Implement Always Encrypted for the PII columns.
Why wrong: Always Encrypted is a client-side encryption feature where the database engine operates on ciphertext but never has the keys; it requires client driver support and can break legacy applications that don't support the feature. It cannot satisfy a server-level encrypt-in-transit requirement because it doesn't control the TLS handshake or connection security. Moreover, it limits queryability (e.g., equality checks only) and is not a substitute for forcing all connections to use TLS 1.2.
C
Set the 'Minimum TLS Version' to 1.2 on the Azure SQL Server.
Setting Minimum TLS Version to 1.2 on the Azure SQL Server enforces that every client connection must use TLS 1.2 or later, rejecting connections using TLS 1.0 or 1.1. This directly satisfies the encrypt-in-transit requirement at the server level, covering all databases in that logical server. It's a server configuration in the Azure portal or via CLI/ARM, and it prevents legacy clients from establishing insecure plaintext or weaker-encrypted connections.
D
Enable Transparent Data Encryption (TDE) for the Azure SQL Database.
Transparent Data Encryption (TDE) performs real-time I/O encryption and decryption of the database data and log files, protecting data at rest using AES-256 encryption. Because it is transparent, no application changes are required; the database engine handles encryption as data is written to storage and decryption as it is read. TDE alone does not encrypt network traffic or mask results, so it must be combined with TLS enforcement and dynamic masking to meet the full set of requirements.
E
Apply Azure Information Protection labels to the database.
Why wrong: Azure Information Protection (AIP) is an information-protection solution that applies classification labels and optional usage restrictions to documents/emails, not to an Azure SQL Database at rest or in transit. It does not change the database's connection security settings, nor does it mask or encrypt T-SQL result-set values. Enabling AIP labels on a database is not a supported mechanism to enforce TLS or protect PII within SQL tables; it merely adds metadata.

Question 4mediummultiple choice

A security operations team uses Microsoft Sentinel. They want to create a custom analytics rule that detects when an Azure virtual machine is created with a public IP address that is not in an approved list. Which type of rule should they use?

Trap 1: NRT rule

An NRT (Near-Real-Time) rule is not ideal here because its primary purpose is to detect threats with minimal latency, typically within minutes. While it could technically detect the VM creation, the scenario doesn't necessitate such immediate detection, and the overhead for near-real-time processing is unnecessary. It's tempting because NRT rules are commonly used for active threat hunting, but for periodic checks against an approved list, a scheduled rule offers better resource optimisation.

Trap 2: Anomaly rule

Anomaly rules use machine learning to detect unusual patterns, not static list matching. They are not suitable for checking against a fixed approved IP list.

Trap 3: Fusion rule

Fusion rules correlate multiple alerts from different sources to detect multi-stage attacks. They are not used for single-event detection like a new VM creation.

A
Scheduled query rule
Correct. Scheduled query rules allow you to run a KQL query on a schedule and create incidents based on the results. This is ideal for checking new VM creations against an approved IP list.
B
NRT rule
Why wrong: An NRT (Near-Real-Time) rule is not ideal here because its primary purpose is to detect threats with minimal latency, typically within minutes. While it could technically detect the VM creation, the scenario doesn't necessitate such immediate detection, and the overhead for near-real-time processing is unnecessary. It's tempting because NRT rules are commonly used for active threat hunting, but for periodic checks against an approved list, a scheduled rule offers better resource optimisation.
C
Anomaly rule
Why wrong: Anomaly rules use machine learning to detect unusual patterns, not static list matching. They are not suitable for checking against a fixed approved IP list.
D
Fusion rule
Why wrong: Fusion rules correlate multiple alerts from different sources to detect multi-stage attacks. They are not used for single-event detection like a new VM creation.

Question 5mediummultiple choice

A security team uses Microsoft Sentinel. They want to detect a potential privilege escalation scenario: when a user is added to the Global Administrator role in Azure AD (audit log) and within 10 minutes that user signs in from a suspicious location (sign-in log). Which type of analytics rule should they create to correlate these two different log sources?

Trap 1: Fusion rule

Fusion rules are built-in, Microsoft-managed analytics rules that leverage machine learning to correlate alerts from multiple security products into a multi-stage attack story. They do not accept custom KQL queries or allow users to specify cross-table join logic, so they cannot be adapted for a custom detection based on specific correlation requirements.

Trap 2: Anomaly rule

Anomaly rules use built-in machine learning models to detect outliers against a learned baseline for individual data sources, such as user sign-ins or behavior from a specific product. They do not support custom KQL joins across different tables, so they cannot correlate events from multiple sources to uncover a custom multi-event attack pattern.

Trap 3: NRT rule (Near Real-Time)

Near Real-Time (NRT) rules are a specific category of scheduled query rules designed for 1-minute latency, but they restrict query syntax and data set size to maintain speed. While they can join some tables, the limited query complexity and lack of support for certain operators make them less suitable for complex cross-source correlation, making the broader 'Scheduled query rule' category the correct answer.

A
Fusion rule
Why wrong: Fusion rules are built-in, Microsoft-managed analytics rules that leverage machine learning to correlate alerts from multiple security products into a multi-stage attack story. They do not accept custom KQL queries or allow users to specify cross-table join logic, so they cannot be adapted for a custom detection based on specific correlation requirements.
B
Scheduled query rule
Scheduled query rules are the correct choice because they let you author custom KQL queries that join multiple tables such as SecurityEvent, SigninLogs, and CommonSecurityLog to correlate events across data sources. By setting a query schedule and alert logic, you can precisely define the multi-source correlation the security team needs.
C
Anomaly rule
Why wrong: Anomaly rules use built-in machine learning models to detect outliers against a learned baseline for individual data sources, such as user sign-ins or behavior from a specific product. They do not support custom KQL joins across different tables, so they cannot correlate events from multiple sources to uncover a custom multi-event attack pattern.
D
NRT rule (Near Real-Time)
Why wrong: Near Real-Time (NRT) rules are a specific category of scheduled query rules designed for 1-minute latency, but they restrict query syntax and data set size to maintain speed. While they can join some tables, the limited query complexity and lack of support for certain operators make them less suitable for complex cross-source correlation, making the broader 'Scheduled query rule' category the correct answer.

Question 6easymultiple choice

A security administrator is troubleshooting network connectivity to an Azure virtual machine. The VM is behind a network security group (NSG) that has a deny-all inbound rule as the default. The administrator wants to quickly verify whether a specific TCP packet on port 3389 from their client IP (203.0.113.50) would be allowed or blocked by the NSG. Which Azure Network Watcher tool should they use?

Trap 1: Network Performance Monitor.

Network Performance Monitor (NPM) is an Azure Monitor-based solution that measures network latency, packet loss, and topology across virtual machines, ExpressRoute, and VPN connections. It relies on agents installed on monitored endpoints to gather performance telemetry and cannot simulate a specific packet against a network security group (NSG). Therefore, while NPM helps identify degraded or failing network paths, it is not designed to validate whether a particular NSG rule permits or denies a given traffic flow, making it incorrect for this troubleshooting scenario.

Trap 2: Next hop.

The Next hop capability in Network Watcher identifies the next hop type and IP address for a packet based on the effective route table associated with a VM—for example, Internet, VirtualNetworkGateway, or a virtual appliance—but it does not inspect NSG rules. A route may correctly point to a valid next hop, yet an NSG rule can still block the traffic before it leaves the VM. Consequently, Next hop is designed for diagnosing routing issues and cannot validate the allow/deny decisions made by network security groups.

Trap 3: NSG diagnostics (flow logs).

NSG diagnostics (flow logs) continuously capture information about IP traffic flowing through an NSG, recording allow/deny outcomes, source/destination addresses, ports, and packet counts into a storage account or Log Analytics workspace for historical analysis. These logs are not interactive: they do not let you simulate an arbitrary test packet on demand and are instead analyzed after the fact using queries or network monitoring tools. Because flow logs require enabling diagnostics and waiting for data to accumulate, they are unsuitable for immediate, packet-specific NSG rule validation, unlike IP flow verify.

A
Network Performance Monitor.
Why wrong: Network Performance Monitor (NPM) is an Azure Monitor-based solution that measures network latency, packet loss, and topology across virtual machines, ExpressRoute, and VPN connections. It relies on agents installed on monitored endpoints to gather performance telemetry and cannot simulate a specific packet against a network security group (NSG). Therefore, while NPM helps identify degraded or failing network paths, it is not designed to validate whether a particular NSG rule permits or denies a given traffic flow, making it incorrect for this troubleshooting scenario.
B
IP flow verify.
IP flow verify, part of Azure Network Watcher, takes a specified protocol, source IP/port, destination IP/port, and the target virtual machine’s network interface to simulate an actual packet. The tool then evaluates the effective security rules applied at both the subnet and network interface levels and returns an allow or deny decision along with the exact rule that allowed or blocked the traffic. This makes it the correct choice for validating NSG rules because it directly answers whether a specific packet is permitted in real time.
C
Next hop.
Why wrong: The Next hop capability in Network Watcher identifies the next hop type and IP address for a packet based on the effective route table associated with a VM—for example, Internet, VirtualNetworkGateway, or a virtual appliance—but it does not inspect NSG rules. A route may correctly point to a valid next hop, yet an NSG rule can still block the traffic before it leaves the VM. Consequently, Next hop is designed for diagnosing routing issues and cannot validate the allow/deny decisions made by network security groups.
D
NSG diagnostics (flow logs).
Why wrong: NSG diagnostics (flow logs) continuously capture information about IP traffic flowing through an NSG, recording allow/deny outcomes, source/destination addresses, ports, and packet counts into a storage account or Log Analytics workspace for historical analysis. These logs are not interactive: they do not let you simulate an arbitrary test packet on demand and are instead analyzed after the fact using queries or network monitoring tools. Because flow logs require enabling diagnostics and waiting for data to accumulate, they are unsuitable for immediate, packet-specific NSG rule validation, unlike IP flow verify.

Question 7hardmultiple choice

Your company uses Microsoft Sentinel to correlate data from multiple sources. You need to create an analytics rule that triggers an incident when a user signs in from an unfamiliar location and then performs a high-risk action in Azure. What is the best approach?

Trap 1: Run a custom anomaly detection job

Anomaly detection is for baseline deviations, not explicit correlation.

Trap 2: Create a Scheduled analytics rule with a KQL query

Creating a Scheduled analytics rule with a KQL query is unsuitable because it primarily focuses on detecting patterns or thresholds within a single query execution over a defined time window, not on tracking a user's state across sequential, distinct events. The scenario requires correlating an initial unfamiliar sign-in with a subsequent high-risk action, which demands a more stateful or behavioural detection mechanism. This option is tempting as scheduled rules are the most common type, ideal for identifying specific known patterns, aggregations, or anomalies that can be captured by a single KQL query run at regular intervals, such as detecting multiple failed sign-ins from a single IP address.

Trap 3: Create a Near-Real-Time (NRT) analytics rule

NRT rules are for single event types.

A
Run a custom anomaly detection job
Why wrong: Anomaly detection is for baseline deviations, not explicit correlation.
B
Create a Scheduled analytics rule with a KQL query
Why wrong: Creating a Scheduled analytics rule with a KQL query is unsuitable because it primarily focuses on detecting patterns or thresholds within a single query execution over a defined time window, not on tracking a user's state across sequential, distinct events. The scenario requires correlating an initial unfamiliar sign-in with a subsequent high-risk action, which demands a more stateful or behavioural detection mechanism. This option is tempting as scheduled rules are the most common type, ideal for identifying specific known patterns, aggregations, or anomalies that can be captured by a single KQL query run at regular intervals, such as detecting multiple failed sign-ins from a single IP address.
C
Create a Near-Real-Time (NRT) analytics rule
Why wrong: NRT rules are for single event types.
D
Create a Fusion analytics rule
Fusion rules correlate multiple alerts from different sources.

Read the full Ansible explanation →

Question 8mediummultiple choice

A security analyst uses Microsoft Sentinel. They have created a playbook that tags Azure VMs as 'isolated' when a high-severity malware alert is triggered. They want this playbook to run automatically whenever a related alert is generated. Which feature should they configure?

Trap 1: Scheduled analytics rule.

A scheduled analytics rule is a query-based detection that runs at defined intervals and creates incidents when results match the query. It does not contain any capability to execute playbooks; instead, it only generates the incident record. To trigger a playbook on those incidents, you must attach an automation rule that responds to the incident creation event.

Trap 2: Incident creation rule.

There is no dedicated 'incident creation rule' object in Microsoft Sentinel's architecture. Incidents are produced by analytics rules, such as scheduled or Microsoft security rules, or imported from external sources, but the platform does not expose a separate rule type solely for incident creation. Automation rules were introduced specifically to handle post-creation actions like invoking playbooks.

Trap 3: Workbook.

Workbooks in Sentinel are interactive dashboards that visualize data through queries and metrics, providing operational insight and reporting. They are purely for display and analysis; they do not contain logic to execute playbooks or perform automated responses. Thus, a workbook cannot be used to run a playbook automatically.

A
Automation rule.
Automation rules in Microsoft Sentinel enable automated incident management by executing playbooks directly in response to incident creation or update events. You can define conditions based on alert properties and specify actions like running a playbook, changing status, or assigning ownership. This is the correct mechanism to run a playbook automatically without manual intervention.
B
Scheduled analytics rule.
Why wrong: A scheduled analytics rule is a query-based detection that runs at defined intervals and creates incidents when results match the query. It does not contain any capability to execute playbooks; instead, it only generates the incident record. To trigger a playbook on those incidents, you must attach an automation rule that responds to the incident creation event.
C
Incident creation rule.
Why wrong: There is no dedicated 'incident creation rule' object in Microsoft Sentinel's architecture. Incidents are produced by analytics rules, such as scheduled or Microsoft security rules, or imported from external sources, but the platform does not expose a separate rule type solely for incident creation. Automation rules were introduced specifically to handle post-creation actions like invoking playbooks.
D
Workbook.
Why wrong: Workbooks in Sentinel are interactive dashboards that visualize data through queries and metrics, providing operational insight and reporting. They are purely for display and analysis; they do not contain logic to execute playbooks or perform automated responses. Thus, a workbook cannot be used to run a playbook automatically.

Review the full subnetting walkthrough →

Question 9hardmultiple choice

A company has two Azure virtual networks, VNet-A and VNet-B, connected via VNet peering. They want all traffic between the VNets to be inspected by a network virtual appliance (NVA) deployed in a subnet in VNet-A. They have configured a user-defined route (UDR) on the subnet in VNet-B that points the destination address space of VNet-A to the private IP of the NVA. However, traffic between the VNets is still not passing through the NVA. What is the most likely cause?

Trap 1: The UDR is not associated with the subnet in VNet-B.

This is not the cause because the effective route table for traffic originating in VNet-A is determined by the subnets in VNet-A, not by any UDR in VNet-B. Traffic from the source VMs in VNet-A to the NVA's private IP is governed by the UDR associated with the source subnet; a missing or misassociated UDR on a VNet-B subnet has no influence on that first hop. Since the scenario states they configured a UDR on the source subnet and connectivity exists (traffic flows, just not through the NVA), a VNet-B association failure cannot explain why packets bypass the NVA.

Trap 2: The VNet peering connection is not in a 'Connected' state.

If the VNet peering connection were not in a 'Connected' state, there would be no traffic at all between VNet-A and VNet-B, including the direct path the traffic is currently taking. The fact that traffic is flowing end-to-end (from source VMs to destination) proves the peering is functional and listed as 'Connected'. Peering state affects connectivity between the virtual networks, not whether a next hop in a UDR is honored, so a disconnected peering cannot be the reason the NVA is being bypassed.

Trap 3: The NVA is deployed in the same subnet as the source VMs.

Deploying the NVA in the same subnet as the source VMs is not inherently a problem and does not obviate the need for IP forwarding. When a UDR's next hop is an NVA's private IP, Azure routes packets to that IP directly if the NVA is in the same subnet; the NVA then needs IP forwarding to send them onward. Therefore, same-subnet placement does not prevent packet delivery to the NVA, and it is not the cause of the routing failure — the missing IP-forwarding flag on the NVA's NIC is.

A
The UDR is not associated with the subnet in VNet-B.
Why wrong: This is not the cause because the effective route table for traffic originating in VNet-A is determined by the subnets in VNet-A, not by any UDR in VNet-B. Traffic from the source VMs in VNet-A to the NVA's private IP is governed by the UDR associated with the source subnet; a missing or misassociated UDR on a VNet-B subnet has no influence on that first hop. Since the scenario states they configured a UDR on the source subnet and connectivity exists (traffic flows, just not through the NVA), a VNet-B association failure cannot explain why packets bypass the NVA.
B
The NVA's network interface (NIC) does not have IP forwarding enabled.
IP forwarding must be explicitly enabled on the network interface (NIC) of the NVA before Azure will deliver packets whose destination IP is not assigned to that NIC. Without it, the Azure fabric drops packets that are addressed to other IPs, so even if the NVA's operating system is configured to route traffic, the packets never reach it. This is the most common omission when deploying NVAs with UDRs, and it precisely explains why traffic flows end-to-end via peering but not through the NVA — the NVA silently discards (or never receives) the forwarded packets.
C
The VNet peering connection is not in a 'Connected' state.
Why wrong: If the VNet peering connection were not in a 'Connected' state, there would be no traffic at all between VNet-A and VNet-B, including the direct path the traffic is currently taking. The fact that traffic is flowing end-to-end (from source VMs to destination) proves the peering is functional and listed as 'Connected'. Peering state affects connectivity between the virtual networks, not whether a next hop in a UDR is honored, so a disconnected peering cannot be the reason the NVA is being bypassed.
D
The NVA is deployed in the same subnet as the source VMs.
Why wrong: Deploying the NVA in the same subnet as the source VMs is not inherently a problem and does not obviate the need for IP forwarding. When a UDR's next hop is an NVA's private IP, Azure routes packets to that IP directly if the NVA is in the same subnet; the NVA then needs IP forwarding to send them onward. Therefore, same-subnet placement does not prevent packet delivery to the NVA, and it is not the cause of the routing failure — the missing IP-forwarding flag on the NVA's NIC is.

Question 10mediummultiple choice

A security team uses Microsoft Sentinel. They want to create a custom detection rule that identifies a potential data exfiltration scenario: when a user signs in from an unusual location and then, within 30 minutes, performs a large download from Azure Blob Storage. They need to correlate sign-in logs from Azure AD with storage diagnostic logs. Which type of analytics rule should they create in Microsoft Sentinel?

Trap 1: An NRT (near-real-time) rule

NRT rules provide low-latency detection but cannot join multiple data sources, which is required for correlating sign-ins and storage access.

Trap 2: A fusion rule

Fusion rules use advanced correlation to identify multi-stage attacks, but they are not customizable for specific user-defined patterns.

Trap 3: A machine learning-based analytics rule

ML-based rules use built-in anomaly detection models and are not designed for custom correlation of specific event sequences.

A
A scheduled query rule using KQL
Scheduled rules can run KQL queries that join multiple tables (e.g., SigninLogs and StorageBlobLogs) to correlate events and trigger alerts when the pattern is detected.
B
An NRT (near-real-time) rule
Why wrong: NRT rules provide low-latency detection but cannot join multiple data sources, which is required for correlating sign-ins and storage access.
C
A fusion rule
Why wrong: Fusion rules use advanced correlation to identify multi-stage attacks, but they are not customizable for specific user-defined patterns.
D
A machine learning-based analytics rule
Why wrong: ML-based rules use built-in anomaly detection models and are not designed for custom correlation of specific event sequences.