Plan and implement deployment mechanics that minimise downtime, including deployment slots and swap, rolling deployments, hotfix paths, containers, binaries, and database tasks.

An "Azure App Service" runs production and staging slots. A connection string must always point at the production database when the slot is acting as production and at the test database when it is acting as staging, so the value must stay with the slot and not travel during a swap. Other application settings should move with the code when slots are swapped. How should the connection string be configured?

• AStore the connection string in the production slot only and leave it unset on staging, relying on the swap to copy the production value across to staging whenever the two slots are exchanged.
• BSet the connection string on each slot and mark it as a deployment slot setting so it is treated as slot-sticky and stays bound to its slot rather than moving when the slots are swapped.check_circle Correct
• CPlace the connection string in "Azure Key Vault" and reference it from both slots, since a Key Vault reference is resolved at runtime and therefore is never carried between slots during a swap operation.
• DDefine the connection string once at the App Service plan level so it applies to every slot on the plan, ensuring the same value is shared and never changes regardless of which slot is in production.

Why A is wrong: Leaving staging unset and depending on the swap to copy the value is the opposite of what is needed, because a normal setting moves during the swap so staging would end up using the production database after exchanging.

Why B is correct: Marking a setting as a deployment slot setting makes it slot-sticky, so each slot keeps its own connection string through a swap, which is exactly how production and staging stay bound to their respective databases while other settings still move.

Why C is wrong: A Key Vault reference secures the value but the reference itself is still an app setting that swaps unless marked slot-sticky, so both slots would resolve the same secret and the per-slot database binding would not hold.

Why D is wrong: App Service does not bind connection strings at the plan level for slots, and a single shared value would give production and staging the same database, defeating the requirement for each slot to target a different database.