Cascade Regional Airlines expects a predictable but sharp spike in booking-site traffic every year during the holiday fare sale, driven by sustained high CPU usage across the web tier. Which autoscale configuration lets the scale set add instances automatically once CPU usage crosses a defined threshold, without requiring an operator to intervene?

A metric-based autoscale rule tied to average CPU percentage across the scale set instances directly measures the condition causing the performance concern and automatically adds instances once usage crosses the defined scale-out threshold, then removes instances once usage falls below a separate, typically lower, scale-in threshold, avoiding oscillation between the two actions. This requires no operator intervention once configured and adapts automatically even if the exact timing or magnitude of the holiday spike shifts year to year. A permanently fixed maximum instance count avoids under-provisioning during the spike but wastes money the rest of the year running at holiday-peak capacity for no reason. A manual scale operation depends entirely on a human remembering to act at the right moment, which is an operational risk, especially if the spike starts earlier or later than expected. A scale-in policy determines which specific instances are removed during a scale-in event; it does not decide when to scale and has nothing to do with reacting to CPU usage. As an operational check, review the Azure Monitor autoscale history after the next sale to confirm the rule actually fired at the expected CPU thresholds and that the scale-in threshold has enough of a gap from the scale-out threshold to prevent rapid flapping.