The city must stage a new agent-tool Function API before residents hit it. Which deployment practice reduces release risk?
Select an answer to reveal the explanation.
Short Explanation
Deployment slots are the dress rehearsal stage—run the new agent-tool API in staging, then swap the sets so residents never watch the tech crew mid-show.
Full Explanation
Staging a new agent-tool Function API before residents hit it is a classic deployment-slot scenario. Deploy the Function app to a staging slot, validate HTTP tools, bindings, and configuration there, then swap into production. Swap keeps the production URL stable while reducing the chance that a bad tool definition or setting takes down the live municipal agent mid-day.
Overwriting production in place with no staging validation or swap maximizes resident-facing risk: cold failures appear only after traffic moves. Publishing only from a developer laptop with unpublished local settings fails environment parity—local.settings.json values often never match production Key Vault or app settings. Deleting the production Function app before each release to force a clean start causes outage, DNS/URL disruption, and lost configuration—unacceptable for citizen-facing agent tools.
Exam caveat: slots require a plan that supports them (for example Premium/Dedicated); Consumption-only constraints may limit slot use—know the hosting SKU. Also validate app settings and sticky slot settings so secrets do not point staging at production queues unintentionally. Operational check: deploy to staging, run smoke tests against the staging URL, swap, confirm production tools respond with the new revision, and keep a swap-back plan if error rates rise.