# Deployment slot

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/deployment-slot

## Quick definition

Deployment slots are separate environments within Azure App Service where you can host different versions of your app. You can test changes in a staging slot, then swap it with the production slot. This helps avoid downtime and makes updates safer. Slot swapping also moves configuration settings as needed.

## Simple meaning

Imagine you run a restaurant and you want to try a new menu. You wouldn’t immediately replace the old menu for all customers. Instead, you might test the new menu on a single table of guests first. Deployment slots work like that for websites or web apps. Azure App Service lets you create a “staging slot” alongside your “production slot.” You deploy your new code or changes to the staging slot while the live site stays on the production slot. Users keep using the old version without interruption. You can test everything in staging, check for errors, verify performance, and make sure the new features work as expected. When you are satisfied, you can “swap” the slots. This means the staging slot becomes the new production slot, and the old production slot becomes the staging slot. The swap happens very quickly, often in seconds, so visitors experience no downtime. If something goes wrong after the swap, you can swap back immediately. This makes deployments much safer. Slot swapping also handles configuration settings intelligently. Some settings “stick” to each slot (like database connection strings for staging) while others move with the app during swap. This means you can have different environment-specific settings without manually changing them. Deployment slots are a core feature for continuous delivery and DevOps practices, especially in Azure. They help teams release updates more frequently and with less risk. Instead of a big stressful launch, you can do small, safe swaps whenever you need. It’s like having a backup plan built right into your hosting environment.

The concept is not unique to Azure, but Azure App Service makes it very easy. Other platforms like AWS Elastic Beanstalk and Kubernetes have similar ideas with blue-green deployments. Deployment slots are the Azure-specific way to achieve zero-downtime deployments. They are a key tool for IT professionals who manage cloud applications.

In short, deployment slots let you stage, test, and swap your app versions safely and quickly, with automatic handling of environment-specific settings. This makes your deployment process smoother and your application more reliable.

## Technical definition

In Microsoft Azure App Service, a deployment slot is a live, independently running instance of a web app, API app, or mobile app backend that runs in the same App Service plan as the production slot. Each slot has its own hostname, app settings, connection strings, and deployment artifacts. The primary slot is called the “production slot” and is the default endpoint users reach. When you create additional slots (e.g., “staging”, “testing”), they are separate deployments that can be used for validation, A/B testing, or blue-green deployment strategies.

From a technical perspective, slot swapping is the core operation. When you swap two slots, Azure App Service performs a series of steps to ensure a smooth transition. First, it validates that the target slot (usually staging) is healthy and that configuration references are correct. Then it applies the slot-specific configuration settings from the source slot (production) to the target slot before the actual swap. This includes connection strings, app settings, and other environment-specific values. Next, Azure reroutes traffic from the source slot to the target slot. This routing change is done at the front-end load balancer level, so client connections are redirected. The swap operation also handles sticky session cookies (ARR affinity) and custom domain bindings. After the swap is complete, the former production slot becomes the staging slot with its previous configuration preserved. This allows an immediate rollback if issues arise.

Slot swapping supports several configuration categories. “Slot-specific settings” are marked as “sticky” and remain with the slot after a swap. These include connection strings (e.g., database, storage), app settings (e.g., API keys, feature flags), certificate thumbprints, and virtual network integrations. Settings that are not slot-specific move with the app during swap, such as logging settings, custom domains, and certain framework configurations. This design allows developers to maintain different environment configurations without manual editing.

Deployment slots also integrate with Azure DevOps, GitHub Actions, and other CI/CD pipelines. You can automatically deploy to a staging slot from a build pipeline, run integration tests, and then trigger a swap to production. The “auto swap” feature even allows Azure to automatically swap a slot into production when a deployment is successful, provided certain health checks pass.

all slots share the same App Service plan, meaning they consume resources (CPU, memory, disk) from the same pool. Having multiple slots increases resource usage and costs if they are running simultaneously. In a production environment, you typically have one staging slot and one production slot, but you can have up to 20 slots depending on the App Service plan tier (e.g., Standard, Premium). The Free and Shared tiers do not support deployment slots. For high-traffic apps, you should also consider advanced staging environments like deployment slots with traffic routing (A/B testing) where you can direct a percentage of users to a specific slot without a full swap.

