4 of the 9 questions we have for this objective, shown with the answer and the reasoning.
Design network solutions
Hartwell Games hosts a multiplayer game server on six virtual machines in a single Azure region. Game clients connect over UDP on port 7777. Traffic must be distributed across the VMs within the region, unhealthy VMs must be removed from rotation using a health probe, the VMs must be spread across availability zones, and the solution must provide low-latency, high-throughput forwarding without inspecting packet contents.
Which load-balancing solution should you recommend?
- AAzure Application Gateway v2 with a UDP listenerApplication Gateway is a layer 7 HTTP and HTTPS load balancer and does not forward UDP traffic.
- BAzure Load Balancer Standard with a zone-redundant frontend and a UDP load-balancing ruleStandard Load Balancer is the regional layer 4 balancer that supports TCP and UDP rules, health probes, and zone-redundant frontends, forwarding packets at very high throughput and low latency.
- CAzure Front Door Standard with a UDP origin groupFront Door is a global HTTP and HTTPS entry point; it has no support for UDP game traffic.
- DAzure Traffic Manager with the Weighted routing methodTraffic Manager is DNS-based and distributes clients across endpoints at resolution time, which is designed for multi-region routing and does not balance packets across VMs inside one region.
Why: Regional and non-HTTP is the combination that selects Azure Load Balancer. The Standard SKU adds the required availability-zone redundancy and health probes and supports UDP rules, which eliminates the HTTP-only services. Traffic Manager is the trap for people who equate global with any DNS-level distribution; it operates on DNS answers rather than on packets and cannot balance connections among VMs in a single region.
Design network solutions
Tideline Retail has 60 stores, each with an SD-WAN appliance and a commodity internet connection, plus a head office with an ExpressRoute circuit. All sites must reach workloads in three Azure regions, and stores must be able to reach each other through Azure. Networking staff want Microsoft to manage the hub routing, want any-to-any connectivity configured automatically, and want to avoid hand-building hubs and route tables in each region.
Which connectivity solution should you recommend?
- AA customer-managed hub-and-spoke virtual network in each region with a VPN gateway and user-defined routesBuilding and maintaining three hubs, their gateways, peerings, and route tables is the hand-crafted approach the staff want to avoid, and store-to-store transit requires additional configuration.
- BAzure Virtual WAN (Standard) with a virtual hub in each region, site-to-site VPN for the stores, and the ExpressRoute circuit connected to one hubStandard Virtual WAN provides Microsoft-managed hubs with automatic any-to-any routing between VPN sites, ExpressRoute, and virtual networks across regions, including branch-to-branch transit.
- CAzure Virtual WAN (Basic) with site-to-site VPN for all sitesBasic Virtual WAN supports site-to-site VPN only; it has no ExpressRoute support, no inter-hub connectivity, and no branch-to-branch transit through multiple regions.
- DPoint-to-site VPN from each store appliance to a VPN gateway in a single regionPoint-to-site is intended for individual clients, not branch appliances, and a single-region gateway does not provide managed multi-region routing.
Why: Virtual WAN is the managed global transit network. When the requirements include many branches, multiple regions, mixed VPN and ExpressRoute, and automatic any-to-any routing including branch-to-branch, Standard Virtual WAN is the intended answer; Basic is limited to VPN-only and single-hub scenarios. A customer-managed hub-and-spoke is the valid alternative when you want full control and have few sites, which is the opposite of this scenario.
Design network solutions
Ravelstone Engineering has a hub virtual network connected to on-premises by ExpressRoute and 12 spoke virtual networks, one per application. Security requires that all traffic between spokes and all traffic from spokes to the internet pass through a central inspection point in the hub, that spokes cannot communicate directly with each other, and that application teams can still deploy resources in their own spokes without touching the hub.
Which two design elements should you recommend? Each correct answer presents part of the solution.
- ADeploy Azure Firewall in the hub and associate a route table with each spoke subnet whose default route (0.0.0.0/0) points to the firewall's private IP addressA user-defined default route to the firewall forces internet-bound and spoke-to-spoke traffic through the central inspection point, because spokes are not peered to each other and must transit the hub.
- BPeer each spoke only to the hub, and do not peer spokes to one anotherPeering is non-transitive, so hub-only peering prevents direct spoke-to-spoke communication and makes the hub the only path between spokes.
- CPeer every spoke to every other spoke with a full mesh of virtual network peeringsA full mesh lets spokes communicate directly and bypass the hub inspection point, which the security requirement forbids.
- DDeploy a network security group on each spoke subnet that denies all outbound internet trafficAn NSG deny rule blocks the traffic entirely rather than steering it to the firewall, and NSGs cannot inspect or forward traffic.
- EEnable ExpressRoute FastPath on the hub gateway connectionFastPath optimizes on-premises to VM throughput by bypassing the gateway; it does not force spoke traffic through a firewall.
Why: A secured hub-and-spoke topology relies on two facts: virtual network peering is not transitive, and user-defined routes override system routes. Peering each spoke only to the hub guarantees that spokes have no direct path to each other, and a default route to the Azure Firewall private IP makes the firewall the next hop for both internet-bound and inter-spoke traffic. Teams keep autonomy inside their spokes because the inspection lives in the hub. The distractors either reintroduce a bypass with a mesh or block traffic instead of inspecting it.
Design network solutions
Juniper Streaming serves a web application from App Service instances in East US, West Europe, and Southeast Asia. Users worldwide must be routed to the closest healthy region with automatic failover, TLS must terminate at the edge, requests must be routed by URL path to different backends, static assets must be cached close to users, and a web application firewall with bot protection and Private Link to the origins is required.
Which load-balancing solution should you recommend?
- AAzure Traffic Manager with the Performance routing methodTraffic Manager is DNS-based and global, but it does not terminate TLS, route by path, cache content, or host a WAF.
- BAzure Application Gateway v2 with WAF in each region, behind Traffic ManagerApplication Gateway is a regional layer 7 balancer; combining three of them with DNS routing adds cost and operational effort and still lacks edge caching and anycast failover.
- CAzure Front Door Premium with WAF and Private Link originsFront Door is the global layer 7 entry point with anycast routing to the closest healthy origin, TLS termination, path-based routing, edge caching, and the Premium tier adds managed WAF rule sets with bot protection and Private Link to origins.
- DAzure Load Balancer Standard with cross-region load balancingLoad Balancer operates at layer 4 and cannot terminate TLS, inspect URLs, cache, or apply a WAF.
Why: Load-balancing selection on AZ-305 starts with two questions: global or regional, and HTTP (layer 7) or non-HTTP (layer 4). Global plus HTTP points to Azure Front Door, and the WAF bot protection and Private Link origin requirements specifically select the Premium tier. Traffic Manager is the global DNS-based option for non-HTTP traffic, Application Gateway is the regional layer 7 option, and Load Balancer is the regional layer 4 option, which is why each distractor misses at least one requirement.