AZ-400 exam's deployment strategy section asks 'once code is built and tested, how do you safely deliver it to production?' A poor deployment strategy can expose thousands of users to errors simultaneously, or turn a simple rollback into a multi-hour ordeal. This section covers five risk-distribution patterns, Feature Flags that control those patterns at the code level, and GitOps that manages infrastructure declaratively.
Like a Clothing Store Changing Seasons — Blue-Green and Recreate
Some stores clear out the entire winter collection before putting up spring items. Others keep two floors running at the same time and redirect shoppers to the new one when it is ready. deployment works like the first store. It shuts down the old version first, then brings up the new one. This is the simplest approach, but the service is completely offline during the transition. It is acceptable for internal tools with a maintenance window, but not suitable for production systems with external users.
deployment keeps two identical environments running at the same time. Blue hosts the current live version, while Green receives the new version. Once Green is ready, a load balancer or DNS entry switches traffic atomically to Green. If something goes wrong, you flip back to Blue. On Azure App Service, this pattern is implemented using and . Slot Swap completes warm-up requests before the traffic switch, eliminating cold-start latency at the moment of transition.
The main drawback is infrastructure cost. Maintaining two parallel environments nearly doubles your costs. A practical compromise is to scale up the Green slot during testing only, then scale down Blue right after the swap.
Like Turning a Faucet a Little at a Time — Canary and Rolling
Turning a faucet wide open all at once can cause a pressure surge. Opening it gradually lets you detect problems early and close it immediately if needed. deployment works the same way. It sends only a small fraction of traffic (for example, 5%) to the new version, then monitors error rates and response times before gradually increasing the percentage.
In Azure, you can implement Canary by setting traffic percentages on App Service Deployment Slots, or by adjusting Ingress weights in Azure Kubernetes Service (AKS). The key is connecting Azure Monitor alerts to automated proceed and rollback conditions based on measured metrics.
deployment replaces instances one at a time in sequence. Because the old and new versions run simultaneously for a period, strict API backward compatibility is required. In AKS, the and parameters control the pace of the rollout.
| Pattern | Downtime | Infrastructure Cost | Rollback Speed | |---------|----------|---------------------|----------------| | Recreate | Yes | Low | Slow | | Blue-Green | None | High | Immediate | | Canary | None | Medium | Fast | | Rolling | None | Low | Medium |
!4 deployment strategies compared
Like a Drug Clinical Trial — Feature Flags and Progressive Delivery
Deploying a new feature does not mean every user should see it immediately. Clinical drug trials start with a small group of volunteers, and only move to the next phase after the results look promising. A controls whether a feature is on or off at runtime, even though the code is already deployed. It is the essential tool for separating deployment from release.
In Azure, you use together with the library. Feature flag key-value pairs are stored in App Configuration, and your .NET, Java, or Python application connects to App Configuration using Azure.Identity to read the flags at runtime. You can configure conditions based on specific user IDs, a percentage of users, geography, or any custom attribute. GitHub Feature Flags and LaunchDarkly follow the same concept.
combines Canary deployments, Feature Flags, and observability into a single approach. You deploy the code with the flag turned off, then open the flag gradually while monitoring metrics. Once an experiment is complete, cleaning up the flag condition code should be part of the pipeline. Flags that pile up over time add complexity and make the codebase harder to reason about.
Like Writing a Score for an Orchestra to Follow — GitOps
When a conductor writes fast and loud in the score, the musicians play accordingly without needing to be told each note individually. applies the same idea to Kubernetes clusters. You declare the desired state of the cluster as YAML files in a Git repository, and an agent continuously compares that declared state with the actual cluster state and reconciles any differences.
and are the leading GitOps tools. Flux either polls the Git repository or listens for webhook events to detect changes, then applies them to the cluster. ArgoCD adds a visualization UI and synchronization policies on top of the same model. On Azure, you connect AKS to and install the Flux extension to manage GitOps centrally across multiple clusters.
The core value of GitOps is the audit trail. Because every infrastructure change is a Git commit, you always have a clear record of who changed what, when, and why. Rollbacks are handled with . A common pattern pairs Azure Pipelines for building and testing application code with GitOps for managing cluster state, keeping the two responsibilities cleanly separated.
Keeping Traffic Moving While Repaving the Road — Database Migrations
You cannot block all traffic just because the road needs repaving. You close one lane, reroute traffic through the other, and keep construction moving. Database schema changes are the most delicate part of a deployment for exactly this reason. Applications can be swapped out quickly, but a schema change is difficult to roll back.
The approach follows three stages: Expand, Migrate, and Contract. First you add the new column (Expand), then you migrate existing data into it (Migrate), and finally you remove the old column (Contract). During the Expand phase, both old and new schemas are supported simultaneously, so that a Blue-Green deployment can have the Green app using the new schema while the Blue app continues to use the old one without failure.
The migration principle is: never delete or rename an existing column until the old version of the application is completely retired. Column deletions or renames can break the currently running version. On Azure, tools like EF Core Migrations, DACPAC/BACPAC, and Flyway automate this discipline. Migration scripts belong in the pipeline as an explicit step, and every script must be idempotent — running it multiple times should produce exactly the same result as running it once.
Exam Key Takeaways
"Send only a portion of traffic to the new version for monitoring" -- Canary deployment "Maintain two environments and switch traffic atomically" -- Blue-Green / Slot Swap "Separate code deployment from feature release" -- Feature Flag "Store and manage Feature Flags on Azure" -- Azure App Configuration + Feature Manager "Git repository as the single source of truth for cluster state" -- GitOps "Managed GitOps agent for AKS on Azure" -- Azure Arc + Flux extension "Required condition when old and new versions run simultaneously in Rolling" -- API backward compatibility "Add column, migrate data, drop old column to protect running app during schema change" -- Expand-Migrate-Contract (Forward-only) "Tear down all instances before deploying new version, downtime accepted" -- Recreate deployment "AKS Rolling deployment pace control parameters" -- maxUnavailable / maxSurge
Blue-Green = immediate rollback, Canary = gradual validation, Feature Flag = separate deploy from release, GitOps = Git as the source of truth.