This chapter covers App Service deployment slots, a critical feature for zero-downtime deployments in Azure. Deployment slots are a core topic for the AZ-204 exam, appearing in approximately 10-15% of compute-related questions. You will learn how to create, configure, and swap slots, manage traffic routing, and handle slot-specific settings. Mastery of this topic is essential for implementing CI/CD pipelines and blue-green deployments in Azure App Service.
Jump to a section
Imagine a high-end restaurant kitchen where the head chef is preparing a new menu for a tasting event. The kitchen has two identical cooking stations: one is the main line that serves paying customers, and the other is a prep station used for experimentation. The chef wants to test the new menu without disrupting the current service. She sets up the prep station exactly like the main line—same ingredients, same equipment, same plating tools. She cooks the new dishes, tweaks recipes, and validates the taste with a small group of staff. Once satisfied, she needs to swap the prep station with the main line so that the new menu becomes the live offering. But she cannot simply move the food—she must swap the entire station, including all mise en place, utensils, and even the stovetop settings. To do this seamlessly, she warms up the new station (prepares it with hot pans), then at the exact moment of changeover, the team quickly switches the serving window from the old station to the new one. Any orders that were already in progress on the old station are finished from that station (old version), while new orders go to the new station. The old station is then cleaned and can be used for the next menu iteration. This is exactly how deployment slots work: the prep station is the staging slot, the main line is the production slot, and the swap operation is the traffic routing change. The key is that the swap is instantaneous and atomic—no orders are lost, and the kitchen never goes offline.
What Are Deployment Slots?
Deployment slots are live instances of an Azure App Service that run in the same App Service Plan but have their own hostnames and app settings. Each slot can host a different version of your application. The primary slot is called the "production" slot, and you can create additional slots (e.g., "staging", "testing") to validate changes before routing traffic to production.
Why Use Deployment Slots?
The primary benefit is zero-downtime deployments. You can deploy a new version to a non-production slot, warm it up, test it, and then swap it into production. The swap operation is instantaneous and does not drop any existing requests. This enables blue-green deployment patterns, A/B testing, and staging environments without additional cost (slots share the same App Service Plan).
How Slots Work Internally
Each slot is a full-fledged App Service with its own:
Hostname: <slotname>-<appname>.azurewebsites.net
Application settings (appsettings.json, Connection Strings, etc.)
Deployment history
Authentication/authorization configuration
Custom domains (can be assigned per slot)
When you swap slots, Azure performs the following steps: 1. Validate settings: Ensures that slot-specific settings (marked as "slot settings") are correctly identified. Non-slot settings are copied from source to target. 2. Warm up the source slot: The source slot (e.g., staging) is warmed up by making requests to its root URL. This ensures the application is responsive before accepting production traffic. 3. Swap routing rules: Azure updates the internal routing so that the production hostname points to the source slot, and the staging hostname points to the target slot. This is an atomic operation at the Azure Front Door / load balancer level. 4. Post-swap cleanup: The old production slot (now staging) may be automatically cleaned up if configured, but usually it remains as a backup.
Slot-Specific Settings
Some settings are "sticky" to a slot—they do not travel with the swap. These are called slot settings (deployment slot settings). They include:
Connection strings (if marked as slot setting)
App settings (if marked as slot setting)
Custom domain bindings
TLS/SSL certificates
WebJobs (some types)
Continuous deployment settings
Authentication/Azure AD settings
Monitoring settings (e.g., Application Insights instrumentation key)
You mark a setting as slot-specific in the Azure Portal under Configuration > General Settings > "Deployment Slot Settings" or via CLI with the --slot-settings flag.
Traffic Routing and Auto-Swap
You can route a percentage of traffic to a slot without swapping. This is called traffic routing or testing in production. For example, you can send 10% of requests to the staging slot while 90% goes to production. This is configured in the Azure Portal under Deployment Slots > slot > Traffic %. This uses cookie-based affinity: a cookie named ARRAffinity is set to ensure a user session stays on the same slot.
Auto-swap is a feature that automatically swaps a slot into production after a successful deployment from a source control provider (like GitHub Actions or Azure DevOps). You enable auto-swap by setting the autoSwapSlotName property on the source slot.
Key Values, Defaults, and Timers
Default number of slots: Up to 5 (including production) for Standard plan, up to 20 for Premium plan.
Warm-up time: The swap operation waits for the source slot to respond to HTTP requests. The default warm-up path is /. You can configure a custom warm-up path via WEBSITE_SWAP_WARMUP_PING_PATH and WEBSITE_SWAP_WARMUP_PING_STATUSES app settings.
Swap timeout: The swap operation times out after 90 minutes by default. If the warm-up fails, the swap is rolled back.
Traffic routing percentage: Must be an integer between 0 and 100.
Cookie affinity: The ARRAffinity cookie is used for routing; it is set on the client's first request.
Configuration and Verification Commands
Using Azure CLI:
# Create a slot
az webapp deployment slot create --name <app-name> --resource-group <rg> --slot staging
# Deploy to slot (via ZIP deploy)
az webapp deployment source config-zip --name <app-name> --resource-group <rg> --slot staging --src <zip-file>
# Swap slots
az webapp deployment slot swap --name <app-name> --resource-group <rg> --slot staging --target-slot production
# List slots
az webapp deployment slot list --name <app-name> --resource-group <rg>
# Configure slot-specific settings
az webapp config appsettings set --name <app-name> --resource-group <rg> --slot staging --settings "DB_CONN=Server=..." --slot-settings "API_KEY=..."
# Set traffic routing
az webapp traffic-routing set --name <app-name> --resource-group <rg> --distribution staging=10Verification:
Browse to https://<slotname>-<appname>.azurewebsites.net to see the slot content.
After swap, the production URL shows the new version.
Use az webapp deployment slot list to see the current slot status.
Interaction with Related Technologies
Azure DevOps / GitHub Actions: Slots are integral to CI/CD pipelines. The deployment task can deploy to a slot and then swap.
App Service Plan: Slots share the same plan, so scaling the plan scales all slots. However, slots can have different instance counts? No, they share the same underlying VMs. But you can scale the plan to handle more load.
Traffic Manager / Front Door: You can use slots for regional deployment and then use Traffic Manager to route users to the correct region. Slots themselves are per-region.
Application Insights: Slot-specific instrumentation keys allow you to monitor each slot separately.
Common Pitfalls
Not marking settings as slot-specific: If you have a database connection string that differs between staging and production, you must mark it as a slot setting. Otherwise, the swap will copy the production connection string to staging, causing staging to point to production database.
Warm-up failures: If your application takes too long to warm up or returns a non-200 status, the swap may fail. Configure custom warm-up path and status codes.
Cookie-based routing: Traffic routing uses cookies, so if a user's browser clears cookies, they may be routed to a different slot mid-session.
Auto-swap with failing deployments: If auto-swap is enabled and a deployment fails, the swap still happens, potentially breaking production. Use deployment gates to validate before auto-swap.
Advanced: Swap with VNet Integration
If your app is VNet-integrated, the slot settings include VNet routing. During swap, the VNet association stays with the slot, so ensure both slots have the correct VNet configuration if needed.
Summary
Deployment slots provide a powerful mechanism for zero-downtime deployments, staging environments, and traffic routing. Understanding slot settings, warm-up, and swap mechanics is crucial for the AZ-204 exam and real-world Azure development.
Create a staging slot
Using the Azure Portal, CLI, or PowerShell, create a new deployment slot named 'staging' under your App Service. This slot is an independent instance with its own hostname (staging-<app>.azurewebsites.net). It shares the same App Service Plan and underlying VMs as the production slot. The slot starts empty (no deployed code) until you deploy to it. You can also clone settings from the production slot during creation, but cloning is optional. The slot is immediately accessible and can be configured with its own app settings, connection strings, and other configuration.
Deploy application to staging
Deploy your new application version to the staging slot using any deployment method: ZIP deploy, FTP, Git, Azure DevOps, GitHub Actions, etc. For example, using Azure CLI: `az webapp deployment source config-zip --name <app> --resource-group <rg> --slot staging --src myapp.zip`. The deployment is isolated from production; users accessing the production URL do not see this version. You can verify the deployment by browsing to the staging slot's URL. At this point, you can run tests, validate configurations, and perform smoke tests without affecting live users.
Configure slot-specific settings
Identify which application settings and connection strings should remain with the slot (i.e., not travel during a swap). Mark these as 'deployment slot settings' in the Azure Portal under Configuration > General Settings, or use the `--slot-settings` flag in CLI. Common slot-specific settings include database connection strings for staging vs. production, API keys for external services, and environment-specific variables (e.g., `ASPNETCORE_ENVIRONMENT`). Settings that are not marked as slot-specific will be copied from the source slot to the target slot during a swap. This is critical: if you forget to mark a setting as slot-specific, a swap will overwrite the production value with the staging value, potentially causing an outage.
Perform slot swap
Initiate a swap between the staging and production slots. This can be done via Azure Portal (Deployment Slots > Swap), CLI (`az webapp deployment slot swap`), or automation. The swap process: (1) Azure validates that the source slot (staging) has the necessary slot settings marked. (2) Azure warms up the source slot by making HTTP requests to its root URL (or custom warm-up path) until it receives a successful response (default 200-299). (3) Azure atomically swaps the routing rules: the production hostname now points to the staging slot's instance, and the staging hostname points to the old production instance. (4) The old production slot (now staging) is kept as a backup. The entire operation typically takes a few seconds to minutes, depending on warm-up time. During the swap, there is no downtime; existing requests are completed on the original slot before the swap finalizes.
Verify and optionally rollback
After the swap, verify that the production URL serves the new version. Monitor application logs, performance metrics, and error rates. If issues are detected, you can perform a swap back (swap staging and production again) to revert to the previous version. This is a quick rollback mechanism. Note that the swap back will also swap slot settings, so if you changed slot settings during the first swap, they will revert. For complex rollbacks, you may need to redeploy the old version to a slot and swap again. Also, consider using traffic routing to gradually shift traffic to the new slot before a full swap, allowing you to monitor performance with a small user segment.
Enterprise Scenario 1: E-Commerce Platform with Blue-Green Deployments
A large e-commerce company uses Azure App Service to host its customer-facing website. They have a Standard tier App Service Plan with 3 instances to handle peak traffic. They create two slots: production and staging. Every sprint, developers deploy the new build to the staging slot. The staging slot is configured with a staging database (slot-specific connection string) and a staging Redis cache. Before swap, automated integration tests run against the staging URL. Once tests pass, the operations team schedules a swap during low traffic hours. The swap takes about 30 seconds, during which the site remains fully responsive. After swap, they monitor for 15 minutes. If error rates spike, they swap back. This process has reduced deployment-related incidents by 90%.
Enterprise Scenario 2: A/B Testing with Traffic Routing
A media company wants to test a new recommendation algorithm on a subset of users. They deploy the new algorithm to a slot called 'test'. They configure traffic routing to send 5% of production traffic to the test slot. The routing uses cookie-based affinity, so users who land on the test slot stay there for the duration of their session. They monitor user engagement metrics via Application Insights, which is configured with a slot-specific instrumentation key. After two weeks, the data shows a 10% increase in click-through rates, so they perform a full swap to make the new algorithm the default. The challenge they faced was that some users reported inconsistent experiences because their browsers cleared cookies mid-session, causing them to switch between slots. They mitigated this by setting a longer cookie expiration and using server-side session storage.
Enterprise Scenario 3: Multi-Region Deployment with Traffic Manager
A global SaaS provider deploys its App Service in two regions: West US and East US. Each region has its own App Service with production and staging slots. They use Azure Traffic Manager to route users to the nearest region. When deploying a new version, they first deploy to staging in East US, swap, then deploy to staging in West US, and swap. During the swap in one region, Traffic Manager automatically routes users to the other region if health probes fail. They encountered an issue where the warm-up path was not configured, causing the swap to fail because the staging app returned a 503 during initialization. They fixed this by setting a custom warm-up path (/health) that returns 200 only after the app is fully ready. They also set WEBSITE_SWAP_WARMUP_PING_STATUSES to 200,301,302 to allow redirects during warm-up.
What AZ-204 Tests on Deployment Slots
AZ-204 exam objective: "Implement Azure App Service web apps" (15-20% of exam). Within that, deployment slots are a key sub-objective. You should expect questions on:
Creating and managing slots (including CLI commands)
Slot swap behavior and warm-up
Slot-specific settings vs. non-slot settings
Traffic routing and auto-swap
Rollback strategies
Common Wrong Answers and Why Candidates Choose Them
"Slot settings travel with the swap": Many candidates think all settings are swapped. In reality, only non-slot settings are swapped. Slot settings stay with the slot. This is the #1 trap.
"You can swap slots without warm-up": The exam tests that Azure automatically warms up the source slot before swap. Some candidates think warm-up is optional or that it's the developer's responsibility.
"Traffic routing uses IP-based affinity": Actually, it uses cookie-based affinity (ARRAffinity cookie). Candidates may assume IP-based because of other Azure load balancing features.
"Auto-swap happens immediately on successful deployment": Auto-swap occurs after a successful deployment from source control, but it also respects warm-up. Candidates may think it's instantaneous.
Specific Numbers and Terms on the Exam
Maximum slots: 5 (Standard), 20 (Premium)
Swap timeout: 90 minutes
Default warm-up path: /
Warm-up status codes: 200-299 by default (configurable via WEBSITE_SWAP_WARMUP_PING_STATUSES)
Traffic routing percentage: integer 0-100
Slot setting marker: --slot-settings in CLI, "Deployment Slot Settings" in portal
Edge Cases and Exceptions
Swap with VNet integration: If your app is VNet-integrated, the VNet association is a slot setting. During swap, the VNet does not change. Ensure both slots have appropriate VNet configurations if needed.
Swap with authentication: If you use Azure AD authentication, the authentication settings are slot-specific by default. Swapping may cause authentication failures if the slots have different app registrations.
Swap with custom domains: Custom domains are assigned to slots. If you have a custom domain on production, after swap, the domain remains with the slot (production slot), so it still works. But if you want the domain to follow the app, you must not mark it as slot-specific? Actually, custom domains are always slot-specific; they are not swapped. So the production slot keeps its custom domain.
Swap with WebJobs: Continuous WebJobs are slot-specific; they are not swapped. Triggered WebJobs are not slot-specific? Actually, WebJobs are part of the app and are swapped. However, continuous WebJobs have a setting to run on a specific slot; you can configure them to run on all slots or only on the production slot.
How to Eliminate Wrong Answers
If a question asks about settings that should not change during a swap, look for "slot-specific" or "deployment slot setting".
If a question involves routing traffic to a slot, look for "cookie-based affinity" or "ARRAffinity".
If a question asks about warm-up, remember that Azure automatically pings the root URL (or custom path) and waits for a success status.
For rollback, the fastest method is to swap back. Redeploying is slower.
For auto-swap, the source slot must have auto-swap enabled, and the deployment must be from a source control provider.
Deployment slots enable zero-downtime deployments by swapping staging and production slots.
Slot-specific settings (e.g., connection strings) must be explicitly marked to remain with the slot during a swap.
Azure automatically warms up the source slot before swap by pinging the root URL (or custom path).
Traffic routing uses cookie-based affinity (ARRAffinity) to send a percentage of users to a specific slot.
Auto-swap automates the swap after a successful deployment from a source control provider.
Maximum slots: 5 for Standard plan, 20 for Premium plan.
Swap can be rolled back by performing another swap (swap back).
Warm-up path and acceptable status codes are configurable via app settings (WEBSITE_SWAP_WARMUP_PING_PATH, WEBSITE_SWAP_WARMUP_PING_STATUSES).
Custom domains and TLS certificates are slot-specific; they do not swap.
Continuous WebJobs are slot-specific; triggered WebJobs are swapped.
These come up on the exam all the time. Here's how to tell them apart.
Deployment Slots (Azure App Service)
Native to Azure App Service, no extra infrastructure needed.
Automatic warm-up and atomic swap built-in.
Supports traffic routing (percentage-based) for A/B testing.
Slot-specific settings prevent configuration leaks.
Limited to 5-20 slots based on plan tier.
Blue-Green Deployment (Manual or Other Tools)
Requires separate infrastructure (e.g., two App Services, load balancer).
Manual warm-up and routing update; no atomic swap guarantee.
Traffic routing typically requires external load balancer (e.g., Traffic Manager).
Configuration management must be handled manually (e.g., environment variables).
Virtually unlimited number of environments if using separate App Services, but cost scales.
Mistake
All app settings are swapped during a slot swap.
Correct
Only settings that are NOT marked as slot settings are swapped. Slot-specific settings (marked in portal or via --slot-settings) remain with the slot and are not copied to the target slot.
Mistake
You can have unlimited deployment slots.
Correct
The number of slots is limited by the App Service Plan tier: Standard allows up to 5 slots (including production), Premium allows up to 20. Free and Shared tiers do not support slots.
Mistake
Slot swap is instantaneous and requires no warm-up.
Correct
Azure automatically warms up the source slot by sending HTTP requests to the root URL (or custom warm-up path) until a successful response is received. This can take time and may fail if the app is slow.
Mistake
Traffic routing uses IP-based affinity to keep users on the same slot.
Correct
Traffic routing uses cookie-based affinity via the ARRAffinity cookie. The cookie is set on the client's first request and ensures subsequent requests are routed to the same slot.
Mistake
Auto-swap occurs immediately after a deployment completes.
Correct
Auto-swap occurs after a successful deployment from a source control provider, but it still goes through the standard swap process including warm-up. The swap is not instantaneous; it depends on warm-up time.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use the `--slot-settings` flag when setting the app setting. For example: `az webapp config appsettings set --name myapp --resource-group myrg --slot staging --settings "DB_CONN=Server=..." --slot-settings "API_KEY=..."`. This ensures `API_KEY` stays with the staging slot during a swap. In the portal, you mark settings as slot settings under Configuration > General Settings > Deployment Slot Settings.
If the source slot fails to respond with a successful HTTP status (default 200-299) within the warm-up period (default 90 minutes), the swap operation fails and is rolled back. The production slot remains unchanged. You can configure a custom warm-up path and acceptable status codes via `WEBSITE_SWAP_WARMUP_PING_PATH` and `WEBSITE_SWAP_WARMUP_PING_STATUSES` app settings.
No. Deployment slots are only available on Standard, Premium, and Isolated tiers. Free and Shared plans do not support slots. You must scale up your App Service Plan to at least Standard to use slots.
Traffic routing allows you to send a percentage of incoming requests to a non-production slot without swapping. It uses cookie-based affinity: the Azure load balancer sets an `ARRAffinity` cookie on the first request to determine which slot the user should be routed to. Subsequent requests from the same user (with the cookie) are sent to the same slot. You configure the percentage in the portal under Deployment Slots > slot > Traffic % or via CLI with `az webapp traffic-routing set`.
Auto-swap automatically triggers a swap from a source slot (e.g., staging) to the target slot (e.g., production) after a successful deployment from a source control provider (like GitHub or Azure DevOps). Manual swap is initiated manually via portal, CLI, or API. Both perform the same swap process including warm-up. Auto-swap is convenient for CI/CD pipelines but requires careful configuration to avoid swapping a failing deployment.
To roll back, perform another swap between the same two slots (swap staging and production again). This effectively reverts the application to the previous version. Note that slot-specific settings will also be swapped back if they were not changed. If you need to roll back to an older version, you can deploy the old code to a slot and swap again.
No. Custom domains are slot-specific settings. They remain bound to the slot they are assigned to. So if you have a custom domain bound to the production slot, after a swap, the production slot (now running the new code) still has the domain. The staging slot retains its default hostname. This is intentional to avoid DNS propagation delays.
You've just covered App Service Deployment Slots — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?