AZ-400 Question 155
Single answerYou are a DevOps engineer for a company hosting a critical web application on Azure App Service. The team wants to deploy new versions of the application with minimal downtime and risk, while also allowing quick rollback if any issues arise. Which deployment approach best meets these requirements?
- A
Deploy a single App Service directly to production in each new release pipeline stage.
- B
Use a staging slot within the same App Service, validate the new version, then swap it into production.
- C
Build a standalone environment for every deployment and manually copy over the assets into the production environment.
- D
Use FTP-based deployment to overwrite the existing production site files.
Show answer and explanation
Correct answer: B
Explanation
Azure App Service deployment slots provide an effective way to implement blue-green style deployments. A staging slot runs the app in a production-like environment, and once verified, you can swap with the production slot. This swap process typically takes seconds and helps minimize downtime and risk. If an issue is detected post-swap, you can quickly swap back. For details, see Microsoft documentation: https://learn.microsoft.com/azure/app-service/deploy-staging-slots.
- A. Incorrect.
Option 1: Incorrect. Deploying directly to production in a single slot does not provide a robust way to verify the new version, nor does it allow a quick rollback. It typically results in some downtime or service interruption.
- B. Correct.
Option 2: Correct. Using a staging slot in Azure App Service enables you to test the new version in a production-like environment before swapping slots. This swap process helps minimize downtime and allows rapid rollback by swapping back if issues occur.
- C. Incorrect.
Option 3: Incorrect. While building a separate full environment can provide isolation, manually copying assets into production is error-prone and can still incur significant downtime. It also lacks the seamless swap functionality that slots offer.
- D. Incorrect.
Option 4: Incorrect. Using FTP to overwrite files in production is risky and can cause downtime. It also has no rollback mechanism besides manually re-uploading previous files.