Domain 4: Practice Q&A — Virtual Networking

Answer each question before expanding the solution. Aim for under 2 minutes per question.

Q1

You have three VNets: A, B, and C. VNet A is peered with VNet B. VNet B is peered with VNet C. A VM in VNet A tries to communicate with a VM in VNet C. The communication fails. What is the reason?

  • A. Cross-VNet peering is not supported across more than one hop
  • B. VNet peering is non-transitive — there is no direct peering between A and C
  • C. VMs in different VNets can only communicate through a VPN Gateway
  • D. The NSG on VNet C is blocking inbound traffic from VNet A's address space
Answer + Explanation

Correct: B — VNet peering is non-transitive

Why B: Peering only creates direct connectivity between the two peered VNets. A→B and B→C are separate peering relationships. There is no transitive route from A to C through B. To enable A↔C, you must either create a direct A↔C peering OR configure VNet B as a transit hub with an NVA/Azure Firewall and enable forwarded traffic.

Why not A: "Not supported across more than one hop" is a consequence of non-transitivity, not a product limitation you can work around with a feature.

Why not C: VMs in peered VNets communicate directly without a VPN Gateway. VPN is for on-premises connectivity or cross-region when peering isn't used.

Why not D: Possibly true but it's not the reason the question describes — the structural issue is the missing peering.

Q2

A subnet has an NSG associated with it and its VMs have NSGs associated with their NICs. Inbound traffic on port 443 is allowed in the subnet NSG but denied in the NIC NSG. What is the outcome?

  • A. Traffic is allowed — subnet NSG is evaluated first and overrides NIC NSG
  • B. Traffic is denied — both NSGs must allow traffic for inbound connections
  • C. Traffic is allowed — NIC NSG takes precedence on inbound traffic
  • D. The configuration is invalid — NSGs cannot be applied to both subnet and NIC simultaneously
Answer + Explanation

Correct: B — Both NSGs must allow traffic

Why B: For inbound traffic, the subnet NSG is evaluated first, then the NIC NSG. Traffic must pass both. If the NIC NSG denies port 443, the traffic is blocked — even though the subnet NSG allows it.

For outbound traffic, the order is reversed: NIC NSG first, then subnet NSG.

Why not A: Subnet NSG doesn't override NIC NSG — they are both enforced. The more restrictive combined result applies.

Why not C: NIC NSG doesn't take precedence on inbound — it's evaluated second, after the subnet NSG.

Why not D: This is a completely valid and common configuration (defense in depth).

Exam tip: Inbound = Subnet NSG → NIC NSG (both must allow). Outbound = NIC NSG → Subnet NSG (both must allow).

Q3

Your organization wants to connect its on-premises datacenter to Azure. The requirements are:

  • Consistent sub-5ms latency
  • 10 Gbps bandwidth
  • Private connection — traffic must not traverse the public internet

Which solution meets all three requirements?

  • A. Site-to-Site VPN Gateway (VpnGw3 SKU)
  • B. Point-to-Site VPN
  • C. Azure ExpressRoute
  • D. VNet peering with BGP routing
Answer + Explanation

Correct: C — Azure ExpressRoute

Why C: ExpressRoute provides a dedicated private connection through a connectivity provider, with bandwidth options up to 100 Gbps, consistent low latency, and no traffic over the public internet. It's the only option that satisfies all three requirements simultaneously.

Why not A: VPN Gateway max is ~1.25 Gbps (VpnGw3). It also runs over the public internet (encrypted, but not private). It cannot guarantee sub-5ms latency.

Why not B: Point-to-Site is for individual client devices — not suitable for datacenter-level connectivity.

Why not D: VNet peering connects Azure VNets to each other — it doesn't extend to on-premises networks.

Q4

You have a Standard Azure Load Balancer with two VMs in the backend pool. The LB is correctly configured with a health probe and load balancing rule on port 80. Users report the VMs are unreachable through the LB public IP. What is the most likely cause?

  • A. The health probe is checking the wrong port
  • B. The backend VMs do not have NSGs allowing inbound traffic on port 80 from the Load Balancer
  • C. Standard SKU public IPs cannot be used with Standard Load Balancers
  • D. The Load Balancer SKU must match the VM SKU
Answer + Explanation

Correct: B — Standard LB requires NSG to allow traffic

Why B: Unlike Basic Load Balancer, Standard Load Balancer requires backend resources to have an NSG that explicitly allows the load-balanced traffic. By default, Standard LB backend VMs are not reachable unless an NSG allows inbound traffic from AzureLoadBalancer service tag or the specific frontend IP.

Why not A: Possible but not the most likely cause for a "correctly configured" LB scenario the question describes.

Why not C: Standard SKU public IPs are required for Standard Load Balancers — they are compatible, not incompatible.

Why not D: There is no such requirement.

Exam tip: Any question where a Standard LB is configured but VMs are unreachable → check NSG first. This is the #1 Standard LB exam trap.

Q5

You add a User-Defined Route (UDR) to a subnet with:

  • Destination: 0.0.0.0/0
  • Next hop type: VirtualAppliance
  • Next hop IP: 10.0.99.4 (Azure Firewall private IP)

