Technical Lab: Create a Backend Pool
Questions
Question 1 — Multiple Choice
You are configuring an Azure Application Gateway and need to add members to the backend pool. When reviewing the available options, you notice that the portal offers different types of targets.
Which of the options below is not a valid target type when creating a backend pool in Application Gateway?
A) IP address or FQDN
B) Virtual machine (associated NIC)
C) Availability Set as a direct entity
D) App Service
Question 2 — Technical Scenario
A team configured an Azure Load Balancer (Standard SKU, internal) with a backend pool associated to a virtual machine NIC. After deployment, connectivity tests fail. Upon investigation, the team discovers that the VM is in a different VNet from the Load Balancer's VNet, but both are connected via VNet Peering.
Load Balancer (Standard, Internal)
Frontend IP: 10.1.0.10 (VNet-A, Subnet-LB)
Backend Pool: VM-01 NIC
VM-01
IP: 10.2.0.5 (VNet-B, Subnet-VMs)
VNet Peering: VNet-A <-> VNet-B (active)
What is the most likely cause of the failure?
A) Standard SKU does not support backend pools with VMs in distinct VNets, even with peering
B) NIC-based backend pool requires the NIC to be in the same VNet as the Load Balancer
C) VNet Peering does not propagate sufficient routes for the Load Balancer to reach the VM
D) Internal Load Balancer does not support backend pools with private IP addresses from another VNet
Question 3 — True or False
An Azure Load Balancer with Standard SKU allows adding resources to the backend pool using the IP address as target, which enables including on-premises machines accessible via ExpressRoute or VPN, without requiring them to have a NIC registered in Azure.
True or False?
Question 4 — Technical Scenario
A team is migrating an application to Azure Application Gateway and needs the backend pool to point to a set of instances from an Azure App Service. The responsible engineer configures the pool using the public IP addresses of the App Service instances, but after a few days the health probes start failing intermittently.
What best explains this behavior and what would be the correct approach?
A) App Services are not supported as backend pool members in Application Gateway; an intermediate VM should be used
B) App Service IP addresses can change since the platform is managed; the correct approach is to use the App Service FQDN as the backend pool target
C) Application Gateway requires the App Service to be in the same region; the issue is geographical
D) Health probe fails because App Service requires mutual TLS authentication, which Application Gateway does not support
Question 5 — Multiple Choice
When creating a backend pool in Azure Load Balancer Standard SKU using the IP address configuration mode, which statement correctly describes a limitation or expected behavior of this approach?
A) Only IPv6 addresses are accepted in IP address configuration mode
B) Resources added by IP do not need to be in the same VNet, but must have network connectivity with the Load Balancer frontend
C) IP address mode is exclusive to Basic SKU Load Balancer and is not available in Standard
D) When using IP address, Load Balancer automatically associates a virtual NIC to the target resource for monitoring
Answer Key and Explanations
Answer Key — Question 1
Answer: C
Application Gateway accepts as backend pool members: IP addresses or FQDNs, VM NICs, virtual machine scale sets (VMSS), and App Services. An Availability Set is not a directly addressable entity as a backend target, as it is a logical grouping construct for VMs, not a network endpoint. VMs within the Availability Set need to be added individually via NIC or IP. The conceptual error in the distractors is confusing logical grouping entities with addressable network resources.
Answer Key — Question 2
Answer: B
When Azure Load Balancer Standard's backend pool is configured in NIC mode, associated resources need to be in the same VNet as the Load Balancer. VNet Peering does not bypass this requirement for the NIC-based association model. The correct alternative to include VMs in different VNets would be to use IP address configuration mode, which accepts targets outside the local VNet, provided there is network connectivity. The common error is assuming that active peering is sufficient for any backend association mode.
Answer Key — Question 3
Answer: True
Azure Load Balancer Standard SKU introduced the IP address-based backend pool, which eliminates the requirement for the target resource to have a NIC registered in Azure. This allows including physical servers or on-premises VMs accessible via ExpressRoute or VPN Gateway as backend pool members. This behavior is a relevant difference from Basic SKU, which requires Azure NICs, and is often underestimated by those who associate Load Balancer exclusively with Azure-native IaaS resources.
Answer Key — Question 4
Answer: B
Azure App Service operates on platform-managed infrastructure, and the underlying IP addresses of instances can change during scaling events, redeployment, or maintenance. The correct approach is to configure the backend pool using the App Service FQDN (e.g., myapp.azurewebsites.net), as Application Gateway resolves the name at runtime. Application Gateway offers native support for App Service as a backend target, including simplified integration in the portal. Using fixed IP on a managed service is an architectural error that violates the expected platform operation model.
Answer Key — Question 5
Answer: B
In the IP address configuration mode of Load Balancer Standard, targets do not need to have NICs registered in Azure or be in the same VNet, but they need to be reachable by the network infrastructure, whether through peering, VPN, or ExpressRoute. The other alternatives contain factual errors: IP mode accepts IPv4 and IPv6; it is available in Standard SKU, not Basic; and Load Balancer does not automatically create virtual NICs for IP targets. The central point is understanding that the flexibility of IP mode comes with the explicit responsibility of ensuring end-to-end network connectivity.