Q: 16
You have an Azure subscription named Subscription1 that contains two Azure virtual
networks named VNet1 and VNet2. VNet1 contains a VPN gateway named VPNGW1 that
uses static routing. There is a site-to-site VPN connection between your on-premises
network and VNet1. On a computer named Client1 that runs Windows 10, you configure a
point-to-site VPN connection to VNet1. You configure virtual network peering between
VNet1 and VNet2. You verify that you can connect to VNet2 from the on-premises network.
Client1 is unable to connect to VNet2. You need to ensure that you can connect Client1 to
VNet2. What should you do?
Options
Discussion
Option C makes sense here. When you add new peering after setting up the P2S VPN, Client1 won't get routes to VNet2 unless you re-download the client package. A looks tempting but is more about gateway transit, not local routes. I think C fits best but open to feedback.
C tbh. Whenever you change peering or VNets, the P2S client config needs to be updated so Client1 gets the new routes. No need for BGP in this scenario. Someone correct me if I'm wrong.
Not sure it's C. I'd actually go with A because peering needs to allow traffic via the remote gateway, otherwise routes won't propagate. C looks like a trap for folks used to simple config changes.
C or D? Had something like this in a mock and went with D for enabling BGP, seemed logical at the time.
Be respectful. No spam.
