Implement and manage virtual networking for Microsoft Azure Administrator (AZ-104)

Sample Practice Questions

1. Question 1

   Note: The question is included in a number of questions that depicts the identical set-up. However, every question has a distinctive result. Establish if the solution satisfies the requirements. Your company's Azure subscription includes two Azure networks named VirtualNetworkA and VirtualNetworkB . VirtualNetworkA includes a VPN gateway that is configured to make use of static routing. Also, a site-to-site VPN connection exists between your company's on- premises network and VirtualNetworkA . You have configured a point-to-site VPN connection to VirtualNetworkA from a workstation running Windows 10. After configuring virtual network peering between VirtualNetworkA and VirtualNetworkB , you confirm that you are able to access VirtualNetworkB from the company's on-premises network. However, you find that you cannot establish a connection to VirtualNetworkB from the Windows 10 workstation. You have to make sure that a connection to VirtualNetworkB can be established from the Windows 10 workstation. Solution: You choose the Allow gateway transit setting on VirtualNetworkA . Does the solution meet the goal?
   1. A. Yes
   2. B. No
   Explanation

   The correct answer is: B. No.

   The answer is No because Allow gateway transit on VirtualNetworkA alone does not resolve the missing-route problem on the point-to-site client. Gateway transit lets a peered VNet make use of the gateway in another VNet, and pairing it with Use remote gateway on the spoke is part of the supported design for letting on-prem reach the peered network, but it does not by itself update the routing table on the Windows 10 P2S client. After topology changes such as adding a peering, the VPN client configuration package has to be downloaded and reinstalled on the workstation so the new VNet's prefix is added to the client's routes; until that happens the workstation has no system route for the new VNet and packets never enter the tunnel. The complete fix is gateway transit on the gateway side, Use remote gateway on the spoke peering, and re-deploying the P2S client package.

2. Question 2

   Note: The question is included in a number of questions that depicts the identical set-up. However, every question has a distinctive result. Establish if the solution satisfies the requirements. Your company's Azure subscription includes two Azure networks named VirtualNetworkA and VirtualNetworkB. VirtualNetworkA includes a VPN gateway that is configured to make use of static routing. Also, a site-to-site VPN connection exists between your company's on- premises network and VirtualNetworkA. You have configured a point-to-site VPN connection to VirtualNetworkA from a workstation running Windows 10. After configuring virtual network peering betweenVirtualNetworkA and VirtualNetworkB, you confirm that you are able to access VirtualNetworkB from the company's on-premises network. However, you find that you cannot establish a connection to VirtualNetworkB from the Windows 10 workstation. You have to make sure that a connection to VirtualNetworkB can be established from the Windows 10 workstation. Solution: You choose the Allow gateway transit setting on VirtualNetworkB. Does the solution meet the goal?
   1. A. Yes
   2. B. No
   Explanation

   The correct answer is: B. No.

   Setting Allow gateway transit on VirtualNetworkB does not solve the problem, so the answer is No: gateway transit is configured on the side that owns the gateway, not on the network that wants to consume it, and even then it only changes whether peered networks may use the gateway for cross-premises traffic. The actual reason point-to-site clients cannot reach the peered VNet is that the VPN client package the workstation installed was generated before the peering existed, so its routing table does not include the address range of VirtualNetworkB. The fix is to regenerate and reinstall the VPN client configuration on the Windows 10 workstation so the new routes are pushed into the client, and on the VNet side to enable Use Remote Gateway on the spoke peering while gateway transit is allowed on the gateway-side peering. Toggling a flag on VirtualNetworkB by itself does not update any client state and does not address the missing routes.

