In the context of the Azure Administrator Associate certification and the management of Azure compute resources, App Service deployment slots are a critical feature mainly used to achieve zero-downtime deployments and efficient lifecycle management. A deployment slot is essentially a live web appli…In the context of the Azure Administrator Associate certification and the management of Azure compute resources, App Service deployment slots are a critical feature mainly used to achieve zero-downtime deployments and efficient lifecycle management. A deployment slot is essentially a live web application with its own unique hostname, running within the same App Service Plan (VM instances) as the production app. This feature is available in the Standard, Premium, and Isolated service tiers.
The primary function of deployment slots is to act as staging environments. Administrators can deploy a new version of an application to a non-production slot (e.g., 'Staging'), validate the functionality, and warm up the instances without impacting the live production traffic. Once validated, the administrator initiates a 'swap' operation.
During a swap, Azure ensures that the instances in the staging slot are fully ready before redirecting production traffic to them. This redirection happens at the load balancer level, ensuring no downtime. Conversely, the old production version is moved to the staging slot. This mechanism provides an immediate fallback strategy: if the new version encounters errors in production, you can immediately swap back to the previous version, reverting to the last known good state.
Administrators must also manage configuration settings during swaps. Settings can be 'sticky' (slot-specific) or swappable. For instance, a connection string to a development database should be sticky to the staging slot, preventing the production app from connecting to a test database after a swap.
Finally, slots support 'Testing in Production' by allowing valid traffic routing rules. An administrator can route a specific percentage of user traffic (e.g., 5%) to a beta slot to test performance or features before commit to a 100% rollout.
Azure App Service Deployment Slots: A Comprehensive Guide for AZ-104
Why is it Important? Deployment slots are a fundamental feature in Azure App Service for achieving zero-downtime deployments and minimizing the risk of introducing bugs into a live environment. They allow administrators and developers to validate changes in a staging environment that mimics production infrastructure exactly, without impacting end-users. Furthermore, they provide an instantaneous rollback mechanism; if a new version has critical errors, you can revert to the previous "known good" state in seconds.
What is it? A deployment slot is essentially a live App Service with its own hostname. App Service apps run in an App Service Plan, and deployment slots share the same VM instances and resources (CPU, Memory) as the production instance within that plan.
Crucially for the AZ-104 exam, deployment slots are not available in the F1 (Free), D1 (Shared), or B1 (Basic) tiers. You must be utilizing Standard, Premium, or Isolated App Service plans to use this feature.
How it works The core mechanic of deployment slots is the Swap. When you deploy your code to a staging slot, the app starts up and creates a warm instance. When you are ready to deploy to production, you perform a swap operation.
During a swap, Azure changes the routing of the Virtual IP address. The traffic destined for the production URL is routed to the instance that was previously the staging slot, and vice versa. This ensures no requests are dropped.
Settings Handling (The "Sticky" Concept): One of the most complex parts of how slots work is understanding which configuration settings move with the swap and which stay attached to the specific slot (known as Sticky Settings or Slot Settings). 1. Settings that swap: General settings (framework version, sockets), App settings (unless marked as slot setting), Connection strings (unless marked), and Handler mappings. 2. Settings that do NOT swap (remain with the slot): Publishing endpoints, Custom domain names, SSL certificates and bindings, Scale settings, and WebJobs.
Exam Tips: Answering Questions on App Service deployment slots When facing AZ-104 questions regarding slots, look for these specific scenarios and keywords:
1. Prerequisites Scenarios: If a question asks why you cannot see the "Deployment Slots" option in the Azure Portal, the answer is almost always that the App Service Plan is on the Basic or Free tier. You must scale up to Standard.
2. Rollback Scenarios: If a scenario states, "You deployed a new version to production, and users are reporting HTTP 500 errors. You need to recover as fast as possible," the correct answer is to swap the slots back. Do not select "restore from backup" (too slow) or "redeploy previous code" (slower than swapping).
3. Configuration Scenarios (The Sticky Trap): Pay close attention to Database Connection Strings. If a question asks how to ensure your Staging App connects to a Test Database and not the Production Database, you must mark the connection string as a Deployment slot setting. If you don't, the connection string will swap into production, causing your production app to connect to the test database (or vice-versa).
4. Traffic Routing (Canary Testing): If a question asks how to route only a small percentage of users (e.g., 10%) to a new version of the app to test performance, the answer is to use Testing in Production feature by configuring the Traffic % on the deployment slot blade.