Troubleshooting Scenario Questions

The policy is configured to require MFA for all locations regardless of trust

Why it fails: If the policy were configured to require MFA for all locations regardless of trust, then users outside the office would also be challenged, but more importantly the trusted-location condition would be ignored entirely. However, the problem description indicates the policy is intended to require MFA only from outside trusted locations, so the location condition must still be scoped to trusted locations. A misconfigured 'any location' condition would produce broad MFA prompts across all networks, not a specific failure at the corporate office. Therefore, this setting does not explain the observed issue.

The policy is set to 'Require MFA' instead of 'Require MFA from trusted locations'

Why it fails: There is no separate Conditional Access grant called 'Require MFA from trusted locations'; rather, an administrator uses the Locations condition to include or exclude trusted named locations and then applies a standard 'Require MFA' grant to that scope. The description in the problem states the policy requires MFA from trusted locations, meaning the administrator already scoped the location condition correctly so trusted locations are evaluated as exempt. If the grant were simply 'Require MFA' without the location exclusion, users at the office would still be prompted but only because of the missing condition, not because of the grant control name. Since the policy description already reflects the intended location-aware behavior, this option is not the root cause.

Users are not assigned to the policy

Why it fails: If users were not assigned to the Conditional Access policy, the policy would have no effect on their sign-ins, and they would not receive an MFA challenge from this policy. The fact that users are being prompted proves they are in scope—either directly, through a group, or through all users—and the policy is being evaluated. An assignment omission would cause silent success without MFA, which is the opposite of the reported symptom. Therefore, user assignment is not the cause of the MFA prompt at the corporate office.

Next hop

Why it fails: Next hop diagnostics in Network Watcher determines the route and next hop IP address for traffic sent from a VM to a given destination. It only reveals the routing path (e.g., to Azure Firewall or a virtual appliance) and does not evaluate whether any security rules along that path allow or deny the packet. Even if the next hop is correctly set to Azure Firewall, the firewall may still drop the traffic, so this tool cannot confirm the specific firewall rule that blocked it.

Network Performance Monitor

Why it fails: Network Performance Monitor is a Network Watcher-based monitoring solution designed to measure latency, packet loss, and network availability between endpoints using monitoring agents. It provides aggregate performance metrics and alerts but does not simulate individual packets through security rule evaluation. As a result, it cannot determine whether Azure Firewall is denying a particular traffic flow or identify the specific rule responsible for the drop.

IP flow verify

Why it fails: IP flow verify in Azure Network Watcher is the correct tool because it simulates a packet with the exact source IP, destination IP, protocol, and port, then evaluates it against all effective security rules, including Azure Firewall rules and NSG rules. It returns a definitive 'Allowed' or 'Denied' result and lists the specific rule that caused the decision, enabling precise identification of the firewall rule blocking traffic. This targeted diagnostic makes it superior to the other options for troubleshooting a suspected Azure Firewall deny.

The ExpressRoute circuit is not configured for DNS forwarding.

Why it fails: ExpressRoute is a Layer 3 connectivity service that extends an on-premises network into Azure; it does not provide DNS resolution or DNS forwarding. DNS forwarding is a server-side function performed by a DNS resolver (e.g., the custom DNS server you configured for the virtual network). An ExpressRoute circuit only carries IP traffic—including DNS queries—but it cannot be 'configured for DNS forwarding' itself. Therefore, the issue is not a missing DNS forwarder on the circuit, but a missing conditional forwarder on your custom DNS server.

The Azure Private DNS zone does not include the on-premises hostname.

Why it fails: Azure Private DNS zones are used to provide DNS resolution for records within a virtual network (or networks linked to the zone), such as custom domain names that you create in Azure. An on-premises hostname is not a record in any Azure Private DNS zone, and adding it there would not make your custom DNS server forward queries to the on-premises DNS. The core problem is the lack of a forwarding path from the Azure-side DNS resolver to the on-premises DNS infrastructure, not a missing zone or record in Azure. Additionally, Private DNS zones are not designed for integrating with on-premises DNS servers—that integration is done via conditional forwarders or DNS server-to-server zone transfers.

