The booking site's App Service is on a Standard S2 plan running two instances. During a flash sale, thousands of concurrent users push CPU usage to its ceiling across all instances simultaneously, even though per-request memory usage stays modest. What is the most appropriate first response to relieve the CPU pressure?
Select an answer to reveal the explanation.
Short Explanation
With CPU maxed out because thousands of people are hitting the site at once, the fix is more workers sharing the load, not a bigger single worker. Scaling out spreads that concurrent demand across additional instances, which is exactly what a high-concurrency, CPU-bound spike calls for.
Full Explanation
Scaling out adds more instances running the existing plan size, distributing incoming concurrent requests across a larger pool of compute, which directly addresses a bottleneck caused by request volume rather than by any single request being resource-heavy. The scenario describes CPU maxing out under high concurrency while per-request memory stays modest, which is the classic signature calling for horizontal scaling rather than a bigger box. Scaling up to add memory would not relieve CPU pressure at all, since the constraint described is CPU, not memory, and increasing an unrelated resource would leave the actual bottleneck untouched. Disabling autoscale during the exact event autoscale exists to handle removes the platform's ability to respond automatically and would likely make the outage worse, not better. Moving to the Free tier during a traffic spike would drastically reduce available compute at the worst possible moment and would also strip away features like custom domains and slots the production site likely depends on. As an operational check, watch the CPU percentage metric per instance after scaling out to confirm it drops toward a sustainable range, and consider pairing the manual scale-out with a CPU-based autoscale rule so the response becomes automatic for the next spike.