A VPN Gateway is also connected to this VNet and advertises a route for 10.1.0.0/16 via BGP. What happens to traffic destined for 10.1.5.200?

  • A. Traffic follows the BGP route to the VPN Gateway
  • B. Traffic follows the UDR to the Azure Firewall because UDR overrides BGP
  • C. Traffic is dropped — conflicting routes cause a routing loop
  • D. Both routes are used in a round-robin fashion
Answer + Explanation

Correct: A — BGP route for 10.1.0.0/16 is more specific than the UDR for 0.0.0.0/0

Wait — this is a nuance question:

The UDR is 0.0.0.0/0 (default route — least specific). The BGP route is 10.1.0.0/16 (more specific). Azure routing uses longest prefix match — the more specific route wins. So traffic to 10.1.5.200 matches 10.1.0.0/16 (more specific) and follows the BGP route, not the default UDR.

If the UDR were also 10.1.0.0/16, then the UDR would win over BGP (same prefix, UDR takes precedence).

The key rule: Longest prefix match first. Among equal prefixes, UDR > BGP > system default.

Why not C: Azure doesn't create routing loops — it selects the best route.

Why not D: Azure routing is deterministic, not round-robin.

Exam tip: "UDR overrides BGP" is true only when they have the same prefix length (or UDR is more specific). If BGP has a more specific prefix, BGP wins via longest prefix match.

Q6

You need to allow VMs in a spoke VNet to use the hub VNet's VPN Gateway to connect to on-premises resources. What must you configure?

  • A. Enable allowGatewayTransit on the spoke-to-hub peering
  • B. Enable allowGatewayTransit on the hub-to-spoke peering, and useRemoteGateways on the spoke-to-hub peering
  • C. Enable useRemoteGateways on both peering connections
  • D. Create a VPN Gateway in each spoke VNet
Answer + Explanation

Correct: B — allowGatewayTransit on hub side, useRemoteGateways on spoke side

Why B: The settings are:

  • Hub-to-spoke peering: Enable allowGatewayTransit — "I (the hub) allow traffic to transit through my gateway."
  • Spoke-to-hub peering: Enable useRemoteGateways — "I (the spoke) want to use the hub's gateway instead of my own."

Both must be set correctly on their respective sides.

Why not A: allowGatewayTransit must be on the hub side (where the gateway lives), not the spoke side.

Why not C: useRemoteGateways only makes sense on the spoke side — setting it on the hub side means the hub would try to use the spoke's gateway (which doesn't exist).

Why not D: The entire point of gateway transit is to share one gateway across spokes — separate gateways defeat the purpose and cost significantly more.

Q7

You are designing private connectivity for an Azure SQL Database. You want the database to have a private IP address in your VNet and be inaccessible from the public internet, including from within Azure's public network.

Which solution should you use?

  • A. Service endpoint for Microsoft.Sql
  • B. Private endpoint for the SQL server
  • C. VNet-integrated App Service connecting to Azure SQL
  • D. Azure SQL Managed Instance
Answer + Explanation

Correct: B — Private endpoint

Why B: A Private Endpoint creates a private IP address in your VNet for the Azure SQL server. The DNS name resolves to the private IP. Public access can be completely disabled at the SQL server level. Traffic stays entirely within the VNet — even accessible over VPN/ExpressRoute from on-premises.

Why not A: Service endpoints keep traffic on the Azure backbone but the SQL server still has a public IP — traffic goes to the public endpoint, just with an optimized path. The SQL server is still publicly accessible from other Azure regions or the internet unless specifically firewalled.

Why not C: VNet integration allows the App Service to reach out to VNet resources, but it doesn't make the SQL server have a private IP — that's a different concern.

Why not D: Azure SQL Managed Instance is a different product (full SQL Server compatibility) — it does run within your VNet natively, but it's not the answer for making an existing Azure SQL Database private.

Q8

You configure an NSG inbound rule with priority 200, Allow, port 80. You also have the default DenyAllInBound rule at priority 65500. A VM's NIC has no separate NSG. Traffic on port 443 from the internet arrives at the VM. What happens?

  • A. Traffic is allowed because the default AllowVnetInBound covers it
  • B. Traffic is denied — the explicit Allow rule only covers port 80, and the default deny covers all other ports
  • C. Traffic is allowed because there is no explicit deny rule for port 443
  • D. Traffic is allowed because the NIC has no separate NSG
Answer + Explanation

Correct: B — Port 443 is denied by the default DenyAllInBound rule

Why B: The NSG has an explicit Allow for port 80 (priority 200). Traffic on port 443 doesn't match any allow rule, so it falls through to the default DenyAllInBound at priority 65500, which denies all unmatched inbound traffic.

Why not A: AllowVnetInBound only applies to traffic with source VirtualNetwork service tag (i.e., traffic from within the same VNet). Traffic from the internet is sourced from Internet, not VirtualNetwork.

Why not C: Not having an explicit Deny doesn't mean Allow. If no Allow rule matches, the default Deny catches it.

Why not D: The NIC having no separate NSG means only the subnet NSG applies. The subnet NSG still denies port 443.

Exam tip: NSG evaluation is: find the lowest priority matching rule, apply it. If no rule matches except the defaults, the default Deny catches all unmatched traffic. There is no "implicit allow" for any traffic from the internet.