A courts clerk assistant runs in App Service containers. Staging should use different Key Vault secret references than production. What should the team do?

App Service deployment slots support configuration that differs by slot, including application settings and Key Vault references. Courts clerk assistant teams should configure slot-specific settings so staging resolves non-production Key Vault secrets and endpoints while production keeps live references. The same container image can then be swapped or tested in staging without sharing production credentials. That separation is the core reason slots exist beyond blue-green code alone—configuration isolation for municipal environments.

Sharing one production Key Vault reference across staging and production slots fails environment isolation and risks staging tests mutating or exposing production secrets. Baking both environments’ secrets into a single multi-purpose image tag fails the runtime-config model and forces secret sprawl inside layers. Disabling slots and redeploying production overnight for every staging test fails safe validation practices and removes the slot-specific settings feature the question targets.

Exam caveat: Sticky settings (slot settings) must be marked appropriately so they do not swap with the code; otherwise staging secrets can move into production on swap. Understand sticky vs. swappable settings when designing clerk-assistant slot configuration.

Operational check: Open staging and production slot application settings and verify distinct Key Vault references. Confirm sticky flags on secret settings, deploy the same image tag to staging, exercise the clerk assistant against non-prod secrets, and only then swap or promote—never relying on a shared production secret in staging.