An enterprise is designing a hub-and-spoke virtual network topology in Azure to host a mul… — Microsoft Azure Solutions Architect (AZ-305)

An enterprise is designing a hub-and-spoke virtual network topology in Azure to host a multi-tier application. The architecture includes:
- A hub virtual network named `vnet-hub-core` ( $10.50.0.0/16$ ) that hosts a central Azure Firewall with a private IP address of $10.50.4.4$ .
- A spoke virtual network named `vnet-spoke-web` ( $10.60.0.0/16$ ) containing a subnet named `web-subnet` ( $10.60.1.0/24$ ).
- A spoke virtual network named `vnet-spoke-db` ( $10.70.0.0/16$ ) containing a subnet named `db-subnet` ( $10.70.1.0/24$ ).

Virtual network peering is configured between the hub and each spoke virtual network. Direct virtual network peering is not configured between the two spoke virtual networks.

You need to configure the routing to meet the following requirements:
- All traffic between `web-subnet` and `db-subnet` must be routed through the Azure Firewall for inspection.
- Traffic within each spoke virtual network must remain local and bypass the Azure Firewall.

Which two configurations should you implement?

In the route table associated with `web-subnet`, add a route for $10.70.0.0/16$ with a next hop type of Virtual appliance and next hop IP address $10.50.4.4$ .Cevap
In the route table associated with `db-subnet`, add a route for $10.60.0.0/16$ with a next hop type of Virtual appliance and next hop IP address $10.50.4.4$ .Cevap
C
In the route table associated with `web-subnet`, add a route for $10.60.0.0/16$ with a next hop type of Virtual appliance and next hop IP address $10.50.4.4$ .
D
In the route table associated with the Azure Firewall subnet, add routes for $10.60.0.0/16$ and $10.70.0.0/16$ with a next hop type of Virtual appliance and next hop IP address $10.50.4.4$ .

Cevap

To achieve the desired routing, associate a route table with the web subnet containing a route for the database spoke's address space (

10.70.0.0/16

) pointing to the firewall (

10.50.4.4

), and associate a route table with the database subnet containing a route for the web spoke's address space (

10.60.0.0/16

) pointing to the firewall (

10.50.4.4

To route traffic between the two spoke virtual networks through the Azure Firewall in the hub, you must define User-Defined Routes (UDRs) in the spoke subnets. Specifically, a route for the remote spoke's address space (

10.70.0.0/16

in Spoke A, and

10.60.0.0/16

in Spoke B) must point to the firewall's private IP (

10.50.4.4

) as a Virtual Appliance next hop. Because there is no direct peering between the spokes, this redirect forces transit traffic to flow through the hub firewall. The default system routes within the hub automatically handle forwarding the traffic from the firewall to the destination spoke.

Adım Adım Çözüm

Identify transit routing requirements

Identify that `vnet-spoke-web` needs to reach

10.70.0.0/16

, and `vnet-spoke-db` needs to reach

10.60.0.0/16

Since peering is non-transitive, spoke-to-spoke communication through a hub NVA/Firewall requires explicit routing.

Configure spoke User-Defined Routes (UDRs)

Associate route tables with `web-subnet` and `db-subnet` pointing to the next-hop IP

10.50.4.4

(Azure Firewall).

This overrides default system routing, redirecting spoke-to-spoke transit traffic through the hub firewall.

Avoid defining local address space routes in spokes

Ensure there are no UDRs inside `vnet-spoke-web` for

10.60.0.0/16

or inside `vnet-spoke-db` for

10.70.0.0/16

This keeps local intra-VNet communication intact by relying on the default 'Local' system route.

Anahtar Kavram

Hub-and-spoke transit routing using User-Defined Routes (UDRs) and Virtual Network Peering while preserving local system routes.

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Konular

Bu konudan daha fazla soru