Examkin

Question

Difficulty: EasyConfigure Virtual Network Peering

An administrator configures two virtual network peerings: one between VNet-Core and VNet-App1, and another between VNet-Core and VNet-App2. Virtual machines are deployed in subnets across all three virtual networks. The administrator enables 'Allow forwarded traffic' on both peerings, but does not configure 'Use remote gateways' or 'Allow gateway transit'. Which of the following describes the default connectivity between VNet-App1 and VNet-App2?

  1. Virtual machines in VNet-App1 cannot communicate with virtual machines in VNet-App2 because virtual network peering is non-transitive.Answer
  2. B
    Virtual machines in VNet-App1 can communicate with virtual machines in VNet-App2 because 'Allow forwarded traffic' is enabled.
  3. C
    Virtual machines in VNet-App1 can communicate with virtual machines in VNet-App2 because peering automatically routes traffic transitively through VNet-Core.
  4. D
    Virtual machines in VNet-App1 can communicate with virtual machines in VNet-App2 only if 'Use remote gateways' is enabled on both peerings.

Answer

Virtual machines in VNet-App1 cannot communicate with virtual machines in VNet-App2 because virtual network peering is non-transitive.
Virtual network peering in Azure is non-transitive. This means that if VNet-App1 is peered with VNet-Core, and VNet-App2 is peered with VNet-Core, there is no automatic path for traffic to travel from VNet-App1 to VNet-App2 through VNet-Core. Enabling 'Allow forwarded traffic' only allows virtual machines in the peered network to receive traffic that did not originate from the peered network itself (such as from a virtual appliance), but it does not enable transitive routing between the two spokes.

Step-by-Step Solution

1
Analyze the topology and peering configuration.
We have VNet-App1 peered to VNet-Core, and VNet-App2 peered to VNet-Core. The two spokes (VNet-App1 and VNet-App2) are not directly peered with each other.
Understanding the direct peering relationships determines which paths are configured.
2
Evaluate the transit capabilities of standard VNet peering.
VNet peering is non-transitive. Traffic originating in VNet-App1 cannot transit through VNet-Core to reach VNet-App2 by default.
This is a fundamental behavior of Azure Virtual Network peering.
3
Determine the impact of the configured peering settings ('Allow forwarded traffic', 'Use remote gateways', 'Allow gateway transit').
Enabling 'Allow forwarded traffic' permits forwarding of traffic from network virtual appliances, but does not provide transit routing. 'Use remote gateways' and 'Allow gateway transit' are gateway-related settings and do not enable spoke-to-spoke routing without a gateway present.
Verifying configuration properties ensures that no special transit bypasses are active.

Key Concept

Azure Virtual Network Peering is non-transitive by default, meaning that spoke-to-spoke communication through a hub requires a router or virtual network gateway.
Rate this question

Topics

Configure Virtual Network Peering

More questions from this topic