4 of the 13 questions we have for this objective, shown with the answer and the reasoning.
Configure and manage virtual networks in Azure
Dunmore Textiles has a virtual machine named VM-ERP in a subnet that has one network security group associated with the subnet and a second network security group associated with the VM's network interface. Users report they cannot connect to VM-ERP on TCP port 8080 from the on-premises range 192.168.50.0/24. The administrator wants to know, with a single check, whether the traffic is being denied and which specific rule in which NSG is responsible.
Which Network Watcher tool should the administrator use?
- AIP flow verifyIP flow verify takes a VM, direction, protocol, source and destination address and port, and returns Allow or Deny together with the name of the NSG rule that made the decision.
- BPacket capturePacket capture records traffic reaching the VM for offline analysis; it does not evaluate NSG rules or name the blocking rule.
- CTopologyTopology draws a diagram of the resources in a virtual network. It gives no information about rule evaluation.
- DVPN troubleshootVPN troubleshoot diagnoses virtual network gateways and connections, which are not involved in this NSG problem.
Why: When traffic to or from a VM is blocked and you suspect a security rule, IP flow verify is the purpose-built tool. You supply the 5-tuple and direction, and Network Watcher evaluates every NSG that applies to the NIC (subnet-level and NIC-level) and tells you the result and the rule name. The deciding requirement is a single check that identifies the rule. The related NSG diagnostics tool gives even more detail across all applicable NSGs, and Effective security rules lists the merged rule set, but IP flow verify is the classic answer for pinpointing one blocked flow. Packet capture and Topology are legitimate Network Watcher features used wrongly here.
Configure and manage virtual networks in Azure
Tamarind Media has two subscriptions. Sub-Core contains VNet-Core and Sub-Media contains VNet-Media, both in the same Microsoft Entra tenant. An administrator who has the Network Contributor role on both virtual networks used Azure PowerShell to run Add-AzVirtualNetworkPeering once, on VNet-Core, pointing to the resource ID of VNet-Media. In the portal, the peering on VNet-Core shows a peering state of Initiated, and VMs in the two networks cannot communicate.
What should you do to complete the peering?
- AIn Sub-Media, run Add-AzVirtualNetworkPeering on VNet-Media, pointing to the resource ID of VNet-Core, to create the reverse peering link.A peering is a pair of links. The Initiated state means only one side exists; creating the link from VNet-Media to VNet-Core changes both to Connected.
- BDelete the peering on VNet-Core and re-create it as a global virtual network peering.Peering type depends on region, not subscription. Re-creating the same one-sided link leaves it in Initiated.
- CMove VNet-Media into Sub-Core so that both networks are in the same subscription.Peering across subscriptions is fully supported; moving the virtual network is unnecessary and disruptive.
- DEnable the Allow gateway transit setting on the VNet-Core side of the peering.Gateway transit shares a virtual network gateway with peers. It does not establish the peering link.
Why: When you create a peering from the portal, Azure usually creates both links at once because the portal has your credentials for both sides. When you create it with PowerShell, CLI, or templates, each side is a separate resource. A one-sided peering shows Initiated; after the matching link is created from the other virtual network, both sides change to Connected and traffic flows. The deciding detail is the Initiated status, which means only the VNet-Core side of the pair exists. Option A is the only action that completes the pair; note that creating either link requires the Network Contributor role (or the peering write actions) on both virtual networks. The subscription-move distractor is unnecessary because cross-subscription and even cross-tenant peering is supported.
Configure and manage virtual networks in Azure
Pembrook Pharma has a virtual network named VNet-Lab (10.60.0.0/16) with a subnet named snet-isolated (10.60.5.0/24). Compliance requires that VMs in snet-isolated cannot send any traffic to the internet, while they must continue to reach every other subnet in VNet-Lab and the peered virtual network VNet-Tools (10.61.0.0/16). The solution must not rely on a network security group or any additional appliance, and must minimize cost.
What should you configure?
- AA route table associated with snet-isolated that contains a route for 0.0.0.0/0 with next hop type None.A UDR for 0.0.0.0/0 with next hop None drops internet-bound traffic, while the more specific system routes for the virtual network (10.60.0.0/16) and the peering (10.61.0.0/16) still win by longest prefix match.
- BA route table associated with snet-isolated that contains a route for 0.0.0.0/0 with next hop type Virtual network.The Virtual network next hop type exists to override routing for prefixes inside the virtual network address space. It is not the documented way to block internet-bound traffic; the None next hop type exists specifically to drop traffic.
- CA route table associated with snet-isolated that contains routes for 10.60.0.0/16 and 10.61.0.0/16 with next hop type None.This blocks exactly the traffic that must be allowed (other subnets and the peered network) and leaves the default internet route in place.
- DA route table associated with snet-isolated that contains a route for 0.0.0.0/0 with next hop type Virtual appliance and the address of an Azure Firewall deployed in VNet-Lab.Forcing traffic through Azure Firewall could meet the compliance goal, but the scenario forbids additional appliances and requires minimal cost.
Why: Azure route selection uses longest prefix match first, then prefers user-defined routes over BGP and system routes when prefixes are equal. A single UDR for 0.0.0.0/0 with next hop None overrides the system default route to the internet but does not affect the more specific system routes that Azure creates for the local virtual network address space and for each peering. The result is that internal and peered traffic continues normally while anything destined for the internet is silently dropped. The constraints that decide this question are no NSG, no additional appliance, and minimal cost, which eliminate the firewall option. Be aware that such a route also blocks access to Azure PaaS public endpoints unless service endpoints or private endpoints are used.
Configure and manage virtual networks in Azure
Ridgeline Capital has a virtual network named VNet-Core with address space 10.1.0.0/16 and subnets snet-front (10.1.1.0/24) and snet-data (10.1.2.0/24). VNet-Core is peered with VNet-Partner (10.7.0.0/16). A route table named rt-front is associated with snet-front and contains one user-defined route: 10.0.0.0/8 with next hop type Virtual appliance and next hop address 10.1.9.4. An administrator runs the Network Watcher Next hop tool from a VM in snet-front with destination 10.1.2.10 and then again with destination 10.7.3.5.
Which next hop types will the tool report for each destination?
- A10.1.2.10: VirtualAppliance (10.1.9.4); 10.7.3.5: VirtualNetworkPeering.The local address space system route 10.1.0.0/16 is more specific than the 10.0.0.0/8 UDR, so traffic to snet-data stays on the VirtualNetwork next hop rather than going to the appliance.
- B10.1.2.10: VirtualNetwork; 10.7.3.5: VirtualAppliance (10.1.9.4).The system route for the peering, 10.7.0.0/16, is more specific than the 10.0.0.0/8 UDR, so longest prefix match sends peered traffic directly through the peering, not to the appliance.
- C10.1.2.10: VirtualAppliance (10.1.9.4); 10.7.3.5: VirtualAppliance (10.1.9.4).User-defined routes only beat system routes when the prefixes are identical. Here both system routes (10.1.0.0/16 and 10.7.0.0/16) are longer than the /8 UDR, so neither destination goes to the appliance.
- D10.1.2.10: VirtualNetwork; 10.7.3.5: VirtualNetworkPeering; the UDR affects neither destination.Longest prefix match wins before route origin is considered. 10.1.0.0/16 (VirtualNetwork) and 10.7.0.0/16 (VirtualNetworkPeering) are both more specific than 10.0.0.0/8, so the appliance route is bypassed for both.
Why: Azure selects a route by longest prefix match first. Only when multiple routes have exactly the same prefix does origin matter, with user-defined routes preferred over BGP routes, which are preferred over system routes. The deciding detail in this scenario is that the UDR is a broad /8 while the system routes for the local address space and for the peering are /16, so the system routes win for both destinations. To force intra-network or peered traffic through the appliance, the administrator would need UDRs with prefixes at least as specific as the system routes, for example 10.1.2.0/24 or 10.7.0.0/16. The Network Watcher Next hop tool is the fastest way to confirm which route is actually being used, and the Effective routes blade on the NIC shows the full merged table.