Finally, deployment slots are a key enabler for continuous delivery and DevOps practices, particularly for exams like AZ-400 (Microsoft DevOps Solutions) and AZ-104 (Microsoft Azure Administrator). They reduce deployment risk, support rollback, and simplify environment management.

## Real-life example

Think of a large electronics store that has a main showroom floor and a back testing room. The main showroom is where customers walk in, browse products, and make purchases. The back testing room is where staff set up new displays, test demo units, and train employees. When a new product version arrives, the staff does not immediately replace the showroom display. Instead, they first set up the new version in the back testing room. They run tests, check that all features work, and see how customers react during a private preview. Only after everything is confirmed working do they move the new display to the main showroom. They simply swap the entire display case, the old one goes to the back room, the new one takes its place. Customers see the new product instantly, without any interruption to the store’s operations. If a problem is discovered after the swap, they can move the old display back to the showroom quickly.

In this analogy, the main showroom is the production slot. The back testing room is the staging slot. The product display is your web application. The swap is the slot swap operation. The store employees are the DevOps team. The customers are your end users. The store benefits because they can test thoroughly without affecting the customer experience. If the new display is flawed, they revert in seconds. This is exactly how deployment slots work in Azure App Service. You deploy new code to a staging slot, test it in an environment identical to production, then swap when ready. The swap is nearly instantaneous, and traffic moves to the new version. If needed, you can swap back immediately. This real-life example shows why deployment slots are so powerful for reducing risk and maintaining high availability during updates.

slot-specific settings are like store policies that stay with each room. For instance, the back room might have special employee-only signage and security settings, while the main showroom has customer-facing signs. When you swap displays, you want the customer-facing signs to stay on the main showroom, not move with the display. Slot-specific settings ensure those environment-specific configurations stay where they belong.

## Why it matters

Deployment slots matter because they directly address one of the biggest challenges in IT operations: how to deploy new software versions without causing downtime or breaking the user experience. In a world where users expect 24/7 availability, even a few seconds of downtime can mean lost revenue, frustrated customers, and damage to brand reputation. Deployment slots eliminate the need for maintenance windows for simple updates. The swap happens in seconds, and users are never redirected to a down page. This is a fundamental shift from traditional deployment methods where you would stop the app, upload files, and restart.

Beyond zero-downtime deployments, deployment slots enable safer releases. Because you can test in an environment that is identical to production (same hosting plan, same configuration framework), you catch environment-specific issues before they affect real users. For example, a bug that only appears under production load can be detected in the staging slot because it shares the same hardware resources. This reduces the number of post-deployment incidents. The ability to swap back instantly provides a safety net. If a deployment introduces a critical bug, you do not need to rebuild and redeploy the old version. You simply swap the slots back, restoring the previous version in seconds. This dramatically lowers the risk of deploying frequently.

For IT teams practicing continuous integration and continuous delivery (CI/CD), deployment slots are a must-have. They integrate smoothly with Azure Pipelines, GitHub Actions, and other CI/CD tools. You can set up a pipeline that deploys to a staging slot, runs automated tests, and then automatically swaps to production if tests pass. This enables fully automated, frequent releases with minimal human oversight. It also supports advanced patterns like blue-green deployments and canary releases when combined with traffic routing.

From a cost perspective, deployment slots are efficient because they share the same App Service plan. You do not pay for a separate hosting environment. The only extra cost is the additional resource consumption when multiple slots are running. This makes them accessible even for small teams. In exam contexts like AZ-104 and AZ-400, understanding deployment slots is critical because they appear in questions about high availability, disaster recovery, and release management. They are a core feature that differentiates Azure App Service from simpler hosting options. Ultimately, deployment slots give IT professionals confidence in their release process, which is invaluable in modern cloud environments.

## Why it matters in exams