An NSG rule is blocking DNS traffic.

Why it fails: An NSG rule that blocks DNS traffic would prevent the VM from sending or receiving UDP/TCP port 53 traffic to whatever DNS server it uses. However, the symptom is that name resolution fails specifically for an on-premises hostname, while IP connectivity works—if an NSG blocked DNS, all name resolution would fail, not just for on-prem names, and you likely couldn't resolve Azure names either. Furthermore, NSGs apply to traffic entering/leaving network interfaces or subnets; they do not selectively filter which DNS names can be resolved. Since the VM can reach the on-premises host by IP, the underlying network path is fine, ruling out NSG blocking as the cause.

The VNet is peered with another VNet that has a conflicting address space.

Why it fails: VNet peering address space conflicts are irrelevant here because VM1 and VM2 reside within the same VNet. Azure VNet peering is a connection between separate VNets, and any overlapping address space would only prevent peering or affect cross-VNet routing; it does not alter the built-in system routes that deliver intra-VNet traffic between two subnets in the same VNet. Thus, a conflicting peered address space cannot explain a failure to reach VM2 on port 8080.

An Azure Load Balancer is directing traffic away from VM2.

Why it fails: An Azure Load Balancer operates at Layer 4 and only handles traffic destined for its own frontend IP address and port configuration. Direct traffic from VM1 to VM2's private IP address does not traverse the load balancer, because the load balancer is not inserted into the data path for VM-to-VM communications within a VNet. Even if VM2 is in the backend pool, the load balancer only influences traffic that is explicitly sent to its frontend, so it cannot 'direct traffic away' from VM2 in this scenario.

The NSG on VM2's subnet has a deny rule for port 8080.

Why it fails: The scenario explicitly states that the NSG on VM2's subnet allows port 8080 inbound. NSGs are stateful packet filters that evaluate traffic at the subnet or NIC level, and if there were a deny rule for port 8080, it would block the connection before it ever reached the guest OS. Since no such deny rule exists (or the existing allow rule applies), the NSG is not the cause of the connectivity failure.

The analytics rule does not include MITRE ATT&CK tactics

Why it fails: MITRE ATT&CK tactics are optional metadata on an analytics rule used for threat classification, investigations, and reporting; they have no role in the automation runtime. A playbook can still read and update incidents regardless of whether the triggering rule specified techniques or tactics. Therefore, omitting tactics would never block the Sentinel API permissions check or cause an incident-update failure.

The Log Analytics workspace is not linked to Azure Monitor Private Link

Why it fails: Azure Monitor Private Link is only needed when you require private, network-isolated connectivity to your Log Analytics workspace, for example over a VNet. If a Private Link is not linked, the workspace remains reachable via the public endpoint, so the playbook's managed identity call to update the incident is not blocked by network restrictions. The failure is instead an authorization problem, not a connectivity or workspace-network issue.

The incident title does not contain an entity mapping

Why it fails: Entity mappings in an analytics rule define which fields become entities (e.g., account, host, IP) for investigation and UEBA analytics. Incident title is a display string and has no effect on the Logic Apps connection or on the entitlement of the managed identity to call the Sentinel incident-update endpoint. A missing entity mapping would merely reduce context in the incident, not cause a permission or API error.

Network Performance Monitor.

Why it fails: 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.

Next hop.

Why it fails: 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.

NSG diagnostics (flow logs).

Why it fails: 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.

Azure Monitor logs

Why it fails: Azure Monitor logs aggregate metrics, activity logs, and resource diagnostics from Azure services, but they do not natively contain the per-flow IP records produced by NSG flow logs. To store and query those flow records, you must explicitly configure NSG flow logs to ship to a storage account or a Log Analytics workspace, and then use Azure Monitor to analyze them. Simply enabling Azure Monitor does not give an organization the raw flow data; it only serves as a downstream analytics platform once the data is routed to it.

Traffic Analytics

