Shipping code is easy; shipping it safely, with a fast way back when something breaks, is what AZ-400 tests. This set focuses on deployment strategies: blue-green, canary, rings, A/B testing, deployment slots, feature flags with Azure App Configuration, database changes, hotfixes, and deploying dependencies in the right order. Most questions describe a business goal — reduce risk, avoid downtime, roll back fast — and ask which strategy fits.
This is the fourth post in our AZ-400 series (Questions 31-40). The previous set, AZ-400 Questions 21-30: Package Management and Testing Strategy, covers feeds, versioning, and quality gates. Every question here is an original practice scenario, not a copy of a real exam item.
Question 31: Instant Switch and Instant Rollback
Contoso runs two identical production environments. One serves all users while the new version is deployed and tested on the other. When ready, traffic switches to the new environment in one step, and switching back is the rollback plan. Which strategy is this?
A) Canary release
B) Blue-green deployment
C) Rolling deployment
D) A/B testing
👁 Reveal Answer
Correct Answer: B
Explanation: Blue-green deployment keeps two identical environments; the new version goes to the idle one, then a router or load balancer switches all traffic at once. Rolling back means switching back. A shifts a small share of traffic first and increases it gradually. C replaces instances a few at a time within one environment. D splits traffic between variants to compare user behaviour or business metrics, not to roll out a release safely. The trade-off of blue-green is cost: you run two full environments.
Question 32: Testing with a Small Slice of Real Users
Fabrikam wants to expose a new version to 5% of production traffic, watch error rates for an hour, and only then widen the rollout. Which strategy matches?
A) Big-bang deployment
B) Blue-green deployment
C) Canary release
D) Hotfix deployment
👁 Reveal Answer
Correct Answer: C
Explanation: A canary release sends a small percentage of real traffic to the new version, monitors it, and gradually increases exposure if it stays healthy. If problems appear, only a few users are affected and traffic can be pulled back. B switches everyone at once. A deploys to everyone with no staged exposure. D is about urgent fixes, not a general rollout pattern.
Question 33: Rolling Out by Audience Groups
Northwind Traders releases first to internal employees, then to a group of early-adopter customers, then to everyone, waiting at each step for health signals. What is this approach called?
A) Ring-based deployment (progressive exposure)
B) Blue-green deployment
C) Dark launching with no users
D) Recreate deployment
👁 Reveal Answer
Correct Answer: A
Explanation: Ring-based deployment defines audience groups (rings) and promotes a release outward one ring at a time, with health checks between rings. It is a form of progressive exposure, and in Azure Pipelines each ring is often modeled as a stage with its own environment and checks. B is a single all-at-once switch. C deploys code that no users see yet, usually behind a feature flag. D tears down the old version before starting the new one, causing downtime.
Question 34: Zero-Downtime Releases on App Service
Woodgrove Bank hosts a web app on Azure App Service (Standard tier). It wants to deploy a new version, warm it up, verify it, and make it live with no downtime — and roll back in seconds if needed. What should you use?
A) Deploy directly to the production slot and restart the app
B) Create a new App Service plan for every release
C) Scale the app down to zero, deploy, then scale back up
D) Deploy to a staging deployment slot, then swap it with production
👁 Reveal Answer
Correct Answer: D
Explanation: Deployment slots let you deploy to a staging slot, warm it up, and test it. A swap then exchanges staging and production with no downtime, and swapping again is a fast rollback. Settings marked as deployment slot settings stay with their slot, so production connection strings do not move to staging. A causes a restart and offers no quick rollback. C guarantees downtime. B adds cost and complexity without the built-in swap.
Question 35: Releasing Code Without Releasing the Feature
Adventure Works wants to deploy a new checkout flow to production now, but turn it on only for a pilot group next week and for everyone later — without redeploying. Which Azure service should manage this?
A) Azure App Configuration with Feature Manager
B) Azure Key Vault
C) Azure Front Door routing rules
D) A separate App Service plan
👁 Reveal Answer
Correct Answer: A
Explanation: Azure App Configuration’s Feature Manager stores feature flags that the application checks at run time. Filters, such as a targeting filter, can enable the feature for specific users or groups or a percentage of users, and changes take effect without a new deployment. This separates deploying code from releasing a feature. B stores secrets, keys, and certificates, not feature switches. C routes traffic between back ends but cannot toggle features inside the app. D adds infrastructure without controlling the feature.
Question 36: Comparing Two Designs
The marketing team at Tailspin Toys wants to show half of visitors a new product page layout and half the old one, then keep whichever produces more purchases. Which technique is this?
A) Rolling deployment
B) Blue-green deployment
C) A/B testing
D) Rollback testing
👁 Reveal Answer
Correct Answer: C
Explanation: A/B testing runs two variants at the same time for different users and compares a business outcome — here, purchases. It is an experiment, not a release-safety strategy. Feature flags are a common way to implement it. A and B are ways to roll out a new version safely, not to compare user behaviour. D is not a recognized strategy. On the exam, wording such as “compare,” “conversion,” or “which performs better” points to A/B testing.
Question 37: Deploying a Database Change Safely
Litware’s release renames a column used by the current application. The app and database are deployed by the same pipeline, and the team wants no downtime. What is the safest approach?
A) Rename the column, then deploy the new app version
B) Use an expand-and-contract approach: add the new column, deploy app code that works with both, migrate data, then remove the old column in a later release
C) Deploy the new app first and rename the column a week later
D) Take the database offline during business hours
👁 Reveal Answer
Correct Answer: B
Explanation: Expand and contract keeps the database compatible with both the old and new application versions during the rollout, so either can run while instances are updated and a rollback stays possible. In Azure Pipelines, schema changes are often applied with a DACPAC or migration scripts in a database step that runs before the app deployment. A breaks the running app the moment the column changes. C breaks the new app until the rename happens. D causes the downtime the team wants to avoid.
Question 38: An Urgent Production Fix
A critical bug is found in version 5.2, which is in production. The main branch already contains unfinished work for 5.3 that must not be released yet. What is the best hotfix path?
A) Fix the bug on main and release main immediately
B) Roll production back to version 4.0
C) Patch the production server by hand and document it later
D) Create a hotfix branch from the 5.2 release tag or branch, fix and deploy it through the pipeline, then merge the fix back into main
👁 Reveal Answer
Correct Answer: D
Explanation: Branching from exactly what is in production keeps unfinished work out of the fix. The hotfix still goes through the pipeline, often with a shortened but not skipped set of tests and approvals, and merging it back to main stops the bug returning in 5.3. A ships unfinished features. C bypasses every control and leaves production out of sync with source control. B throws away good features and may introduce older bugs. With trunk-based development and feature flags, the fix can often go on main instead, because unfinished work is hidden behind flags.
Question 39: Deploying Dependencies in Order
Coho Winery’s release includes a database schema update, an API that needs the new schema, and a front end that needs the new API. In what order should the YAML pipeline deploy them?
A) All three in parallel stages to save time
B) Front end, then API, then database
C) Database, then API, then front end, using dependsOn between stages
D) API first, then database and front end together
👁 Reveal Answer
Correct Answer: C
Explanation: Each component must deploy after the thing it depends on. Modeling the order with stage dependencies guarantees that the API only deploys after the schema succeeds and the front end only after the API succeeds; a failure stops the chain. A risks the API running against the old schema. B and D deploy consumers before their dependencies are ready, causing errors during the release.
Question 40: Updating a Server Farm Without Downtime
A virtual machine scale set of 20 web servers sits behind an Azure Load Balancer. You must update all of them with no outage and keep enough capacity to serve traffic throughout. What should you do?
A) Stop all 20 servers, update them, then start them together
B) Perform a rolling update in small batches, removing each batch from the load balancer while it updates
C) Delete the scale set and create a new one
D) Update only the first server and let replication copy the change
👁 Reveal Answer
Correct Answer: B
Explanation: A rolling update changes a few instances at a time. The load balancer health probe stops sending traffic to instances being updated, while the remaining instances keep serving users. Virtual machine scale sets support rolling upgrade policies that control batch size and pause time. A causes a full outage. C causes downtime and loses instance state. D is not how servers behind a load balancer receive application updates.
Study Tips for Deployment Strategies
- Match the keyword to the strategy. “Two identical environments” is blue-green; “small percentage first” is canary; “groups of users in order” is rings; “compare outcomes” is A/B testing.
- Separate deploy from release. Feature flags in Azure App Configuration let code ship dark and be turned on later.
- Know App Service slots. Deploy to staging, warm up, swap, and swap back to roll back. Slot settings stay with their slot.
- Design database changes for both versions. Expand, migrate, then contract in a later release.
- Order dependencies with stages. Database before API before front end, enforced with
dependsOn.
Keep Practicing for AZ-400
Continue with AZ-400 Questions 41-50: Infrastructure as Code and Pipeline Maintenance. For reference, read Microsoft’s guide to App Service deployment slots with Question 34, and the feature management overview with Question 35.