Deployment slots are a heavily tested concept in both the AZ-104 (Microsoft Azure Administrator) and AZ-400 (Microsoft DevOps Solutions) exams. In AZ-104, deployment slots fall under the “Configure and manage Azure App Service” objective, which is a major domain. Questions often ask about how to enable deployment slots, how to configure slot-specific settings, and the effect of swapping on custom domains and SSL certificates. You should know which App Service plan tiers support deployment slots (Standard and above) and the maximum number of slots per plan. You may also be asked about scenarios where you need to stage an update with zero downtime, and the correct answer will involve creating a staging slot, deploying to it, and swapping. Another common AZ-104 question type involves troubleshooting a swap failure due to a slot setting being marked as sticky incorrectly, or because of a health check issue. Understanding that slot-specific settings (connection strings, app settings marked as slot settings) remain with the slot after swap is crucial. You should also know how to enable auto swap and the health check path.

In AZ-400, deployment slots are even more central because the exam focuses on release strategies and continuous delivery. You will see questions about blue-green deployments, canary releases, and how deployment slots implement these patterns. For instance, you may be asked to design a release pipeline that uses deployment slots to minimize impact of new releases. You need to understand how to configure the swap with traffic routing (e.g., send 10% of users to staging slot for testing). Slot swapping is the Azure-native way to achieve zero-downtime deployments. The exam also covers integration with Azure Pipelines: how to set up a pipeline that deploys to a staging slot, runs smoke tests, and then performs a swap. You might be asked to decide whether to use deployment slots or other methods like Azure Traffic Manager or Azure Load Balancer for a particular scenario. Another common topic is rollback strategies using deployment slots. Knowing that after a swap, you can swap back immediately is a key point.

In both exams, multiple-choice and scenario-based questions are common. You might be presented with a situation: “Your company wants to deploy a new version of an app with zero downtime. The app runs on Azure App Service. You need to recommend a solution.” The correct answer will involve deployment slots. Alternatively, a troubleshooting question may describe a failed swap because the health check endpoint returned 500 errors. You need to know that the slot swap will abort if health checks fail. There are also questions about sticky settings: “You deploy a new version to staging but the database connection string for staging is used in production after swap. What went wrong?” The answer is that the connection string was not marked as a slot setting. Understanding these nuances is essential for exam success. Deployment slots are not just a nice-to-know feature; they are a core part of the Azure DevOps toolkit. I highly recommend practical labs with slot swaps to solidify the concepts.

Finally, exam objectives often list deployment slots under “Implement a container-based continuous deployment” or “Manage Azure App Service”. Check the official exam study guides for exact details. But definitely allocate study time to this topic.

## How it appears in exam questions

Exam questions about deployment slots typically fall into three patterns: scenario-based decision questions, configuration questions, and troubleshooting questions. In scenario-based questions, you are given a business requirement and must choose the appropriate Azure feature. For example: “Your company has a web app hosted in Azure App Service. You need to deploy updates with zero downtime. You also need to be able to roll back quickly if the update fails. Which feature should you use?” The answer is deployment slots. The distractors might include Azure Traffic Manager, Azure Load Balancer, or simply redeploying the old version. Understanding that deployment slots provide built-in zero-downtime swap and instant rollback is key.

Configuration questions test your knowledge of slot settings. A typical question: “You have a web app with a staging slot. The staging slot uses a different database for testing. After a swap, the production app is using the staging database. What is the likely cause?” The answer: The database connection string was not marked as a slot-specific (sticky) setting. This means it moved with the app during swap. You need to remember that only settings explicitly marked as slot settings stay with the slot. Another configuration question: “You want to allow automated swaps when a deployment to staging succeeds. Which feature should you enable?” Answer: Auto swap. You also need to know that auto swap requires a health check path to be defined.

Troubleshooting questions often involve swap failures. For instance: “When attempting to swap slots, the operation fails with a health check error. The health check endpoint is configured correctly. What could be the issue?” Possible causes include: the staging slot is not in a healthy state (e.g., 500 errors), the health check path returns unexpected status codes, or the staging slot’s configuration is invalid. Another troubleshooting scenario: “After a swap, users report intermittent 503 errors. What is the most likely cause?” This could be due to ARR affinity (sticky sessions) where user sessions are lost after the swap, or because the application requires a warm-up period. You might need to configure the “application warm-up” feature or ensure that your app handles session state appropriately.

