During a fare-sale spike, Cascade Regional Airlines notices that shopping-cart state built up on one backend web server is being lost mid-checkout because a customer's follow-up requests keep landing on a different VM behind the Standard Load Balancer. Which load balancer setting should route all of that customer's requests back to the same backend instance for the duration of the session?

Azure Load Balancer's distribution mode controls how it maps incoming flows to backend instances, and setting it to source IP affinity (also called client IP affinity, using a 2-tuple or 3-tuple hash) makes the load balancer consistently send traffic from the same client IP to the same backend VM, which keeps session-bound state like an in-memory shopping cart intact. The default mode, a 5-tuple hash including source and destination ports, spreads even repeat requests from the same client across different backends whenever the client uses a new source port, which is exactly the symptom described. A health probe threshold only governs how quickly an unhealthy instance is removed from rotation and has nothing to do with which instance a given client is routed to. An inbound NAT rule is for one-to-one management access, not client traffic distribution. Backend pools do not have a 'priority' setting on Standard Load Balancer — that concept belongs to Traffic Manager's priority routing method, not to a regional load balancer's pool. The caveat for the exam: source IP affinity is a coarser, less reliable persistence mechanism than cookie-based session affinity, and if true session stickiness matters more precisely, an Application Gateway with cookie-based affinity is the better Layer 7 tool. Operationally, confirm the fix by checking the load balancing rule's session persistence field reads 'Client IP' rather than 'None'.