Sorry answer is AD too bad I cannot edit the previous post.

Correct answer is AD. A: Vnet2 where the NVA is placed need to be allowed to forward traffic from Vnet1 to Vnet3 and vica versa B: User Defined Route (UDR) must be created on each Subnet in Vnet1 and Vnet3 to override system (default) routes and send traffic between these Vnet's via the NVA

- A. On the peering connections, allow forwarded traffic - D. Create route tables and assign the table to subnets

I think the options C and E are correct. Since, the VNet 1 can't communicate directly with the VNet3 and similarly the VNet3 can't communicate with the VNet1 directly, they have to communicate via VNet2 (HUB and Spoke model), therefore Gateway Transit must be implemented on VNet2 and on VNet1 and VNet3 we need to use Remote Gateways. According to my understanding the options A and D is wrong because we enable the forwarding traffic in case of DNS. Similarly, we use user defined routes using Route Table in case of DNS. For example, If the VNet2 was configured as DNS Server then in that case we will implement forwarding traffic and define custom routes on VNet2. https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-point-to-site-routing#multis2sbgp

yes A and D is correct

wrong answer... for azure hub and spoke a virtual appliance (not VPN gateway is needed). I think it should be AD

A, D is correct Exact working in MS documentation. See under "Allow forwarded traffic" Section Ref Link: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-manage-peering

The correct answer should be: A&D

A+D or A+C+D both works, however, A+D is the best performance and less impact; so best answer is A+D

You can also configure spokes to use the hub gateway to communicate with remote networks. To allow gateway traffic to flow from spoke to hub, and connect to remote networks, you must: Configure the peering connection in the hub to allow gateway transit. Configure the peering connection in each spoke to use remote gateways. Configure all peering connections to allow forwarded traffic.

A&D is correct same as Question61

The answer is INCORRECT!! It dismisses a key piece of information, which is that we will implement a hub and spoke topology (references the documentation on Peerings). The documentation to check is https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke#recommendations . At the beginning of the article, you can see the architecture diagram clearly uses the Gateway to connect to an On-premises infra. This makes option C INCORRECT! The same applies to option E. On- premises infra is not even mentioned. Checking the referenced documentation you can clearly see that “If you require connectivity between spokes, consider deploying Azure Firewall or an NVA for routing in the hub, and using UDRs in the spoke to forward traffic to the hub.” There you have the 2 keywords: routing (UDR stands for User Defined Rout) and forwarding.

A&D is correct answer

the correct answer should be A & D

A and D

A & D are the correct answers Please refer "Spoke connectivity" part from the below article. https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke If you require connectivity between spokes, consider deploying Azure Firewall or an NVA for routing in the hub, and using UDRs in the spoke to forward traffic to the hub. The deployment steps below include an optional step that sets up this configuration. In this scenario, you must configure the peering connections to allow forwarded traffic. You can also use a VPN gateway to route traffic between spokes, although this will have impacts in terms of latency and throughput. Also, Azure Firewall or a network firewall appliance provides an additional layer of security.

A. On the peering connections, allow forwarded traffic D. Create route tables and assign the table to subnets