You might also see questions about the limitations of deployment slots. For example: “You are on a Free tier App Service plan. Can you use deployment slots?” The answer is no. The Standard tier or higher is required. Another limitation: “How many deployment slots can you have for a Premium tier App Service?” The answer is up to 20. For Standard, it’s 5. Knowing these numbers is helpful. Also, remember that all slots share the same App Service plan resources, so running too many slots can impact performance.

Finally, there are questions about traffic routing with slots. For example: “You want to test a new feature with a small subset of users without swapping slots. What should you configure?” Answer: Use the “Routing rules” feature to direct a percentage of traffic to a specific slot (canary release). This is different from a full swap. Understanding the difference between swapping and traffic routing is important.

to ace deployment slot questions, focus on: when to use slots vs other services, how to mark sticky settings, auto swap configuration, health check requirements, plan tier limitations, and troubleshooting common swap issues.

## Example scenario

A medium-sized e-commerce company runs a web application on Azure App Service. The application handles product listings, shopping carts, and checkout. The development team releases a new feature that improves the checkout flow. The team wants to roll out the feature without causing any downtime, because even a minute of downtime could cost thousands in lost sales. The team also wants the ability to revert quickly if customers encounter issues.

The team creates a new deployment slot named “staging” in the same App Service plan. They deploy the new code to the staging slot. The staging slot has its own database connection string pointing to a test database. This connection string is marked as a “slot-specific” setting so that it stays with the staging slot even after a swap. The production slot continues to use the live database. The team runs automated tests against the staging slot and performs manual testing. They verify that the new checkout flow works correctly with the test data.

After testing passes, the team initiates a slot swap. Azure quickly exchanges the traffic routing between the two slots. Users now see the new checkout flow with zero downtime. The old version is now in the staging slot. The team monitors the production application for errors. After a few hours, they notice a subtle bug that only appears with real shopping cart data. The bug is not critical but could confuse some users. The team decides to roll back. They perform another swap, sending the old version back to production. Again, the swap happens in seconds with no downtime. The bug is fixed in the development environment, and a new deployment to staging is queued.

This scenario demonstrates the key benefits: zero-downtime deployment, safe testing in an identical environment, slot-specific settings, and instant rollback capability. The team can deploy more frequently because the risk is low. Customers never experienced an outage or a broken page. The entire process is handled through the Azure portal or via CLI/PowerShell commands. This scenario is typical for both AZ-104 and AZ-400 exam questions. In the exam, you might be asked to design this exact solution or troubleshoot a similar situation.

The scenario also highlights a common mistake: forgetting to mark the database connection string as a slot setting. If the team had not marked it, after the first swap the production app would try to use the test database, causing data corruption and outages. This mistake is a classic exam trap. Always remember to identify which settings should be slot-specific (sticky) and which should move with the app.

## Common mistakes

- **Mistake:** Assuming all settings move with the slot during a swap.
  - Why it is wrong: Azure has a concept of slot-specific settings (sticky settings). If you do not explicitly mark a connection string or app setting as a slot setting, it will move with the app during a swap. This can cause the production app to suddenly use staging database credentials, leading to data corruption or access issues.
  - Fix: Always mark environment-specific configurations like database connection strings, API keys for test services, and feature flags that differ between environments as slot-specific settings. Use the Azure portal, CLI, or ARM templates to set the “slot setting” flag to true.
- **Mistake:** Thinking all App Service plans support deployment slots.
  - Why it is wrong: Deployment slots are only available on Standard, Premium, PremiumV2, PremiumV3, and Isolated tiers. Free and Shared tiers do not support slots. Learners often try to create a slot on a Free plan and wonder why the option is grayed out.
  - Fix: Verify your App Service plan tier before planning to use slots. If you need slots, upgrade the plan to at least Standard. For exam questions, remember that the Free and Shared tiers are excluded.
- **Mistake:** Believing that swapping slots causes downtime.
  - Why it is wrong: Slot swapping is designed to be a zero-downtime operation. Azure handles the traffic routing at the load balancer level, and the swap occurs in seconds. However, if your application has long-running tasks or relies on sticky sessions without proper handling, users may experience brief disconnects. The swap itself does not take the app offline.
  - Fix: Understand that the swap operation itself does not stop the application. For exam scenarios, always choose deployment slots when the requirement is zero-downtime deployment. Consider session affinity and warm-up if you have stateful apps.