3. Question 3

   Note: The question is included in a number of questions that depicts the identical set-up. However, every question has a distinctive result. Establish if the solution satisfies the requirements. Your company's Azure subscription includes two Azure networks named VirtualNetworkA and VirtualNetworkB. VirtualNetworkA includes a VPN gateway that is configured to make use of static routing. Also, a site-to-site VPN connection exists between your company's on- premises network and VirtualNetworkA. You have configured a point-to-site VPN connection to VirtualNetworkA from a workstation running Windows 10. After configuring virtual network peering between VirtualNetworkA and VirtualNetworkB, you confirm that you are able to access VirtualNetworkB from the company's on-premises network. However, you find that you cannot establish a connection to VirtualNetworkB from the Windows 10 workstation. You have to make sure that a connection to VirtualNetworkB can be established from the Windows 10 workstation. Solution: You download and re-install the VPN client configuration package on the Windows 10 workstation. Does the solution meet the goal?
   1. A. Yes
   2. B. No
   Explanation

   The correct answer is: A. Yes.

   The solution meets the goal because the P2S VPN client configuration package is generated at the moment of download and embeds the gateway's current view of the routes it should push to the client. When VirtualNetworkA and VirtualNetworkB are peered, the P2S route table the gateway uses must be regenerated to include VirtualNetworkB's address range, and the only way an existing client picks up that change is to re-download and re-install the VPN client configuration. Until the workstation receives the new routes, it has no entry sending VirtualNetworkB traffic into the VPN tunnel, even though VirtualNetworkA's peering already gives it backbone connectivity to VirtualNetworkB. Re-installing the package refreshes those client-side routes, after which the Windows 10 workstation can reach VirtualNetworkB through the same P2S tunnel.

4. Question 4

   Your company has virtual machines (VMs) hosted in Microsoft Azure. The VMs are located in a single Azure virtual network named VNet1 . The company has users that work remotely. The remote workers require access to the VMs on VNet1 . You need to provide access for the remote workers. What should you do?
   1. A. Configure a Site-to-Site (S2S) VPN.
   2. B. Configure a VNet-toVNet VPN.
   3. C. Configure a Point-to-Site (P2S) VPN.
   4. D. Configure DirectAccess on a Windows Server 2012 server VM.
   5. E. Configure a Multi-Site VPN
   Explanation

   The correct answer is: C. Configure a Point-to-Site (P2S) VPN..

   A Point-to-Site VPN is the right pattern when individual remote users need ad-hoc access to a VNet from anywhere on the internet, because the gateway terminates per-user tunnels using OpenVPN or IKEv2 and authenticates with certificates or Microsoft Entra ID. Site-to-Site VPN connects an entire on-premises network through an on-prem VPN device and a public IP, which is wrong for users who roam from random networks. VNet-to-VNet VPN links two Azure VNets together and does not give remote workers a way in. DirectAccess on Windows Server 2012 is a legacy on-premises remote-access technology that is deprecated and not how you connect to an Azure VNet. Multi-Site VPN is a variant of S2S that aggregates several on-prem sites to one gateway, again not a remote-user solution. P2S is purpose-built for individual remote endpoints and integrates with Entra ID for modern authentication.

5. Question 5

   Note: The question is included in a number of questions that depicts the identical set-up. However, every question has a distinctive result. Establish if the solution satisfies the requirements. Your company has a Microsoft SQL Server Always On availability group configured on their Azure virtual machines (VMs). You need to configure an Azure internal load balancer as a listener for the availability group. Solution: You create an HTTP health probe on port 1433. Does the solution meet the goal?
   1. A. Yes
   2. B. No
   Explanation

   The correct answer is: B. No.

   The solution does not meet the goal because Azure load balancer health probes for an internal load balancer fronting a SQL AlwaysOn availability-group listener must use TCP on the SQL Server port (1433 by default) rather than HTTP. SQL Server does not expose an HTTP endpoint that responds with a 200 OK to a probe; an HTTP probe on 1433 would fail every check and the backend would be marked unhealthy. A TCP probe simply opens a socket and treats a successful handshake as healthy, which matches how SQL Server actually listens. Floating IP must also be enabled on the load-balancing rule so the backend can answer using the listener's frontend IP, which is the standard AlwaysOn pattern. The probe choice in the proposed solution is therefore wrong; only a TCP probe on the SQL port satisfies the listener requirement, so the answer is no.

Other Microsoft Azure Administrator (AZ-104) domains

• Deploy and manage Azure compute resources (123 questions)
• Implement and manage storage (105 questions)
• Manage Azure identities and governance (127 questions)
• Monitor and maintain Azure resources (94 questions)