Why it fails: Traffic Analytics is an add-on to Network Watcher that visualizes and summarizes NSG flow logs, offering dashboards with top talkers, denied traffic, and geographic flows. It does not capture or store the underlying flow data itself; it relies on NSG flow logs being already sent to a Log Analytics workspace. Therefore, if flow logs are not enabled, Traffic Analytics has no data to analyze, making it a post-processing tool rather than a data source.

Azure Firewall logs

Why it fails: Azure Firewall logs record traffic that actually passes through the Azure Firewall service, which is only present in a specific subnet and only sees traffic that is route-forced to it. Many VMs use network security groups (NSGs) instead of a firewall, so traffic to and from those VMs would never appear in firewall logs. Even when a firewall is present, NSG flow logs are still needed to cover the full subnet-level activity, because firewall logs omit traffic that is denied by an NSG before it reaches the firewall.

Update the AKS cluster's DNS server to use a custom DNS that can resolve the private endpoint.

Why it fails: Updating the AKS cluster's DNS server to a custom resolver is unnecessary because AKS nodes already use Azure-provided DNS by default. The correct mechanism is to link the private DNS zone to the AKS virtual network so Azure DNS transparently resolves the endpoint's FQDN to the private IP. Adding a custom DNS server introduces an extra configuration layer that can cause split-horizon resolution issues and is not required for private endpoint connectivity.

Delete the private endpoint and configure ACR firewall rules to allow the AKS subnet.

Why it fails: Deleting the private endpoint and relying on ACR firewall rules would route AKS pull traffic through the ACR public endpoint over the internet, defeating the purpose of private connectivity. Even if the firewall is scoped to allow only the AKS subnet, the traffic egresses to a public IP, exposing the registry to internet-borne threats and violating a security design that requires private link. This approach also breaks if the ACR is configured to disable public network access, so it is not a valid fix.

Recreate the AKS cluster with a different managed identity that has ACR pull permissions.

Why it fails: Recreating the AKS cluster with a different managed identity will not resolve the pull failure because the issue is at the network and DNS layer, not authentication. The currently assigned identity likely already has ACR Pull permissions; the kubelet cannot even reach the registry to present those credentials if the private endpoint's DNS name does not resolve to the private IP in the AKS subnet. Recreating a cluster is a disruptive, unnecessary step that ignores the root cause and would not change the DNS resolution behavior without the private DNS zone link.

The browser is blocking persistent cookies

Why it fails: This is incorrect because while blocking persistent cookies can affect how long a user stays signed in across browser restarts, it does not control periodic reauthentication while the session is active. Sign-in frequency is enforced by Microsoft Entra Conditional Access through token claims and policy evaluation, not by cookie storage. Even if persistent cookies are blocked, Microsoft Entra ID would still allow the session to continue until the sign-in frequency interval expires; it would not trigger a reauthentication precisely at the 1-hour mark.

Token lifetime policy overrides the sign-in frequency

Why it fails: This is incorrect because token lifetime policies determine the maximum validity of access or refresh tokens, but they do not override the Conditional Access sign-in frequency control. Sign-in frequency can force a reauthentication earlier than the token lifetime, because it is evaluated separately during each token request against the configured time window. In this scenario, the 1-hour reauthentication is the direct result of the sign-in frequency setting, not an artifact of token expiration or policy precedence.

The user is considered high risk by Identity Protection

Why it fails: This is incorrect because Identity Protection risk-based Conditional Access policies trigger only when a user's risk level is elevated, and they typically respond by requiring MFA, blocking sign-in, or requiring a password change—not by simply demanding reauthentication at a fixed interval. There is no mention of a risk detection, so attributing the prompt to risk would be unfounded. The fixed 1-hour cadence is a hallmark of sign-in frequency, not a risk-based policy.

Hunting queries

Why it fails: Hunting queries are proactive, KQL-based searches that look for suspicious activity across historical and real-time logs, but they are not structured around a single entity's timeline or relationships. They return a set of matching events or raw records, leaving the investigator to correlate and pivot manually. UEBA entity pages, in contrast, aggregate an entity's full activity, peer, and risk insights into a curated view, so hunting queries don't satisfy the entity-focused visualization requirement.

Analytics rules