- **Mistake:** Forgetting that health checks can block a swap.
  - Why it is wrong: Azure App Service can be configured with a health check path. Before a swap, Azure validates that the target slot (staging) responds with a healthy HTTP status (2xx) on that path. If the health check fails, the swap is aborted. Learners often ignore this and wonder why their swap fails without explanation.
  - Fix: Always configure a health check endpoint in your application and point Azure to it. Ensure the staging slot returns a 200 OK even if it is not fully functional. In exam troubleshooting, if a swap fails, suspect the health check first.
- **Mistake:** Thinking you can have an unlimited number of slots.
  - Why it is wrong: The number of deployment slots is limited by the App Service plan tier. Standard allows up to 5 slots (including production), Premium allows up to 20. Learners sometimes try to create dozens of slots and hit the limit.
  - Fix: Remember the slot limits by tier. For Standard: 5 total (production + 4 additional). For Premium: 20 total. For exam questions, if a scenario mentions many environments, check if the plan supports it.
- **Mistake:** Confusing deployment slots with Azure Traffic Manager or Load Balancer.
  - Why it is wrong: Deployment slots are a feature of Azure App Service, not a separate load balancing service. Traffic Manager and Load Balancer distribute traffic across multiple VM instances or regions. Slots swap the entire app environment within the same App Service plan. Learners often choose Traffic Manager when the question is about zero-downtime deployment within a single app.
  - Fix: If the requirement is to deploy new versions of a single app with zero downtime and rollback, the answer is deployment slots. Traffic Manager is for multi-region routing. Load Balancer is for VMs. Know the distinct use cases.

## Exam trap

{"trap":"A candidate sees a question: \"You deploy a new version of your app to the staging slot. The staging slot uses a different test database. You swap the slots. After the swap, the production app shows errors because it cannot connect to the database. What is the most likely cause?\" A wrong answer choice might be \"The production database was down.\"","why_learners_choose_it":"Learners may assume the problem is external (database failure) because they think the swap is flawless. They may not fully understand that settings like connection strings can move between slots unless marked as slot-specific. They also may not realize that the staging database connection string was not marked as a slot setting, so it moved to production after swap.","how_to_avoid_it":"Always remember that only settings explicitly marked as slot-specific (sticky) stay with the slot. When you swap, non-sticky settings move with the app. The fix is to mark the test database connection string as a slot-specific setting in the staging slot. This way, after the swap, the production slot uses its original production connection string. For the exam, read carefully: if any configuration is environment-specific, it should be a slot setting."}

## Commonly confused with

- **Deployment slot vs Blue-green deployment:** Blue-green deployment is a general deployment pattern where two identical environments (blue and green) are kept, and traffic is switched between them. Deployment slots in Azure App Service are an implementation of this pattern, but blue-green can be implemented with VMs, containers, or other platforms. Blue-green is the concept; deployment slots are the Azure-specific tool. They are similar in purpose but not identical in scope. (Example: Blue-green: you have two full server farms. Deployment slots: you have two slots within one App Service plan.)
- **Deployment slot vs Staging environment:** A staging environment is any environment that mimics production for testing. A deployment slot is a specific type of staging environment that is hosted in the same App Service plan and can be swapped with production. A staging environment could also be a separate App Service instance, a separate VM, or a local server. Deployment slots are more tightly integrated with Azure App Service and support the swap operation. (Example: A staging environment could be a different Azure Web App instance in a different resource group. A deployment slot is a slot within the same web app.)
- **Deployment slot vs Canary deployment:** A canary deployment releases a new version to a small subset of users before rolling out to everyone. Deployment slots can be used for canary deployments via the traffic routing feature (routing percentage to a slot). However, a canary deployment is a broader strategy that can be implemented without slots, for example by using feature flags or load balancer rules. Slots provide one way to do canary releases, but they also support full blue-green swaps. (Example: Using deployment slots, you can route 10% of traffic to the staging slot for a canary test. After validation, you route 100% or perform a full swap.)
- **Deployment slot vs Azure Traffic Manager:** Azure Traffic Manager is a DNS-based traffic load balancer that distributes traffic across multiple endpoints (which can be in different regions). It does not perform slot swaps or manage application versions. Deployment slots operate within a single App Service endpoint. Traffic Manager is for global load balancing and disaster recovery, not for versioned deployments within a single app. (Example: If you need to direct users to the nearest region, use Traffic Manager. If you need to swap app versions without downtime, use deployment slots.)

