Skip to main content

Technical Lab: Configure deployment slots for an App Service

Questions​

Question 1 — Multiple Choice​

A development team uses Azure App Service with a staging slot. After validating the application in the staging slot, the team performs a swap operation between staging and production. What is the expected behavior regarding slot settings?

A. Slot settings are swapped along with the application content, migrating from staging to production.

B. Slot settings remain fixed in their respective slots and do not follow the swap.

C. Slot settings are automatically deleted after the swap to avoid environment conflicts.

D. Slot settings are copied to the destination slot, but are also maintained in the source slot.

Question 2 — Technical Scenario​

An administrator needs to ensure that when swapping between staging and production, the App Service does not receive requests from end users during the warm-up phase. The staging slot is configured with the default option and there is no special configuration active at the moment.

Which functionality should be enabled to meet this requirement?

A. Enable Always On in the staging slot so that initialization occurs before the swap.

B. Configure Auto Swap pointing directly to production, eliminating the transition phase.

C. Activate the Swap with Preview option, which keeps the staging slot receiving production configurations before completing the swap.

D. Increase the Health Check interval so that the App Service waits longer before routing traffic.

Question 3 — Multiple Choice​

Consider the following variable configuration scenario in an App Service:

Slot: production
  APP_ENV = production      (slot setting: false)
  DB_CONN = conn-prod       (slot setting: true)

Slot: staging
  APP_ENV = staging         (slot setting: false)
  DB_CONN = conn-staging    (slot setting: true)

After a swap between production and staging, what will be the state of APP_ENV and DB_CONN in the production slot?

A. APP_ENV = production and DB_CONN = conn-prod

B. APP_ENV = staging and DB_CONN = conn-prod

C. APP_ENV = production and DB_CONN = conn-staging

D. APP_ENV = staging and DB_CONN = conn-staging

Question 4 — Technical Scenario​

An organization uses a Standard S1 App Service plan. The infrastructure team tries to create a fifth deployment slot to support a new dedicated QA environment, but the operation fails with an exceeded limit error.

az webapp deployment slot create \
  --name myapp \
  --resource-group myRG \
  --slot qa-dedicated

What is the cause of the error and what is the correct action?

A. The slot name contains a hyphen, which is not allowed. It should be renamed to qadedicated.

B. The Standard plan supports a maximum of 4 deployment slots per App Service. To have more slots, it is necessary to migrate to the Premium plan.

C. The command is using outdated Azure CLI. The correct parameter would be --deployment-slot instead of --slot.

D. The deployment slots feature is not available in the Standard plan; it is necessary to migrate to the Premium plan to enable them.

Question 5 — True or False​

When executing a swap between two App Service slots, Azure automatically performs a warm-up phase in the destination slot before redirecting traffic, provided the application responds with HTTP 200 on the initialization route configured in Health Check.

True or False?

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Slot settings (application settings or connection strings marked as "deployment slot setting") are bound to the slot, not to the application content. During a swap, the content and settings not marked as slot settings migrate between slots, but slot settings remain fixed where they are.

This behavior is intentional: it allows each environment (e.g., staging, production) to maintain its own connection strings or environment-specific variables, regardless of how many swaps occur.

The main misconception of the distractors is treating all settings as if they were equivalent, without considering the distinction between slot-bound settings and settings that follow the code.

Answer Key — Question 2​

Answer: C

Swap with Preview is the functionality that allows performing the swap in two phases. In the first phase, the destination slot (production) settings are applied to the source slot (staging), but end-user traffic is not yet redirected. This allows the application to warm up with the actual production settings before completing the swap.

  • Always On (A) keeps the process active, but does not control traffic flow during the swap.
  • Auto Swap (B) automates the swap immediately after a deploy, without a preview phase.
  • Health Check (D) monitors instance health, but does not block traffic routing during the swap warm-up phase by itself.

The consequence of not using Swap with Preview is that user requests may hit an instance still initializing, resulting in noticeable errors or slowness.

Answer Key — Question 3​

Answer: B

After the swap:

SettingBehaviorResult in production
APP_ENVNot a slot setting: follows the contentstaging (came from staging slot)
DB_CONNIs a slot setting: stays fixed in the slotconn-prod (remains in production)

APP_ENV is not marked as a slot setting, therefore it migrates along with the application code from staging to production. DB_CONN is marked as a slot setting, remaining bound to the production slot with its original value conn-prod.

The most common error is assuming that all variables behave the same way during the swap. The distinction between slot settings and normal settings is the core of this behavior.

Answer Key — Question 4​

Answer: B

The Standard plan supports up to 5 total slots per App Service (including the production slot), therefore the actual limit is 4 additional slots. If the team already has 4 additional slots and tries to create a fifth, the operation fails due to the plan limit.

The correct solution is to migrate to the Premium plan, which supports up to 20 slots per App Service.

  • Alternative D is wrong because deployment slots are available in the Standard plan; the problem is the quantity limit, not the absence of the feature.
  • Alternatives A and C represent technical misconceptions about CLI nomenclature and slot names, which are not the real cause of the error in this scenario.

Answer Key — Question 5​

Answer: False

Azure performs automatic warm-up during the swap based on the application initialization rules (such as applicationInitialization in web.config or App Service settings), and not based on the route configured in Health Check.

Health Check is used to continuously monitor instance health and remove unhealthy instances from the load balancer, but it is not the mechanism that controls warm-up during the swap. Confusing the two is a common conceptual error, as both involve HTTP checks, but with distinct purposes and execution moments.