You deploy an update to a website, and suddenly every user sees a broken page. Without understanding deployment patterns, you risk crashing your entire application for every customer at once. These patterns are the playbooks that keep your service running smoothly while you roll out changes, and the AZ-400 exam tests whether you can choose the right playbook for the right situation.
Jump to a section
A simple way to picture Implementing Deployment Patterns and Strategies
Your friend is renovating a 3-bedroom house. You are the project manager, and the goal is to replace the old wiring without anyone living in the dark for more than a few minutes at a time.
First, the 'Blue-Green' strategy: you build a complete, fully-furnished replica of the house on the lot next door. This is the 'green' house. All the wiring is new and perfect. You then switch the families over on Saturday morning while they're eating breakfast. The old 'blue' house sits empty. If the new wiring has a fault, you switch everyone back in 10 minutes. Zero downtime, instant rollback.
Next, a 'Canary' release: you rewire only one bedroom first. One family member sleeps there. If the lights flicker, you fix it before touching the rest of the house. Only a few people are affected, and the risk is contained.
Then there is 'Rolling' deployment: you rewire one room at a time, moving the family between rooms as you go. The kitchen works while the lounge is dark. No single moment of full blackout, but the process takes days.
Finally, 'Feature Toggles': you install a hidden switch behind the living room couch. The new chandelier is wired and tested but switched 'off' at the wall. You can flip the toggle during a party when no one is looking. The feature exists in the house but is invisible until you decide to turn it on.
Deployment patterns are standardised ways of releasing new software to users. They exist to solve one central problem: how do you change a system that people are actively using without breaking their experience? The old way was to simply overwrite the live application with the new version — this is called a 'Big Bang' deployment. If something went wrong, the whole service was down until someone fixed it. Modern patterns avoid that risk.
First, let's define a 'release' versus a 'deployment'. A deployment is the act of putting new code onto a server. A release is when that new code actually becomes visible or active for users. You can deploy without releasing. This distinction is fundamental to several patterns.
Blue-Green Deployment (sometimes called Red-Black at Netflix) uses two identical environments. 'Blue' is the current live production environment. 'Green' is the new version running on identical infrastructure. When green is fully tested and ready, you flip the router — all traffic now goes to green. If green fails, you flip back to blue. The key point: the previous version remains running and ready, so rollback is instantaneous. This pattern requires double the infrastructure during the transition, which costs money. It is best for high-traffic applications where even seconds of downtime cost revenue.
Canary Release is named after the old practice of taking a canary into a coal mine. If the canary died, the miners knew the air was toxic. With a canary release, you send a small percentage of your users — maybe 5% — to the new version of your application. You monitor their behaviour and error rates. If the canary group experiences problems, you stop the release and fix the code before any other users see it. If the canary is healthy, you gradually increase the traffic percentage to 10%, then 25%, then 50%, then 100%. This pattern is slower than blue-green but requires less infrastructure overhead.
Rolling Deployment updates instances one by one. Imagine you have 10 servers running your application. With a rolling deployment, you take server 1 out of the load balancer, update it, test it, then put it back. Then server 2, then server 3, and so on. At any given moment, at least 9 servers are working normally. This pattern works well when you have many small, identical servers and don't want to double your infrastructure costs.
Feature Toggles (also called Feature Flags) are not exactly a deployment pattern but a technique that supports them. A feature toggle is a configuration setting that turns a feature on or off without deploying new code. You deploy code with the new feature included but set to 'off'. Later, you flip the toggle to 'on' for specific users or groups. This lets you test features in production with small audiences. It also lets you turn off a problematic feature instantly without rolling back the entire deployment.
Ring-Based Deployment is popular at Microsoft. You organise your users into rings. Ring 1 is the development team. Ring 2 is the internal IT department. Ring 3 is a small group of external 'insider' users. Ring 4 is 10% of general users. Ring 5 is everyone. Each ring gets the update only after the previous ring reports no critical issues. This is like a canary release but with clearly defined groups rather than random percentages.
Slot-Based Swapping in Azure App Service uses deployment slots. A slot is a separate instance of your app with its own hostname. You deploy to a 'staging' slot, test it, then 'swap' the staging and production slots. The swap is atomic — either it works or it doesn't. This is Azure's native implementation of blue-green deployment. You can also do 'auto-swap' where Azure automatically swaps a slot after a successful deployment.
Why does this matter for AZ-400? The exam will present a scenario: 'Your company has 50,000 users and cannot afford any downtime. They want to test a new feature with 5% of users before full rollout. Which pattern should you use?' The answer is a canary release. Or: 'You need to roll back immediately if a deployment fails. Your budget is tight. Which pattern minimises cost while allowing quick rollback?' The answer might be a ring-based deployment with feature toggles.
The most common exam traps are around terminology. 'Blue-green' and 'slot swap' are the same concept. 'Canary' and 'ring-based' are similar but not identical. The exam expects you to know the trade-offs: blue-green costs more but offers the fastest rollback. Rolling deployments are cheap but slow to roll back. Feature toggles decouple deployment from release.
Analyse Business Constraints
Before choosing a pattern, identify the non-negotiable requirements: maximum acceptable downtime, budget for infrastructure, rollback speed needed, and whether you need to test with real users. This step determines whether you use blue-green (zero downtime, high cost) or rolling (no extra cost, slower rollback).
Implement Feature Toggles in Application Code
Work with developers to add toggle logic around new features. Each toggle must have a default state (usually 'off') and must be controllable via configuration or a dedicated feature management service like Azure App Configuration. This step ensures you can deploy code without automatically releasing it.
Set Up Deployment Slots or Target Environments
In Azure App Service, create a staging slot that mirrors production. For blue-green, this is the 'green' environment. For canary, you might need additional slots or use Azure Traffic Manager to route a percentage of traffic. This step creates the infrastructure structure for the chosen pattern.
Deploy Code to the Staging or Secondary Environment
Use Azure Pipelines or another CI/CD tool to push the new code to the staging slot or to a canary instance. This is the 'deployment' step. The code includes the feature toggle configuration. After deployment, run automated smoke tests to verify basic functionality.
Route Traffic and Monitor the Canary (if applicable)
If using canary release, configure Azure Traffic Manager or the App Service routing feature to send a small percentage of user traffic to the updated environment. Monitor error rates, latency, and user complaints using Azure Monitor and Application Insights. If metrics are healthy, gradually increase the traffic percentage.
Swap Slots or Release to Full Production
For blue-green, perform the slot swap. For rolling, update the remaining servers. For feature toggle releases, flip the toggle to 'on' for the target user segment. This is the 'release' step. Verify that all users see the correct version.
Document and Practise Rollback Procedure
Write a runbook with the exact steps to revert the deployment: swap slots back, turn off a feature toggle, or restart the rolling update in reverse. Practise the rollback quarterly. The exam values preparedness for failure as much as the deployment itself.
Meet Priya, a release engineer at a mid-sized e-commerce company called 'ShopFast'. ShopFast runs a website that gets 2 million visitors a day. They have a new checkout feature that saves user addresses automatically. Priya needs to deploy this feature without breaking sales.
Priya starts by checking the current architecture. ShopFast uses Azure App Service with a standard tier plan. She has two deployment slots: 'production' and 'staging'. The infrastructure is set up for a blue-green approach, but Priya knows that a full blue-green swap would expose every user to the new checkout feature immediately. That is risky because if the address-saving feature has a bug, all users will see errors.
Instead, Priya combines two patterns. First, she implements a feature toggle for the new address-saving functionality. The code is deployed to the staging slot with the toggle set to 'off'. She swaps the staging and production slots during a low-traffic period (3 AM). Now the new code is on production, but the feature is invisible because the toggle is off. This is the 'deploy' step without the 'release'.
Next, Priya sets up a canary release using Azure Traffic Manager. She directs 2% of users to a third slot that has the feature toggle turned 'on'. She monitors error rates and user complaints for 24 hours. All looks good. She increases to 10%. After another 24 hours, she increases to 50%. Finally, she turns the toggle on for everyone.
Three days later, marketing wants to test a 'buy now, pay later' button. Priya sets up a new feature toggle and repeats the process. She also documents the procedure in a runbook — a step-by-step manual for the on-call engineer. The runbook includes the exact commands to turn off a toggle or to swap slots back if something goes wrong.
The real-world job involves:
Choosing the right pattern for the business constraint
Configuring deployment slots or infrastructure as code (IaC) templates
Setting up monitoring and alerting for the canary group
Writing feature toggle configuration files
Practising rollback drills once a quarter
Coordinating with developers to ensure toggle logic is in the code
Priya's day-to-day includes reviewing Azure Monitor dashboards during canary releases, updating YAML files for Azure Pipelines, and answering questions from developers about how to implement toggles in their code. She also attends a weekly 'release readiness' meeting where the team decides which pattern to use for the next deployment.
The AZ-400 exam tests 'Implement deployment patterns and strategies' in a very specific way. You will see scenario-based multiple-choice questions. The key is to match the scenario's constraints (downtime tolerance, cost, rollback speed, user segment size) to the correct pattern.
Question Types: - 'You need to release a new feature to a small subset of users for testing. Downtime is not acceptable. Which pattern?' Answer: Canary release. - 'Your application runs on 20 virtual machines. You need to update each VM without taking the entire application offline. Budget is limited.' Answer: Rolling deployment. - 'You need to swap the entire environment instantly with zero downtime and have the ability to roll back immediately.' Answer: Blue-green deployment or slot swap. - 'You need to deploy code that is inactive until a later date. Which technique?' Answer: Feature toggle / feature flag.
Common Traps: - The exam might describe a scenario where cost is a concern but the question mentions 'high availability'. Beginners often choose blue-green for high availability, but blue-green doubles infrastructure cost. If the scenario mentions 'limited budget', the correct answer is likely rolling deployment. - Another trap: confusing 'canary' with 'blue-green'. Both can have zero downtime, but canary releases expose only a percentage of users to the new version, while blue-green exposes 100% after the switch. - Feature toggles are often the correct answer when the question mentions turning a feature off quickly without redeploying. - The term 'slot swap' is Azure-specific. The exam might ask: 'Which Azure App Service feature supports blue-green deployments?' The answer is 'deployment slots with swap'.
Key Concepts to Memorise: - The difference between 'deployment' and 'release'. - The infrastructure cost implications of each pattern. - The rollback speed of each pattern (blue-green fastest, rolling slowest). - That feature toggles require code changes and are a developer responsibility to implement correctly. - That ring-based deployment organises users by groups (internal, beta, production) rather than random percentages.
Exam Tips: - Read the scenario twice. Look for keywords: 'immediate rollback' (blue-green), 'cost sensitive' (rolling), 'test with a few users' (canary), 'gradual rollout by user group' (ring-based). - If the question mentions 'Azure App Service', immediately consider deployment slots. - If the question mentions 'feature preview' or 'early access', think canary or ring-based. - Do not overcomplicate. The simplest pattern that meets the constraint is usually correct. - Remember that you can combine patterns. A question might describe using feature toggles within a canary release. The answer could be 'feature toggles' if the question asks about the technique for hiding the feature.
Blue-green deployment uses two identical environments and flips traffic between them, offering instant rollback at double the infrastructure cost.
A canary release exposes a small percentage of users to a new version to gather real-world feedback before full rollout.
Rolling deployment updates servers one by one, minimising cost but making rollback slow because each server must be individually reverted.
Feature toggles decouple deployment from release, allowing code to be deployed but kept inactive until the toggle is turned on.
Ring-based deployment organises users into ordered groups (internal, beta, production) and releases software to each ring sequentially.
Slot swapping in Azure App Service is the native implementation of blue-green deployment, but you can combine it with traffic routing for canary-like behaviour.
The correct deployment pattern depends on the business constraints: cost, downtime tolerance, rollback speed, and testing requirements.
A deployment is the act of putting code on a server; a release is making that code visible to users.
These come up on the exam all the time. Here's how to tell them apart.
Blue-Green Deployment
Switches 100% of traffic from old to new environment at once.
Requires two identical environments running simultaneously, doubling infrastructure cost.
Rollback is instant by flipping traffic back to the old environment.
Canary Release
Sends only a small percentage of user traffic to the new version initially.
Uses only one production environment; the new version shares infrastructure with the old version.
Rollback is gradual or instant depending on whether you stop routing traffic to the new version.
Rolling Deployment
Updates servers one at a time, keeping most servers running the old version.
No extra infrastructure cost; only the existing servers are used.
Rollback requires updating each server again, which takes time.
Blue-Green Deployment
Updates all servers simultaneously by swapping traffic between two full environments.
Doubles infrastructure cost because both environments run concurrently.
Rollback is near-instantaneous by switching traffic back to the old environment.
Feature Toggle (Flag)
A configuration setting that hides or reveals a feature without deploying new code.
Works at runtime; you can change the toggle value without restarting the application.
Perfect for gradual rollouts and emergency disabling of features.
Branch by Abstraction
A code-level technique where new code is introduced behind an abstraction layer.
Requires code changes and often a new deployment to expose the feature.
Used for long-lived feature work that spans multiple releases.
Deployment
The act of installing new code onto a server or environment.
Can happen without users ever seeing the new code.
Example: deploying a new version to a staging slot without swapping.
Release
The act of making that code visible or active for users.
Can happen hours or days after deployment through a toggle or slot swap.
Example: turning on a feature toggle to show a new button to all users.
Mistake
Blue-green deployment is always the best choice because it offers the fastest rollback.
Correct
Blue-green deployment doubles your infrastructure cost because you need two full environments running simultaneously. It is only the best choice when the cost of downtime exceeds the cost of duplicate infrastructure.
Beginners often assume that 'best' means 'most reliable' without considering cost. The exam explicitly tests trade-offs.
Mistake
A canary release and a rolling deployment are the same thing.
Correct
A canary release sends a percentage of traffic to new servers while old servers remain untouched. A rolling deployment updates each server one by one, so at any moment different servers run different versions of the code.
Both patterns involve gradual updates, but the mechanism and risk profile are different. The exam uses the distinct terminology to differentiate them.
Mistake
Feature toggles are only useful for testing in development environments.
Correct
Feature toggles are used in production to turn features on or off without redeploying. They enable 'dark launches' (deploying code that is inactive) and allow operators to disable problematic features instantly.
People confuse testing environments with production techniques. Feature toggles are a production operational tool, not just a development convenience.
Mistake
If you use a slot swap in Azure App Service, you cannot use a canary release.
Correct
You can use a slot swap for the deployment and then use a feature toggle within the swapped application to control who sees the new feature. Azure also supports 'routing traffic to a slot' which lets you send a percentage of users to a specific slot, enabling canary releases with slots.
The exam tests whether you understand that patterns can be combined. Slot swap and canary are not mutually exclusive.
Mistake
Rollback is equally fast for all deployment patterns.
Correct
Blue-green rollback is near-instantaneous (flip traffic back). Rolling deployment rollback requires updating each server again, which takes as long as the original deployment. Feature toggle rollback is instant if the toggle code is already in place.
Beginners focus on the deployment phase and forget about the rollback phase. The exam frequently asks about rollback speed.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
They are conceptually identical. A slot swap in Azure App Service is Microsoft's implementation of blue-green deployment, where you swap the staging and production slots to switch traffic instantly.
Yes. Azure App Service supports 'routing traffic to a slot', which lets you send a percentage of your user traffic to a specific deployment slot, enabling canary releases without additional tools.
Yes, during the transition, you need both the blue and green environments running simultaneously, which doubles your compute cost. After the swap, you can decommission the old environment or keep it for the next cycle.
A feature toggle allows you to turn a feature on or off without redeploying code. This is useful for gradual rollouts, A/B testing, and emergency disabling of problematic features.
Choose rolling when your infrastructure cost cannot increase and you can tolerate sequential updates. Choose canary when you need real user feedback before full rollout and can afford to route a small percentage of traffic to the new version.
Ring-based deployment organises users into groups (rings) such as internal team, beta testers, early adopters, and general audience. The update is released to each ring only after the previous ring shows no critical issues.
You've finished Implementing Deployment Patterns and Strategies. Continue through the AZ-400 study guide to build a complete picture of the exam.
Done with this chapter?