Exam AZ-801 topic 1 question 22 discussion

Perhaps A is correct https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-point-to-site-routing

C is just plain wrong D is also out as Virtual Network (VNet) service endpoint provides secure and direct connectivity to Azure services https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-point-to-site-routing If you make a change to the topology of your network and have Windows VPN clients, the VPN client package for Windows clients must be downloaded and installed again in order for the changes to be applied to the client Meaning A is wrong leaving B as the answer

A. On Computer1, download and reinstall the VPN client.

correct ans is B. Create a route table and associate the table with GatewaySubnet on VNet1.

"If you make a change to the topology of your network and have Windows VPN clients, the VPN client package for Windows clients must be downloaded and installed again in order for the changes to be applied to the client." From the link provided by Nefaxto. ;)

To decide on the correct answer, let's take a closer look at the options: - Option A (Download and reinstall VPN client on computer 1): This option doesn't seem relevant to solving the access problem between AppSvr1 and AppSvr2. - Option B (Create a routing table and associate it with GatewaySubnet on virtual network 1): This is the most appropriate option. It configures the routes required for traffic to pass between the peered virtual networks (VNet1 and VNet2). In this way, User1 will be able to access AppSvr2 from AppSvr1. - Option C (Modify Windows Defender firewall settings on Computer1): Although firewall security is important, this will not directly solve the access problem between the two virtual machines. - Option D (Add a service endpoint to virtual network 2): This option doesn't seem necessary to solve the access problem between AppSvr1 and AppSvr2. Taking this information into account, I confirm that Option B is the correct answer.

Answer is A

Answer is A.

Multiple peered VNets In this example, the Point-to-Site VPN gateway connection is for VNet1. VNet1 is peered with VNet2. VNet 2 is peered with VNet3. VNet1 is peered with VNet4. There is no direct peering between VNet1 and VNet3. VNet1 has “Allow gateway transit” and VNet2 and VNet4 have “Use remote gateways” enabled. Clients using Windows can access directly peered VNets, but the VPN client must be downloaded again if any changes are made to VNet peering or the network topology. Non-Windows clients can access directly peered VNets. Access isn't transitive and is limited to only directly peered VNets.

B is correct B. Create a route table and associate the table with GatewaySubnet on VNet1. Reason below: 1- User1 is already able to establish a Point-to-Site (P2S) connection to GW1 to access AppSvr1. This indicates that the VPN client on Computer1 is configured correctly for the existing P2S connection. 2- The problem is that User1 cannot access AppSvr2, which is located in Vnet2 and not directly connected to the P2S connection. To enable User1 to access resources in Vnet2, you need to ensure that the traffic from the P2S connection is correctly routed to Vnet2. 3- Creating a route table and associating it with the GatewaySubnet on VNet1 allows you to define custom routes for the VPN traffic. You can configure the route table to route traffic destined for Vnet2 through the peering connection between Vnet1 and Vnet2.

A, these topics were covered in more detail in AZ-104

You're correct that VNet peering does indeed establish a link and routing between the two virtual networks (VNet1 and VNet2). However, by default, a Point-to-Site (P2S) VPN client (User1 in this case) connected to VNet1 can only access resources within VNet1. While VNet peering allows for resources in VNet1 and VNet2 to communicate directly, this doesn't automatically mean a P2S VPN client connected to VNet1 can access resources in VNet2. This capability has to be explicitly configured.

B. Create a route table and associate the table with GatewaySubnet on VNet1. Since User1 can establish a P2S connection to GW1, User1 can access resources in VNet1. However, User1 cannot access resources in VNet2 because there is no route between the two VNets. To enable access to AppSvr2, you need to create a route table and associate the table with GatewaySubnet on VNet1. The route table should contain a user-defined route that has a destination prefix of the address space of VNet2 (10.2.0.0/16 in this case) and the next hop type Virtual appliance. The next hop address should be the IP address of the virtual network gateway on VNet1. This route table will enable User1 to access AppSvr2 over the P2S connection to GW1.

not B because Azure creates the route table. You can add to a route table but not create your own.

Re-install the P2S client.

https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview For peered virtual networks, resources in either virtual network can directly connect with resources in the peered virtual network. The traffic between virtual machines in peered virtual networks is routed directly through the Microsoft backbone infrastructure, not through a gateway or over the public Internet. Full connectivity is the default option. So, just reinstall the client.

Same as thefscale, if the 2 VNETs are peered, recreating the connection should provide connectivity to both.