HOTSPOT -
You have the hybrid network shown in the Network Diagram exhibit.
You have a peering connection between Vnet1 and Vnet2 as shown in the Peering-Vnet1-Vnet2 exhibit.
You have a peering connection between Vnet1 and Vnet3 as shown in the Peering-Vnet1-Vnet3 exhibit.
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
NOTE: Each correct selection is worth one point.
Hot Area:
Box 1: Yes -
Virtual network peering seamlessly connects two Azure virtual networks, merging the two virtual networks into one for connectivity purposes.
Box 2: No -
No Virtual Gateway is used.
Gateway transit is a peering property that lets one virtual network use the VPN gateway in the peered virtual network for cross-premises or VNet-to-VNet connectivity. The following diagram shows how gateway transit works with virtual network peering.
In the diagram, gateway transit allows the peered virtual networks to use the Azure VPN gateway in Hub-RM. Connectivity available on the VPN gateway, including S2S, P2S, and VNet-to-VNet connections, applies to all three virtual networks.
Box 3: No -
No Virtual Gateway is used.
Reference:
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-peering-gateway-transit
Correct answer Y,N,N. Remember Azure VNET Peering is NON-Transitive. Meaning, only direct peered VNETs can talk to each other. To make it transitive you either use VNET Gateway or NVAs/Azure FireWall.
correct, vnet1 cannot be a trnsit between vnets2 and 3, without using the gateway as transit
Incorrect. Vnet2 can communicate to Vnet3 because the communication is via AZURE backbone not via Gateway, gateway is only required if Vnet2 wants to communicate to On-prem. My take YYN As per this MSDOC https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview
This is not correct No transitivity be default between spokes vnets
Correct
I don't get it, why can't VNET1 communcate with on-prem when there is a site-to-site VPN present?
I read the question wrong, my bad!
Answer is tricky. Y/N/N is correct, because it's not mentioned the usage of NVA or VNG. If it mentioned NVA, or use of VNG, then it would be Y/Y/Y
Answer is correct. Y N N
yes,no,no
Answer is correct, The option: Use the remote virtual network's gateway" is not enabled
YYN amt2022. Unfortunately your are incorrect. VNet peering is non-transitive by default. This default behaviour can be altered by selecting the appropriate option 'allow forwarded traffic from the peered vnet'. This would allow 'vnet-3' to receive forwarded traffic from 'vnet-1' (i.e. traffic that is sent from vnet2 is forwarded from vnet1 to vnet2. So the correct option in box 2 is YES. Therefore the answer to the question is YYN. Vnet1 does not allow gateway transit, so vnet3 cannot communicate with the on-prem network.
This is not correct. If you actually bother to create a virtual network and check the description that is shown for this option. It reads: Enabling this option will allow the peered virtual network to receive traffic from virtual networks peered to 'test'. For example, if vnet-2 has an NVA that receives traffic from outside of vnet-2 that gets forwards to vnet-1, you can select this setting to allow that traffic to reach vnet-1 from vnet-2. While enabling this capability allows the forwarded traffic through the peering, it doesn't create any user-defined routes or network virtual appliances. User-defined routes and network virtual appliances are created separately. Meaning that only selecting this option won't enable the peering between VNET 2 & VNET 3
The options have all changed on the actual Azure Portal UI now. It's much clearer and self-explanatory now in fact !
The last one should be yes: It is stated that there is a Site-to-Site VPN which implies that there is virtual network gateway.
I am wrong, I think it that old screenshot, the option "remote gateway or route server" should be enabled
correct vnet1 not use its gateway for vnet2
Doesn't the 2nd Link name on both those peerings are wrong matter?