Soru

Zorluk: OrtaVirtual Network Connectivity and Routing

An enterprise is designing a hub-and-spoke virtual network topology in Azure. The hub virtual network, `vnet-hub-central`, uses the IP address space 10.10.0.0/1610.10.0.0/16 and hosts an Azure Firewall at 10.10.1.410.10.1.4. There are two spoke virtual networks: `vnet-app-prod` (10.20.0.0/1610.20.0.0/16) and `vnet-db-prod` (10.30.0.0/1610.30.0.0/16). Both spokes are peered directly to `vnet-hub-central`. You need to ensure that all network traffic between `vnet-app-prod` and `vnet-db-prod` is routed through the Azure Firewall for security inspection, while ensuring that resources within `vnet-app-prod` can communicate with each other directly without routing local traffic through the firewall. Which two configurations should you implement? (Select two.)

  1. A route table associated with the subnet in `vnet-app-prod` that contains a route for 10.30.0.0/1610.30.0.0/16 with a next hop of Virtual Appliance pointing to 10.10.1.410.10.1.4Cevap
  2. A route table associated with the subnet in `vnet-db-prod` that contains a route for 10.20.0.0/1610.20.0.0/16 with a next hop of Virtual Appliance pointing to 10.10.1.410.10.1.4Cevap
  3. C
    A route table associated with the subnet in `vnet-app-prod` that contains a route for 10.20.0.0/1610.20.0.0/16 with a next hop of Virtual Appliance pointing to 10.10.1.410.10.1.4
  4. D
    A route table associated with the subnet in `vnet-db-prod` that contains a route for 10.30.0.0/1610.30.0.0/16 with a next hop of Virtual Appliance pointing to 10.10.1.410.10.1.4

Cevap

Configure a route table associated with the subnet in the application spoke VNet with a route for the database spoke prefix pointing to the Azure Firewall, and configure another route table associated with the subnet in the database spoke VNet with a route for the application spoke prefix pointing to the Azure Firewall.
The correct solution involves configuring specific route tables in each spoke VNet to direct traffic destined for the opposite spoke VNet to the Azure Firewall's private IP address. By targeting only the remote spoke's IP space (10.30.0.0/1610.30.0.0/16 for the application spoke, and 10.20.0.0/1610.20.0.0/16 for the database spoke), traffic destined for the other spoke is successfully routed to the firewall, while traffic within the local spoke continues to use the default system Local route.

Adım Adım Çözüm

1
Identify the routing path requirements between spokes.
Traffic from the application spoke (10.20.0.0/1610.20.0.0/16) destined for the database spoke (10.30.0.0/1610.30.0.0/16) must transit the firewall (10.10.1.410.10.1.4) in the hub VNet (10.10.0.0/1610.10.0.0/16).
This establishes security inspection requirements for cross-spoke communication.
2
Define the user-defined route for the application spoke subnet.
Add a UDR for destination 10.30.0.0/1610.30.0.0/16 with a next hop of Virtual Appliance (10.10.1.410.10.1.4).
This overrides the default direct peering routing and forces traffic outbound to the database spoke to flow through the firewall.
3
Define the user-defined route for the database spoke subnet.
Add a UDR for destination 10.20.0.0/1610.20.0.0/16 with a next hop of Virtual Appliance (10.10.1.410.10.1.4).
This ensures symmetric routing, allowing the response traffic from the database spoke to return through the firewall.
4
Verify local subnet routing behavior.
Ensure no UDRs are created targeting the local VNet's own CIDR block (i.e., do not configure 10.20.0.0/1610.20.0.0/16 in the application spoke, or 10.30.0.0/1610.30.0.0/16 in the database spoke).
This prevents overriding the default local system route, maintaining direct and unhindered internal communication within the spoke VNets.

Anahtar Kavram

Azure Virtual Network Peering and User Defined Routes (UDRs)
Tahmini Süre:1m 30s
Bu soruyu puanla