Cascade Regional Airlines is rebuilding its public booking site behind an Azure Load Balancer that fronts identical web farms in the Denver and Boise regions, and the network team wants the load balancer's frontend to keep working even if an entire availability zone in a region goes down. Which load balancer SKU must they choose to get zone-redundant frontend IP configurations?

A zone-redundant frontend IP means a single Standard Load Balancer frontend has a presence across all availability zones in the region, so the loss of one zone doesn't take the frontend offline — traffic simply keeps flowing to healthy backend instances in the surviving zones. This is a property of the Standard SKU specifically; the Basic SKU has no concept of availability zones at all and is being retired for production workloads. The Gateway SKU distractor confuses two different products: it refers to a Gateway Load Balancer used to insert third-party network virtual appliances transparently into a traffic path, not a tier of the standard public/internal load balancer. Pointing at a Traffic Manager profile SKU is a category error — Traffic Manager is a DNS-based global routing service with no SKU tiers of this kind, and it operates above the load balancer, not as a replacement for it. The exam-relevant caveat: Standard Load Balancer also defaults to a secure-by-default posture, meaning outbound access requires explicit configuration (an outbound rule or NAT gateway) rather than the implicit outbound access Basic SKU backend VMs enjoyed. Operationally, confirm the choice in the portal by checking that the load balancer's SKU field reads Standard and that its frontend IP configuration lists an availability zone setting of 'Zone-redundant' rather than 'No zone redundancy'.