This chapter covers Azure App Service deployment slots and traffic splitting, a critical feature for zero-downtime deployments and A/B testing. On the AZ-204 exam, this topic appears in roughly 10-15% of questions related to Compute (Objective 1.3), often in scenarios about safe deployment strategies and slot swapping. You will need to understand slot types, swapping mechanics, auto-swap, traffic routing, and how to handle app settings and connection strings across slots. Mastery of these concepts is essential for passing the exam and for real-world Azure development.
Jump to a section
Imagine a theater company that performs a show every night in a grand theater (the production slot). They have a smaller rehearsal space (the staging slot) where they can practice changes to the script, lighting, and choreography without affecting the paying audience. The rehearsal space is a complete copy of the grand theater—same stage dimensions, same props, same number of seats. After rehearsing, the director can 'swap' the entire production by having the cast and crew move all sets and props from the rehearsal space to the grand theater in a single coordinated move (swap). Alternatively, the director can send a small group of test audience members into the grand theater to watch a mixed performance where 10% of the scenes use the new script and 90% use the old script (traffic splitting). This allows the director to gauge audience reactions before committing fully. The key is that both theaters are fully equipped and isolated—changes in the rehearsal space never affect the main show until the swap or split is activated. The director can also warm up the new show by running it in the rehearsal space for hours before the swap, ensuring everything runs smoothly. This mirrors Azure App Service deployment slots: the production slot serves live traffic, the staging slot is a separate environment with its own app settings and scaling, and swapping or traffic splitting lets you validate changes with zero or partial traffic before full rollout.
What are Deployment Slots?
Azure App Service deployment slots are live, fully functional environments that are separate instances of your app, each with its own hostname and app settings. Each slot runs in its own isolated App Service plan instance (though they share the same plan if you choose). The main slot is called 'production' (always exists), and you can add up to 5 additional slots for Standard tier, up to 20 for Premium tier, and up to 5 for Isolated tier. Slots are designed to enable safe deployment: you can deploy a new version to a staging slot, validate it, then swap it into production with zero downtime.
How Slot Swapping Works Internally
When you perform a swap between two slots, Azure does NOT physically move files or restart the app. Instead, it swaps the virtual IP (VIP) addresses of the slots. The production slot's VIP is moved to the staging slot, and vice versa. This means the DNS name for your app (e.g., myapp.azurewebsites.net) now points to the staging slot's instance. The swap process is atomic and synchronous: all requests in flight are drained before the swap completes. The steps are:
Validate source and target slots: Azure checks that both slots exist and are in the same region and resource group.
Apply target slot settings to source slot: All connection strings and app settings marked as 'slot-specific' (sticky) from the target slot are applied to the source slot. This ensures that after swap, the app behaves as expected with the correct settings. However, this step does not restart the app; it only writes settings to the source slot's configuration store.
Wait for source slot to restart: If any settings changed (especially connection strings that cause a restart), the source slot restarts. This is why you should avoid changing settings that force restart during swap; otherwise, you might see a brief downtime.
Swap VIPs: The VIP of the source slot is swapped with the VIP of the target slot. This is a network-level change that takes effect almost instantly.
Post-swap operations: Azure may apply any auto-swap triggers or perform cleanup.
Key Components, Defaults, and Timers
Slot types: Production (always exists), additional slots named by you (e.g., staging, testing).
Maximum slots: Standard: 5, Premium: 20, Isolated: 5.
Slot-specific settings (sticky): You can mark app settings, connection strings, and other configuration as 'slot-specific'. These settings stay with the slot, not the app code. When you swap, sticky settings from the target slot are applied to the source slot before VIP swap. Non-sticky settings travel with the code.
Auto-swap: You can enable auto-swap on a slot so that every time you deploy to that slot, Azure automatically swaps it with the target slot (usually production). The default is disabled. When enabled, the swap happens after the deployment is complete and the slot is warmed up.
Traffic splitting: You can route a percentage of incoming traffic to a slot without swapping. This is done by setting the routingWeight property on the slot. The value is a percentage (0-100) that determines the proportion of requests sent to that slot. The sum of weights across all slots must equal 100. Traffic is split at the front-end load balancer using a hash of the client IP or other identifiers to ensure session affinity (same client goes to same slot).
Warm-up: Before swapping, you can configure a warm-up path (e.g., '/warmup') that Azure pings to ensure the slot is ready. The default warm-up time is 30 seconds, but you can customize it.
Swap duration: Typically a few seconds to a minute, depending on the number of settings and whether a restart is required.
Configuration and Verification Commands
Using Azure CLI:
# Create a deployment slot
az webapp deployment slot create --name MyApp --resource-group MyRG --slot staging
# Swap slots
az webapp deployment slot swap --name MyApp --resource-group MyRG --slot staging --target-slot production
# Configure traffic routing
az webapp traffic-routing set --name MyApp --resource-group MyRG --distribution staging=10 production=90
# List slots
az webapp deployment slot list --name MyApp --resource-group MyRG
# Show slot settings
az webapp config appsettings list --name MyApp --resource-group MyRG --slot stagingUsing Azure PowerShell:
New-AzWebAppSlot -ResourceGroupName MyRG -Name MyApp -Slot staging
Swap-AzWebAppSlot -ResourceGroupName MyRG -Name MyApp -SourceSlotName staging -DestinationSlotName production
Set-AzWebAppSlot -ResourceGroupName MyRG -Name MyApp -Slot staging -RoutingWeight 10Interaction with Related Technologies
Azure DevOps: Deployment slots integrate seamlessly with Azure DevOps release pipelines. You can deploy to a staging slot, run smoke tests, then use a 'Swap Slots' task to promote to production.
App Service Plans: Slots within the same plan share the same VM instances but run as separate worker processes. If you scale the plan, all slots scale together. For isolation, use separate plans.
Authentication/Authorization: When using Azure AD authentication, you must ensure the redirect URIs include the slot's hostname. Slot swapping does not automatically update the registered app's reply URLs.
Custom Domains and SSL: Custom domains are bound to the slot's hostname. When swapping, you might need to rebind certificates if they are slot-specific. Azure automatically handles swapping of SSL bindings for the production slot.
Traffic Manager: If you use Azure Traffic Manager for global load balancing, you can direct traffic to different slots in different regions for advanced routing scenarios.
Important Details for Exam
Sticky vs Non-sticky settings: Only settings marked as 'slot-specific' stay with the slot. All other settings (like connection strings not marked) travel with the code during swap. The exam loves to test this: if you have a connection string that should point to a production database, it must be marked as slot-specific; otherwise, it will be swapped with the staging slot's value.
Auto-swap prerequisites: Auto-swap requires the source slot to have a successful deployment. It does not work if the deployment fails.
Traffic splitting is not sticky: Once you split traffic, the slot receives that percentage of requests. However, if you later swap the slot, the routing weights reset. You must reconfigure traffic splitting after a swap.
Swap with preview: You can perform a 'swap with preview' which first applies target settings to source slot but does not swap VIPs. This allows you to validate the app with production settings before finalizing. This is useful for testing behavior with production connection strings.
Slot cloning: You can clone settings from one slot to another when creating a new slot, but this is a one-time operation; subsequent changes are not synced.
Limitations: Slots are not available in Free or Shared tiers. Also, slots cannot be used with Azure Functions in Consumption plan (only Premium plan).
Create a Staging Slot
In the Azure portal, navigate to your App Service, select 'Deployment slots' under Deployment, then click 'Add Slot'. Give it a name (e.g., 'staging'). You can clone settings from an existing slot (e.g., production) to avoid reconfiguring. The new slot is created as a separate instance with its own hostname (myapp-staging.azurewebsites.net). It runs the same code as the source slot initially. The slot is immediately available and can be accessed via its URL. This step is the foundation for safe deployment.
Deploy Code to Staging Slot
Deploy your new application version to the staging slot using your preferred method (FTP, Git, CI/CD, Azure DevOps). The deployment targets the staging slot's URL and does not affect production. The staging slot restarts to load the new code. During this time, the staging slot is unavailable, but production remains untouched. You can verify the deployment by accessing the staging URL. This step isolates the risk of a bad deployment.
Validate in Staging Slot
Access the staging slot via its unique URL (e.g., https://myapp-staging.azurewebsites.net). Perform smoke tests, functional tests, or load tests. Validate that the app works correctly with the staging slot's settings. If you have slot-specific settings (e.g., a staging database connection string), they are used. This validation ensures that the new version is ready for production. You can also use 'swap with preview' to apply production settings to staging for more accurate validation.
Configure Traffic Splitting (Optional)
If you want to test the new version with a subset of live traffic before full rollout, configure traffic routing. In the portal, go to the production slot's 'Traffic Routing' blade. Set a percentage (e.g., 10%) to the staging slot. The remaining 90% stays on production. Traffic is split at the load balancer using a hash of the client IP to ensure session affinity. This allows you to monitor real user behavior without full commitment. Traffic splitting is additive; you can have multiple slots receiving traffic.
Swap Slots to Production
When ready, perform a swap. In the portal, go to Deployment slots, select the source slot (staging), and click 'Swap'. Choose the target slot (production). The swap process begins: Azure validates slots, applies target settings to source, waits for restart if needed, then swaps VIPs. The entire operation is atomic and should complete within seconds. After swap, the staging slot now holds the old production code, and production runs the new version. You can immediately test production. If issues arise, you can swap back.
Enterprise Scenario 1: E-Commerce Platform with Zero-Downtime Deployments
A large e-commerce company deploys new features weekly. They use deployment slots to ensure zero downtime during peak hours. The production slot serves live traffic. They deploy to a staging slot, run automated Selenium tests, then swap. Because the swap is VIP-level, there is no interruption. They also use auto-swap for minor updates: they deploy to a 'staging' slot with auto-swap enabled to production. This eliminates manual intervention. However, they learned the hard way that if the staging slot fails to warm up (e.g., due to a missing dependency), the swap still proceeds because auto-swap does not check warm-up by default. They now configure a warm-up path and use swap with preview to catch issues. They also mark their database connection strings as slot-specific to avoid pointing production to the staging database after swap.
Enterprise Scenario 2: A/B Testing for a SaaS Application
A SaaS provider wants to test a new UI with 5% of users before full rollout. They deploy the new UI to a 'canary' slot and configure traffic routing: 5% to canary, 95% to production. The load balancer uses client IP hashing to ensure each user consistently sees the same version. They monitor error rates and user feedback. After a few days, they increase the percentage to 50%, then eventually swap fully. This approach minimizes risk. One pitfall: if the canary slot has a bug that causes high CPU usage, it can affect the entire App Service plan because all slots share the same VM resources. They now use a separate App Service plan for the canary slot to isolate resource consumption.
Enterprise Scenario 3: Multi-Region Disaster Recovery
A financial services company runs its app in two Azure regions (East US and West US) for disaster recovery. They use Traffic Manager to route users to the nearest region. Each region has its own App Service with production and staging slots. When deploying updates, they first deploy to staging in East US, validate, then swap. Then they deploy to staging in West US, validate, and swap. This ensures that if a deployment fails, only one region is affected. They also use slot-specific settings to point each slot to the correct regional database. A common mistake is forgetting to update the Traffic Manager endpoint after a swap; however, because the slot hostname remains the same, Traffic Manager continues to work correctly.
What AZ-204 Tests on Deployment Slots and Traffic Splitting
The exam objective 1.3 (Create and manage compute resources) includes 'Manage deployment slots' as a sub-objective. Questions typically appear in scenario-based formats where you must choose the correct deployment strategy. Key areas tested:
Slot-swapping behavior: Know that swapping is VIP swap, not file copy. Understand that sticky settings stay with the slot, non-sticky travel with code.
Auto-swap configuration: When to use it (automated deployments) and its limitations (requires successful deployment, no warm-up check by default).
Traffic splitting: How to route a percentage of traffic to a slot, session affinity via client IP hash, and that traffic splitting is reset after a swap.
Swap with preview: The ability to apply target settings before VIP swap to validate.
Slot limits: Standard: 5 slots, Premium: 20, Isolated: 5.
Common Wrong Answers and Why Candidates Choose Them
'Settings are always swapped with the code': Candidates often think all app settings move with the slot. In reality, only non-sticky settings move; sticky settings stay. They miss the 'slot-specific' checkbox.
'Traffic splitting uses round-robin': Some think traffic is evenly distributed, but it uses client IP hashing for session affinity, not round-robin.
'Auto-swap automatically warms up the slot': Candidates assume auto-swap includes a warm-up check. It does not; you must configure a warm-up path separately.
'Swapping restarts the app': Many think the app restarts during swap. It does not unless sticky settings change that require a restart (like connection strings). The VIP swap itself is seamless.
Specific Numbers and Terms That Appear on the Exam
Maximum number of slots per tier: Standard 5, Premium 20, Isolated 5.
Default warm-up time: 30 seconds.
Traffic splitting percentage range: 0-100, sum must equal 100.
Slot names: 'production' is reserved; you can create slots like 'staging', 'testing', 'canary'.
Command: az webapp deployment slot swap.
Edge Cases and Exceptions
Slots in Free/Shared tiers: Not available. You must scale up to at least Standard.
Function Apps: Slots are available only for Premium plan (not Consumption).
Swap with preview: If you cancel a swap with preview, the settings applied to the source slot are reverted.
Traffic splitting with more than two slots: You can split among multiple slots, but the sum must be 100.
Slot cloning: Only copies settings at creation time; subsequent changes are not synced.
How to Eliminate Wrong Answers
If a question mentions 'zero downtime deployment' and options include 'restart the app' or 'redeploy to production', eliminate those. The correct answer involves slots.
If the question asks about 'keeping production database connection string after swap', look for 'mark as slot-specific' or 'sticky settings'.
If the question involves 'gradually rolling out to 10% of users', look for 'traffic splitting' or 'routing weight'.
Deployment slots are separate, live environments that allow zero-downtime deployments via VIP swap.
Only settings marked as 'slot-specific' (sticky) remain with the slot; all others travel with the code during swap.
Traffic splitting uses client IP hashing for session affinity, not round-robin.
Auto-swap does NOT perform a warm-up check by default; configure a warm-up path separately.
Maximum slots: Standard 5, Premium 20, Isolated 5. Not available in Free/Shared tiers.
Swap with preview applies target settings to source slot before VIP swap, allowing validation.
After a swap, traffic routing weights are reset; you must reconfigure them if needed.
Slots share the same App Service plan resources; consider separate plans for resource isolation.
These come up on the exam all the time. Here's how to tell them apart.
Swap with Preview
Applies target slot's sticky settings to source slot before VIP swap.
Allows you to validate app behavior with production settings while still on staging URL.
You can cancel the swap after preview; settings are reverted.
Useful when you need to test with production database connection strings.
Adds an extra step but reduces risk of configuration mismatches.
Direct Swap
Swaps VIPs directly without applying target settings first.
Faster than swap with preview (one step).
Cannot cancel once initiated.
If settings differ, the app might behave unexpectedly after swap until restarted.
Simpler for routine deployments where settings are identical.
Traffic Splitting
Routes a percentage of live traffic to a non-production slot without swapping.
Allows gradual rollout and A/B testing.
Session affinity ensures same client sees same version.
Does not change which slot is production; production remains the same.
Traffic weights reset after a swap; must be reconfigured.
Full Swap
Moves the entire app from one slot to another atomically.
Results in all traffic hitting the new version immediately.
No session affinity across slots; all clients see the same version.
Changes which slot is considered production.
Settings are swapped appropriately.
Mistake
Deployment slots copy files from staging to production during swap.
Correct
Swap is a VIP swap at the network level. No files are moved. The production slot's VIP is reassigned to the staging slot's instance, and vice versa.
Mistake
All app settings and connection strings are swapped with the code.
Correct
Only settings NOT marked as 'slot-specific' are swapped. Sticky settings stay with the slot. You must explicitly mark production-specific settings as slot-specific.
Mistake
Traffic splitting uses round-robin distribution.
Correct
Traffic splitting uses a hash of the client IP to ensure session affinity. The same client is always routed to the same slot, not round-robin.
Mistake
Auto-swap automatically performs a warm-up check.
Correct
Auto-swap does not perform a warm-up check by default. You must configure a warm-up path (e.g., /warmup) in the App Service settings.
Mistake
You can use deployment slots in Free tier.
Correct
Deployment slots are only available in Standard, Premium, and Isolated tiers. Free and Shared tiers do not support slots.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Sticky settings (slot-specific) remain with the slot when you swap. For example, a production database connection string should be sticky so that after swap, the new code in production still points to the production database. Non-sticky settings travel with the code. If you have a setting that should be the same across all slots (like an API key), leave it non-sticky. In the Azure portal, you mark a setting as 'slot-specific' by checking the 'deployment slot setting' box.
Use traffic splitting. In the Azure portal, go to your App Service, select 'Deployment slots', then 'Traffic routing'. Set a percentage (e.g., 10%) for the staging slot. The remaining traffic goes to production. This uses client IP hashing for session affinity. You can also use the CLI: `az webapp traffic-routing set --name MyApp --resource-group MyRG --distribution staging=10 production=90`.
No, a direct swap cannot be cancelled once initiated. However, if you use 'Swap with preview', you can cancel before the final VIP swap. During the preview phase, the target settings are applied to the source slot, but the VIPs are not swapped. You can then either complete the swap or cancel, which reverts the settings.
Your app restarts during a swap only if the sticky settings that changed require a restart (e.g., connection strings). If no sticky settings change, the swap is seamless. To avoid restarts, ensure that sticky settings are identical between slots or avoid changing them during the swap.
Enable auto-swap on a slot (e.g., staging) and specify the target slot (e.g., production). Every time you deploy to the source slot, Azure automatically swaps it with the target after the deployment is successful. This is useful for CI/CD pipelines. Note: auto-swap does not perform a warm-up check; configure a warm-up path if needed.
Traffic routing weights are reset after a swap. If you had 10% of traffic going to staging before the swap, after swapping, production and staging will have default weights (100% to production, 0% to staging). You must reconfigure traffic routing if you want to continue using it.
Yes, but only with the Premium plan. Consumption plan does not support deployment slots. For Functions, slots work similarly to App Service, allowing you to swap between versions.
You've just covered Deployment Slots and Traffic Splitting — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?