Diagnosing a Slot Swap That Broke Production App Settings
Your release pipeline deploys a .NET Core web app to Azure App Service using a slot swap strategy. The pipeline runs acceptance tests on the staging slot before swapping. After a recent change, the acceptance tests pass but the production site becomes unresponsive after the swap. What is the most likely cause?
Quick Answer
The production outage traces back to the slot swap itself: Azure App Service swaps all slot-specific configuration, including app settings and connection strings, along with the code. If the staging slot's settings were meant only for testing, they overwrite production during the swap — which is why acceptance tests pass against staging but the live site breaks immediately after.
⚠ Common exam trap
Watch out — candidates often assume acceptance tests are sufficient to catch all issues, or they misunderstand the slot swap mechanism—thinking it causes downtime—when the real problem is the automatic migration of non-sticky configuration settings between slots.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The staging slot had different app settings that were swapped into production, causing the site to fail.
The most likely cause is that the staging slot had different app settings (e.g., connection strings, environment variables, or feature flags) that were swapped into production. During a slot swap, Azure App Service automatically moves all slot-specific configuration (app settings, connection strings, and other deployment slot settings) to the target slot. If the staging slot was configured with settings intended only for testing (like a staging database or debug mode), those settings would overwrite the production settings, causing the production site to become unresponsive. This is a common pitfall because acceptance tests may pass against the staging environment but fail when the same code runs with production configuration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The staging slot had different app settings that were swapped into production, causing the site to fail.
Why this is correct
Slot swap swaps all settings, so if staging settings are not suited for production, the site can become unresponsive.
- ✗
The acceptance tests are not comprehensive enough and missed a regression.
Why it's wrong here
The tests passed, so the issue is likely not a regression in code but a configuration mismatch.
- ✗
The acceptance tests should have been run after the swap.
Why it's wrong here
Running tests after swap is a valid practice, but the issue is configuration, not test timing.
- ✗
The slot swap was not 'warm-up' and caused downtime.
Why it's wrong here
Slot swap is designed to avoid downtime; warm-up is optional.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
Key term
Release pipeline
A Release pipeline is an automated sequence of steps that takes software from code commit to production deployment, ensuring quality and consistency.
About these practice questions
Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
5 more ways this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Your release pipeline deploys to Azure App Service using a deployment slot strategy. After a successful deployment to the staging slot, you run smoke tests, then swap slots. Recently, a swap failed because the staging slot had an incorrect application setting. What is the BEST way to prevent this issue?
hard- A.Use a manual approval gate before swap.
- B.Configure the App Service deployment center.
- C.Add a task to verify settings before swap.
- ✓ D.Mark the application setting as a deployment slot setting.
Why D: Marking the application setting as a deployment slot setting ensures that the setting stays with the slot and is not swapped between staging and production. This prevents the staging slot from having an incorrect value that could cause a swap failure, as the setting is pinned to the slot and not part of the swap payload.
Variation 2. Your release pipeline deploys to Azure App Service using a deployment slot. You need to ensure that after swapping slots, the staging slot retains the previous production configuration for rollback. Which deployment strategy should you use?
medium- A.Rolling deployment
- B.Blue-green deployment
- ✓ C.Swap with preview
- D.Canary deployment
Why C: Swap with preview (multi-phase swap) is the correct strategy because it uses Azure App Service deployment slots to validate the staged version before completing the swap. When the swap is completed, the staging slot receives the previous production code and configuration, preserving a rollback state. If a problem occurs, you can swap back to the staging slot. Note that a standard slot swap also preserves the previous production state in staging, but swap with preview adds the benefit of preview validation before finalizing the swap, which aligns with the requirement of maintaining rollback capability.
Variation 3. Your release pipeline deploys a .NET Core web app to Azure App Service using a deployment slot for staging. The pipeline runs integration tests against the staging slot. After tests pass, you want to swap the staging slot with production. However, the swap fails sometimes because the staging slot has different configuration settings. What is the best practice to ensure swapping succeeds?
medium- ✓ A.Use slot-specific configuration settings (deployment slot settings) for connection strings and app settings that differ between slots.
- B.Manually update the production slot settings to match staging before each swap.
- C.Perform a swap with preview and then complete the swap after verifying the staging slot.
- D.Write a custom PowerShell script to copy configuration from staging to production before swapping.
Why A: Azure App Service allows you to mark specific configuration settings (like connection strings and app settings) as 'deployment slot settings.' When a setting is marked as slot-specific, it stays with the slot during a swap, preventing failures caused by mismatched configurations. This ensures that the staging slot retains its test-specific settings (e.g., a test database connection string) while the production slot keeps its own settings, making the swap predictable and reliable.
Variation 4. You are designing a release pipeline for a mission-critical application that must achieve zero-downtime deployments to Azure App Service (Web App for Containers). The application uses Azure SQL Database with schema migrations. The current deployment slot strategy uses staging and production slots. You need to ensure that during a swap, the staging slot is warmed up and the database schema is rolled back if the swap fails. Which combination of deployment slots and pre/post-swap actions should you implement?
hard- ✓ A.Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new to staging, warm up staging, then swap staging to production. On failure, swap staging back to production.
- B.Use two slots (staging and production) with auto-swap enabled. The auto-swap handles warm-up automatically. If the swap fails, Azure automatically rolls back.
- C.Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new slot to staging, then staging to production. On failure, swap staging back to production.
- D.Use two slots (staging and production). Apply schema changes in staging before swap. If swap fails, manually redeploy the old version to production.
Why A: It uses three slots to isolate schema changes in a new slot, then swaps to staging for warm-up, and finally swaps to production. If the swap fails, rolling back staging to production reverses the schema changes, ensuring zero-downtime. This approach aligns with Azure App Service slot-swap best practices for mission-critical applications requiring database rollback capability.
Variation 5. Your Azure DevOps pipeline deploys a web app to Azure App Service using a YAML pipeline. The deployment fails intermittently with the error 'Conflict' when updating deployment slots. What is the most likely cause?
medium- ✓ A.Another deployment or swap operation is already in progress on the slot.
- B.The service connection is using expired credentials.
- C.The slot name is misspelled in the pipeline configuration.
- D.The web app is locked by a file handle from a previous deployment.
Why A: The 'Conflict' error during an Azure App Service deployment slot update indicates that the slot is currently locked by another operation, such as an ongoing deployment or a swap. Azure App Service enforces mutual exclusion on slot operations to prevent race conditions, so if a previous deployment or swap has not completed, the new request is rejected with HTTP 409 Conflict.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.