Cascade Regional Airlines needs a public IP for its booking-tier load balancer that is zone-redundant and denies all inbound traffic by default unless an NSG explicitly allows it. Which SKU should they choose, and why?
Select an answer to reveal the explanation.
Short Explanation
Standard public IPs come locked down by default — nothing gets in until an NSG says so — and they're the SKU that actually supports being spread across availability zones. Basic is the older, open-by-default option without that resiliency. For a public-facing booking system, Standard is the one built for this job.
Full Explanation
Standard SKU public IPs are secure by default, meaning inbound traffic is denied unless an associated NSG explicitly allows it, and they support zone redundancy, letting the IP remain available even if a single availability zone fails. Basic SKU public IPs, by contrast, allow all inbound traffic by default (with no NSG required to reach the resource) and do not support zone redundancy, making them a poor fit for a production booking-tier endpoint with both security and resiliency requirements. The claim that Basic is the only SKU compatible with load balancers is backwards; Standard Load Balancer specifically requires Standard SKU public IPs, and it is Basic Load Balancer that is the more limited, legacy option. The claim that dynamic allocation enables zone redundancy inverts the relationship: Standard SKU public IPs are always statically allocated, and static allocation is one of the properties that supports reliable zone-redundant behavior. Standard SKU being ‘open to all inbound traffic by default’ is also false; that describes Basic's behavior, not Standard's. Because Standard is secure by default, Cascade's team must remember to create explicit NSG allow rules for HTTPS before the load balancer will actually serve traffic.