AZ-305 Practice Question 49: Zero Downtime Release
Microsoft Azure Solutions Architect Expert (AZ-305) · Test 5 · question 9 of 10
A media company deploys its App Service web app, running on a Premium v3 plan, twice a week. Users currently see errors for about a minute after each deployment while the app warms up. The release process must be redesigned so that:
- no request is dropped during a release, and the new code is warmed up before it receives traffic, - a bad release can be reverted within seconds, without rebuilding or redeploying the package, - the production database connection string stays with the production environment rather than travelling with the deployed code.
What should you recommend?
Show answer and explanation
Answer:
Deployment slots are available on the Standard, Premium, and Isolated tiers, so a Premium v3 plan qualifies, and they answer each requirement directly. The swap operation warms up every instance of the source slot before switching the routing rules, which Microsoft describes as eliminating downtime on deployment with seamless traffic redirection and no requests dropped. After a swap, the staging slot holds the previous production app, so performing the same swap again immediately restores the last known good site, a rollback in seconds with nothing to rebuild. And connection strings can be configured to stick to a slot, so the production connection string stays in production rather than being swapped with the code.
Option A keeps the outage and just moves it to a quieter hour. Redeploying the old package is a full deployment, so rollback is measured in minutes, and there is still no warm-up before traffic arrives.
Option B is a heavier, DNS-based version of the same idea. It doubles the plan cost, and Traffic Manager shifts traffic by handing out DNS answers, so clients and resolvers keep using the old address until the record's TTL expires, neither the instant cutover nor the instant rollback the requirements ask for.
Option D addresses capacity, not release safety. Adding instances and restarting them in sequence still puts new code straight into the production path with no validation, no warm-up guarantee, and no way back other than another deployment.