An administrator deploys three virtual networks in an Azure subscription: * **VNet-Hub** (… — Microsoft Azure Administrator (AZ-104)

An administrator deploys three virtual networks in an Azure subscription:

* VNet-Hub ( $172.16.0.0/16$ ), containing a VPN gateway and a virtual machine named VM-Hub ( $172.16.1.4$ ) deployed in Subnet-Hub.
* VNet-Spoke1 ( $172.17.0.0/16$ ), containing a virtual machine named VM-Spoke1 ( $172.17.1.4$ ) deployed in Subnet-Spoke1.
* VNet-Spoke2 ( $172.18.0.0/16$ ), containing a virtual machine named VM-Spoke2 ( $172.18.1.4$ ) deployed in Subnet-Spoke2.

The administrator configures virtual network peering between VNet-Hub and VNet-Spoke1 with 'Allow gateway transit' enabled on VNet-Hub and 'Use remote gateways' enabled on VNet-Spoke1. The administrator also configures virtual network peering between VNet-Hub and VNet-Spoke2 with 'Allow gateway transit' enabled on VNet-Hub and 'Use remote gateways' enabled on VNet-Spoke2. 'Allow forwarded traffic' is enabled on all peering connections. No User-Defined Routes (UDRs) or Network Virtual Appliances (NVAs) are deployed.

To enable VM-Spoke1 to communicate with VM-Spoke2, no additional peering connections or routing resources are required because the existing gateway transit configurations automatically route traffic between the spokes through the hub.

Answer: Answer

Answer

False

The statement is false because virtual network peering in Azure is strictly non-transitive. Enabling 'Allow gateway transit' on the hub and 'Use remote gateways' on the spokes allows the spokes to use the hub's VPN gateway to communicate with on-premises networks, but it does not enable routing between the spokes. For VM-Spoke1 to communicate with VM-Spoke2, you must configure either direct peering between the spokes, or route the traffic through a network virtual appliance (NVA) or Azure Firewall in the hub using User-Defined Routes.

Step-by-Step Solution

Analyze the virtual network peering topology and configuration settings.

Two spokes (VNet-Spoke1 and VNet-Spoke2) are peered with a central hub (VNet-Hub). Gateway transit is enabled for both connections.

Understanding the layout is necessary to determine routing behavior.

Evaluate the transitivity of virtual network peering in Azure.

Virtual network peering is non-transitive. Traffic from VNet-Spoke1 cannot transit through VNet-Hub to reach VNet-Spoke2 by default.

To verify if direct spoke-to-spoke connectivity exists via the hub without additional routing configuration.

Determine the effect of 'Allow gateway transit' and 'Use remote gateways' configurations.

These configurations only permit spoke virtual networks to share the hub's VPN or ExpressRoute gateway to access on-premises networks. They do not establish spoke-to-spoke routing.

To assess if the gateway transit settings facilitate the required spoke-to-spoke data plane connectivity.

Conclude the required configuration to enable communication between VM-Spoke1 and VM-Spoke2.

Either a direct peering must be configured between the spokes, or an NVA/Azure Firewall must be deployed in the hub VNet with User-Defined Routes (UDRs) on the spokes to forward traffic.

To verify that additional resources/configurations are indeed required, making the original statement false.

Key Concept

Azure Virtual Network Peering is non-transitive, and gateway transit only applies to VPN/ExpressRoute gateways, not spoke-to-spoke routing.

Estimated Time:2m 0s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic