AZ-104 · Deploy and manage Azure compute resources · Updated August 7, 2026

Azure App Service Deployment Slots Explained: Swapping, Sticky Settings, and Swap with Preview

A deployment slot is a live, fully functional copy of an App Service app with its own hostname, running side by side with production. The feature exists to solve one problem: deploying new code without downtime and without gambling on an untested release. But the mechanics behind “swap” trip up a lot of AZ-104 candidates, because a swap isn’t a simple traffic-routing flip. It’s a multi-step operation that restarts instances, applies configuration, and can be paused mid-flight for validation. Understanding those steps, and which settings move with a swap versus which stay pinned to a slot, is most of what the exam is actually testing in this domain.

The tier requirement: Standard or above

Deployment slots require the Standard, Premium, or Isolated tier of an App Service plan. Free, Shared, and Basic tiers don’t support slots at all. This is a common AZ-104 trap: a scenario mentions a Basic-tier app that needs a staging environment, and the correct first step is upgrading the plan, not configuring a slot the current tier can’t create.

Slot count scales with tier too: Standard supports up to 5 slots per app, Premium and Isolated up to 20. If you’re planning to scale an app down to a cheaper tier, confirm the target tier supports at least as many slots as the app already uses, since you can’t scale down below the tier that supports your current slot count. There’s no additional charge for slots themselves; you pay for the App Service plan tier, shared across every slot on that plan.

What a swap actually does

Selecting “swap” between a source slot (say, staging) and a target slot (production) triggers a defined sequence, not an instant cutover:

Azure applies the target slot’s settings (slot-specific app settings, connection strings, and select other configuration) to every instance of the source slot. This restarts all instances in the source slot.
Azure waits for every source-slot instance to finish restarting. If any instance fails to come back, the whole swap is rolled back and stopped.
If local cache is enabled, Azure triggers cache initialization with an HTTP request to the source slot’s root, which can cause another restart.
Azure warms up the source slot: either your custom applicationInitialization warm-up configuration runs, or Azure sends a default HTTP request to the app root and treats any response as “warmed up.”
Once every instance is confirmed warm, Azure swaps the two slots by switching their routing rules. The slot that was source now serves what was previously in the target slot, and vice versa.
The same settings-and-restart cycle then runs on the slot that just received the pre-swap production app, so both slots end up correctly configured.

Because all the risky work (restarting, warming up, validating) happens on the source slot while the target slot keeps serving traffic normally, a swap is designed to produce zero dropped requests and no downtime. If something goes wrong after a swap completes, the fix is simple: swap the same two slots again, since the previous production app is now sitting intact in the other slot.

Sticky settings vs. settings that swap

This is the single most tested distinction in the deployment slots domain. Some configuration follows the app content when you swap; other configuration is “sticky,” meaning it stays attached to the slot itself regardless of what app content lands there.

Settings that swap with the app (they move to wherever the content goes):

Language framework version (.NET, Java, PHP, Python, Node.js)
32-bit vs. 64-bit platform setting
WebSockets enabled/disabled
App settings and connection strings, unless explicitly marked slot-specific
Mounted storage accounts, unless explicitly marked slot-specific
Handler mappings, public certificates, WebJobs content
Hybrid connections, service endpoints, Azure CDN, path mappings

Settings that stay with the slot (sticky by default, they don’t swap):

Publishing endpoints, custom domain names
TLS/SSL certificates and protocol settings (HTTPS Only, TLS version, client certificates)
Scale settings, WebJobs schedulers
IP restrictions, Always On, diagnostic log settings, CORS
Managed identities, virtual network integration

Any app setting or connection string can be flipped from swappable to slot-specific by checking “Deployment slot setting” in the portal (or --slot-settings via CLI). This matters most for environment-specific values: a staging slot’s database connection string should almost always be marked slot-specific, so a swap into production doesn’t push staging’s connection string into the live app. Getting this backwards is a classic cause of a “successful” swap that immediately breaks production.

Swap with preview

A standard swap runs straight through all six steps without pausing. Swap with preview (also called a multi-phase swap) inserts a checkpoint: Azure applies the target slot’s settings to the source slot, restarts and warms it up, and then pauses before actually switching routing. You get a window to validate that the source slot behaves correctly with production’s settings applied, before committing to the traffic switch. From there you either complete the swap or cancel it, which reapplies the source slot’s original configuration.

Swap with preview is unavailable when site authentication is enabled on either slot involved, which is worth remembering as an exam-style exception to an otherwise straightforward feature.

Auto swap and traffic routing

Auto swap automates the whole cycle: enable it on a source slot and point it at a target slot, and every code push to the source slot triggers an automatic swap once warm-up completes, with no manual “swap” click required. It’s built for continuous deployment pipelines aiming for zero-downtime releases, but it isn’t supported on Linux web apps or Web App for Containers.

Separately from swapping, App Service can route a percentage of production traffic to a nonproduction slot, useful for canary testing with a subset of real users before a full swap. A client routed this way is pinned to that slot for about an hour, visible via the x-ms-routing-name cookie. This is distinct from swap with preview: traffic routing splits live production traffic across slots, while swap with preview validates a slot in isolation before it becomes production at all.

How the AZ-104 exam tests this

A scenario describes an app on Basic tier that needs a staging slot: the fix is upgrading to Standard or above, since Basic and lower tiers don’t support slots at all.
A scenario asks how to move a new build into production with zero downtime and full validation beforehand: swap with preview, not a plain swap and not auto swap, since preview is the option that pauses for validation before committing.
A scenario describes a connection string or app setting that should never move to production during a swap: mark it as a slot setting (“Deployment slot setting”/--slot-settings), which makes it sticky to that slot.
A scenario asks why a production TLS certificate or custom domain didn’t change after a swap: those are sticky settings by design, not swapped, so this is expected behavior, not a bug.
A scenario describes wanting every code push to a dev/staging slot to automatically become production once healthy: auto swap, keeping in mind it doesn’t work on Linux apps or Web App for Containers.
A scenario wants to test a new version with a small percentage of live users without fully swapping it into production: automatic traffic routing by percentage, a separate feature from swapping.

Quick reference

Deployment slots require Standard tier or above; Standard supports up to 5 slots, Premium and Isolated up to 20; there’s no extra charge for slots themselves.
A swap is a multi-step operation: apply target settings to the source slot, restart, warm up, then switch routing, then repeat the settings-and-restart cycle on the other slot.
Settings that swap with the app: framework version, platform bitness, WebSockets, app settings/connection strings (unless marked slot-specific), handler mappings, certificates, WebJobs content.
Settings that stick to the slot: custom domains, TLS/certificate settings, scale settings, IP restrictions, Always On, diagnostic logs, CORS, managed identities, VNet integration.
Swap with preview pauses after applying target settings so you can validate before committing; it’s unavailable if site authentication is enabled on either slot.
Auto swap automates the cycle on every push but doesn’t support Linux web apps or Web App for Containers; percentage-based traffic routing is a separate feature from swapping entirely.

For the infrastructure-as-code angle on provisioning App Service plans and slots consistently, see ARM templates vs Bicep. For the full map of AZ-104’s compute, networking, storage, and identity domains, start with the AZ-104 study guide.