## Step-by-step breakdown

1. **Create a deployment slot** — In the Azure portal, navigate to your App Service (web app). Under the “Deployment” section, select “Deployment slots” and click “Add Slot.” Give it a name (e.g., “staging”) and choose whether to clone settings from an existing slot (usually production). Creating a slot provisions a new endpoint with its own hostname (staging-<yourapp>.azurewebsites.net). This step is the foundation for all subsequent operations.
2. **Configure slot-specific settings** — Go to “Configuration” for the slot (not the main app). Add app settings and connection strings that are specific to this slot (e.g., test database connection string). Mark each setting as a “Deployment slot setting” (sticky). These settings will remain with this slot even after a swap. This is critical to avoid configuration leaks between environments. Also configure any environment-specific values like API keys for sandbox services.
3. **Deploy your application code to the slot** — Use your CI/CD pipeline (Azure DevOps, GitHub Actions, FTP, or local Git) to deploy the new version of your app to the staging slot. The deployment goes to the new slot’s endpoint without affecting the production slot. You can also manually upload the code via the Azure portal. The staging slot now runs your new code independently on the same App Service plan.
4. **Test the application in the staging slot** — Access the staging slot’s URL (e.g., https://staging–myapp.azurewebsites.net) to perform functional tests, integration tests, and performance checks. Since the staging slot shares the same hosting resources as production, you get a realistic test environment. Run automated test suites, check logs, and verify that all features work. If the health check endpoint is configured, Azure will also test it before swap.
5. **Perform the slot swap** — In the Azure portal, go to “Deployment slots,” select the staging slot, and click “Swap.” Azure will validate the target slot’s health, apply source slot settings (non-sticky ones) to the target, then redirect traffic. The swap happens in seconds. The production slot now runs the new code, and the old code moves to the staging slot. You can also perform a swap via Azure CLI (az webapp deployment slot swap) or PowerShell.
6. **Monitor and roll back if necessary** — After the swap, monitor the production application using Azure Monitor, Application Insights, or your own dashboards. Check for errors, performance degradation, or any issues. If a problem is detected, perform another swap to revert to the old version (now in the staging slot). The rollback also happens with zero downtime. This step concludes the cycle. Optionally, you can enable auto swap to automate step 5 when a deployment succeeds.

## Practical mini-lesson

Deployment slots are not just a simple toggle; they require careful planning in real-world scenarios. First, you need to understand slot affinity. By default, Azure App Service uses ARR (Application Request Routing) cookies to maintain sticky sessions. When you swap slots, these cookies are not automatically transferred. Your application might need to handle session state externally (e.g., using Redis Cache or Azure SQL) to avoid session loss after swap. Many professionals configure their apps to be stateless or use a shared session store. This is a practical deployment consideration that often appears in complex exam scenarios.

Second, the auto swap feature is powerful but requires a healthy staging slot. Auto swap is configured on the target slot (usually staging) and triggers a swap when a deployment is successful. But “successful” depends on the health check configuration. If your health check endpoint is too permissive (always returns 200), auto swap might deploy a broken app. Conversely, if it is too strict, every deployment might fail the health check and prevent the swap. The health check path should be lightweight and check critical dependencies (like database connectivity). It should not be the home page if the home page depends on many services that might be slow during warm-up. A good health check returns a simple status page that validates core functionality.

Third, slot swapping and virtual networks. If your app is integrated with a virtual network, slot-specific settings for VNet integration can be tricky. The VNet integration is a slot-specific setting. You must ensure that both production and staging slots have appropriate VNet connections configured separately. Swapping will not transfer VNet integration settings automatically. This is a common misconfiguration in enterprise environments.

Fourth, there is the concept of “swap with preview.” This is an advanced feature that lets you validate the swapped configuration before the swap fully completes. You can perform a swap, but the traffic remains with the source slot until you finalize. This allows you to verify that settings are correct (like custom domains and certificates) before committing the swap. In practice, this is useful for high-risk deployments.

Fifth, consider the multi-region scenario. Deployment slots work within a single region. If your app is deployed across multiple regions for disaster recovery, you need to manage slots per region independently or use Azure Front Door or Traffic Manager for global routing. Deployment slots alone do not handle cross-region failover.

Finally, professionals often use deployment slots in combination with Azure DevOps release pipelines. A typical pipeline has stages: Build, Deploy to Staging, Run Smoke Tests, Swap to Production, and Post-Deployment Monitoring. Understanding how to configure these stages in YAML or the classic editor is invaluable for the AZ-400 exam. You should also know how to use the Azure CLI commands: `az webapp deployment slot create`, `az webapp deployment slot swap`, and `az webapp config appsettings set` to mark slot-specific settings. Practicing these commands in a lab environment will solidify your understanding.

deployment slots are a practical tool for safe, frequent releases. But they require attention to session state, health checks, VNet integration, and CI/CD pipeline integration. Master these subtopics for both exam and real-world success.

## Memory tip

Swap before you break, settings stick when you mark them. (Remember to mark slot-specific settings as sticky, and swapping is safe for zero-downtime.)

## FAQ

**How many deployment slots can I create?**

The limit depends on your App Service plan tier. Standard tier allows up to 5 slots (including production). Premium tiers allow up to 20 slots. Free and Shared tiers do not support slots.

**Can I use deployment slots for a containerized web app?**

Yes, deployment slots work with both Windows and Linux App Service, including container-based web apps. You can deploy container images to different slots and swap them.

**What happens to custom domains and SSL certificates during a swap?**

Custom domains and SSL certificates are not slot-specific by default. They move with the app during a swap. However, you can use slot-specific bindings by marking the certificate thumbprint as a slot setting. Typically, it is easier to apply the domain to the production slot and let it swap.

**Does a slot swap cause any downtime?**

No, slot swapping is designed for zero downtime. The traffic is redirected at the front-end level. However, if your application relies on sticky sessions (ARR affinity), individual user sessions may be lost. This is not downtime, but users might need to re-authenticate or lose session data.

**Can I send a portion of traffic to a slot without swapping?**

Yes, you can configure traffic routing (also called canary testing) to direct a percentage of traffic to a specific slot. This is different from swapping and allows you to test with real users while keeping the main version in production.

**What is auto swap and how does it work?**

Auto swap automatically swaps a slot into production when a deployment to that slot succeeds. It is configured on the target slot (e.g., staging). It requires a health check path to be defined. When you deploy new code to staging, Azure validates the health check, and if it passes, the swap is triggered automatically.

**Do I pay extra for deployment slots?**

You do not pay a separate fee for slots, but all slots share the same App Service plan resources. If you run multiple slots actively, you consume more CPU, memory, and disk from your plan. This may require scaling up or scaling out your plan, which increases costs.

## Summary

Deployment slots are a powerful and essential feature of Azure App Service that enable zero-downtime deployments, safe testing, and instant rollback. By creating a separate, live staging environment that shares the same App Service plan, you can deploy new code, validate it under near-production conditions, and swap it live in seconds. This transforms the deployment process from a high-risk event into a routine operation. 

 For IT certification candidates, especially those preparing for AZ-104 and AZ-400, mastery of deployment slots is not optional. You need to understand how to create and manage slots, the behavior of sticky settings, the swap operation, and how to integrate slots into CI/CD pipelines. Expect scenario-based questions that test your ability to choose slots for zero-downtime situations, as well as step-ordering and troubleshooting questions. Common mistakes include ignoring sticky settings, assuming slots work on Free tier, and forgetting to pre-warm. 

 The key takeaway for the exam: when you see the phrase 'zero downtime' or 'test before production', think deployment slots. When you see 'canary deployment' or 'traffic routing', also think slots. With this glossary entry, you now have a thorough understanding of what deployment slots are, how they work in practice, and how to answer exam questions about them correctly. Remember the memory tip: 'sticky settings stay stuck to their slot.' Good luck with your certification journey.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/deployment-slot