AZ-104 Practice Question 16: App Service Slot Tier
Microsoft Azure Administrator Associate (AZ-104) · Test 2 · question 6 of 10
A web app runs on an App Service plan in the Basic tier. Releases currently cause about two minutes of downtime, and the last rollback took an hour. The team wants to validate each build on a live URL first, cut over with no dropped requests, and be able to return to the previous build in seconds.
There is no budget for a second region. What should you do?
Show answer and explanation
Answer:
Deployment slots are the built-in answer to this problem, and they are "available if you run in the Standard, Premium, or Isolated tier of an App Service plan", so the Basic plan must be scaled up first. A slot is a live app with its own host name, so the build can be validated before release. During a swap, every instance of the source slot is warmed up before the routing rules switch, which means "no requests are dropped because of swap operations." Rollback is the same swap run again: after a swap the staging slot holds the previous production app.
Option A does not address deployments at all. Always On keeps the app warm so it is not unloaded when idle; restarting after a deployment adds downtime rather than removing it.
Option B is not how slots work, and it is not possible as described. Slots live inside the same App Service plan as the app, and moving an app between plans is a configuration change with its own disruption, not a warmed-up, atomic cut-over.
Option D buys capacity, not a safe release. Scaling out deploys the same new build to every instance; if the build is bad, all instances serve it, and there is no previous version parked anywhere to swap back to.