Why it fails: Analytics rules are detection logic (typically KQL-based) that trigger alerts or incidents when specific patterns, thresholds, or anomalies are matched in ingested data. Their purpose is to fire alerts, not to present an entity's history or connections visually. Even though an alert may link to an incident and later to entity pages, the analytics rule itself is just the detection mechanism, not the entity-focused investigation or visualization tool described in the question.

Workbooks

Why it fails: Workbooks are interactive Azure Monitor-based dashboards that allow data visualization across multiple sources and workspaces, often used for high-level security metrics and reporting. They are generally scoped to an organization, subscription, or scenario rather than to a single entity's investigation timeline. While you could create a custom workbook to show entity-related data, it doesn't provide the automatic, built-in entity-page experience with UEBA investigation insights, so it is not the correct answer for entity-centric visualization.

The user's browser cookies are disabled

Why it fails: SAML SSO relies on the browser to relay messages and maintain the authentication session via cookies after redirects, so disabled cookies can interrupt the sign-in flow. However, if the certificate or metadata is invalid, the application will not accept the SAML assertion regardless of cookie state. This is a client-side condition, not the primary cause of a certificate validation or configuration error.

The application is not registered in the app gallery

Why it fails: Being absent from the Microsoft Entra ID application gallery has no bearing on sign-in, because you can register an application as a custom or non-gallery enterprise app and manually configure SAML endpoints and certificates. The gallery simply provides pre-built templates to simplify configuration. The app could still be fully functional without being listed.

The user does not have a license for Microsoft Entra ID

Why it fails: Microsoft Entra ID Free tier supports SAML-based SSO for enterprise applications, so a user does not require a Premium license to sign in. The user merely needs an active directory account that is assigned to the application. If the user lacks any Entra ID license, they may not have an identity at all, but that is different from not holding a paid license; the free tier covers this scenario.

The custom log file path specified in the DCR is a local path, but AMA requires a network share for custom log collection.

Why it fails: Azure Monitor Agent can readily collect custom logs from local file paths, both on Windows (e.g., `C:\Logs\*.log`) and Linux (e.g., `/var/log/*.log`). Network shares are not required—and often not recommended—because they add permission and reliability complexity. A local path in the DCR is perfectly valid, so this is not the cause of a failed ingestion.

The log file format is not JSON, but AMA only supports custom logs in JSON format.

Why it fails: Azure Monitor Agent's custom log collection supports multiple formats, not just JSON. While JSON with newline-delimited records is one supported layout, the agent also handles plain-text files that follow a defined pattern specified in the DCR's `transformKql` or delimited by a custom separator. The presence of non-JSON logs is therefore not inherently an issue, as long as the transformation logic correctly parses the record boundaries.

The VM does not have local administrator privileges required for the AMA to read the log files.

Why it fails: The Azure Monitor Agent service runs under the `LocalSystem` account on Windows and as `root` or with equivalent privileges on many Linux hosts, giving it the file-system access needed to read local logs. Therefore, the VM administrator account's privileges are not directly relevant to the agent's ability to open log files. A lack of local administrator rights for the user who configures the DCR would not prevent the agent from collecting the logs, so this option is not a valid explanation for the failure.

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

Why it fails: 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.

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

Why it fails: 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.

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

Why it fails: 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.

Delete the VM immediately to stop the process

Why it fails: Deleting the VM destroys volatile memory, disk artefacts and logs needed for forensic analysis, so evidence is lost rather than preserved. It is tempting as containment, and would be correct if the workload were disposable and the priority were stopping active spread with no investigation requirement.

Disable all analytics rules in Sentinel

Why it fails: Disabling Sentinel analytics rules suppresses detection across the environment and does nothing to isolate or capture the endpoint's state. It is tempting when alerts are noisy and analysts want quiet, and would suit planned maintenance windows, not an active investigation requiring evidence retention.

Rotate every subscription key before reviewing the process tree

Why it fails: Rotating subscription keys destroys the authentication context tied to the compromised workload and does not preserve volatile endpoint evidence. It is tempting because key rotation is a standard containment action after credential exposure. Deeper investigation requires collecting the process tree and memory before remediation.