AZ-305 Question 223
Single answerYour organization hosts a front-end web application in one Azure Virtual Network (VNet) and a back-end database in another VNet. You also have an on-premises network connected to Azure via a site-to-site VPN gateway attached to the front-end VNet. You need to allow the front-end to communicate with the back-end and also access on-premises resources, while ensuring minimal latency and private traffic flow. Which approach should you design?
- A
Create a VNet peering between the front-end and back-end VNets, and enable 'Use remote gateways' on the back-end VNet.
- B
Create a VNet peering between the front-end and back-end VNets, and enable 'Use remote gateways' on the front-end VNet.
- C
Use two separate ExpressRoute connections, each directly tied to one of the VNets, with no VNet peering.
- D
Configure forced tunneling on both VNets, ensuring that all traffic is routed back through the on-premises network.
Show answer and explanation
Correct answer: B
Explanation
For secure, low-latency communication between VNets and on-premises, Azure Virtual Network Peering with gateway transit is recommended. When you enable 'Use remote gateways' on the VNet that does not have the VPN gateway (the back-end in this scenario), traffic from the back-end can route to the on-premises network via the front-end VNet gateway. This is outlined in Microsoft Azure documentation under 'VNet peering - Gateway transit' (https://docs.microsoft.com/azure/virtual-network/tutorial-cross-region-vnet-peering).
- A. Incorrect.
Incorrect: Enabling 'Use remote gateways' on the back-end VNet doesn't allow the front-end VNet to utilize its own VPN gateway for on-premises connectivity. The back-end would not be able to send traffic to the on-premises network via the front-end's gateway unless the front-end VNet is configured to advertise its gateway to the back-end.
- B. Correct.
Correct: Peering the front-end and back-end VNets and enabling 'Use remote gateways' on the front-end VNet allows the back-end to use the front-end's VPN gateway for on-premises connectivity. The front-end already has the VPN gateway attached, and this configuration ensures minimal latency for VNet-to-VNet traffic while keeping it private.
- C. Incorrect.
Incorrect: Using two separate ExpressRoute connections would be complex and costly, and is not the intended solution for this scenario. You only have a site-to-site VPN gateway attached to the front-end VNet, and there's no mention of needing a separate connection for the back-end VNet.
- D. Incorrect.
Incorrect: Forced tunneling directs internet traffic back to on-premises, which can introduce unnecessary complexity and latency. This does not optimize VNet-to-VNet communication and is contrary to best practices unless you specifically need to force internet-bound traffic through on-premises inspection.