AZ-104 Practice Question 36: App Service Plan Noisy Neighbour
Microsoft Azure Administrator Associate (AZ-104) · Test 4 · question 6 of 10
Five web apps share one Standard S1 App Service plan. One of them runs a nightly report that pegs the CPU, and while it runs the other four apps become slow. You scaled the plan out from one instance to three; the four apps are still slow during the report.
What should you do?
Show answer and explanation
Answer:
In a dedicated tier the VM instances belong to the plan, not to an app: "If multiple apps are in the same App Service plan, they all share the same VM instances," and "all apps in an App Service plan scale together, because they share the same underlying compute resources." So scaling out gave the report app three instances to saturate instead of one. Microsoft names this exact case as a reason to split: isolate an app in a new App Service plan when "the app is resource intensive" or when "you want to scale the app independently from the other apps in the existing plan." Compute is dedicated at the plan level, not the per-app level.
Option B adds to the problem rather than relieving it. "If you have multiple deployment slots for an app, all deployment slots also run on the same VM instances," and Microsoft notes that "an active slot is also classified as an active app because it's competing for resources in the same App Service plan."
Option C states something that isn't true of App Service plans. Every app in the plan runs on every instance configured for the plan, so more instances means more places the report app runs.
Option D solves a cold-start problem, not a contention one. Always On keeps an app loaded when it is idle; it grants no CPU reservation and does nothing about a neighbour consuming the instance.
Reference: Azure App Service plan overview