A maple cooperative hosts its public storefront and an overnight import site on the same small App Service plan to save money. During imports the storefront becomes CPU-starved. What should the developer explain?
Select an answer to reveal the explanation.
Short Explanation
One small plan is one shared engine—two sites take turns on the same cylinders. When the overnight import floors the gas pedal, the storefront stalls in traffic. Give the noisy job its own plan if the public site must stay snappy.
Full Explanation
All web apps on the same App Service plan share that plan’s CPU, memory, and instance compute. When the maple cooperative’s overnight import and public storefront share a small plan, a heavy import can starve the storefront—noisy neighbor behavior at the plan level. Isolating the import onto a dedicated plan (or separating peak workloads) is the correct explanation.
Apps on one plan absolutely can share CPU; blaming only DNS on the custom domain misdiagnoses contention. Subscription quotas do not replace plan isolation; moving apps between plans is exactly how you separate noisy neighbors. Container Apps environments do not automatically isolate App Service sites from plan-level CPU contention; that statement mixes products.
Exam caveat: scaling the shared plan up can reduce starvation but still couples workloads. For true isolation, place the overnight import on its own plan or run it as a job/batch style workload off the public site’s plan.
Operational check: during a controlled import, watch storefront CPU and response times on the shared plan; move the import app to a second plan and repeat. Confirm the storefront remains responsive while the import burns CPU on its dedicated plan.