A blood-bank App Service site JIT-compiles on first request, so a cold swap still caused a rider-visible pause. Which swap technique should the developer use so the destination worker warms before cutover?
Select an answer to reveal the explanation.
Short Explanation
Cold JIT is like opening a closed shop—first customer waits. Swap with preview (and app init) warms the destination worker before the final flip so the blood-bank site does not hitch. Availability tests watch health; they do not warm the swap.
Full Explanation
The blood-bank App Service site JIT-compiles on first request, so a cold swap still caused a rider-visible pause. Use swap with preview (and/or application initialization) so the destination worker warms before final cutover. Preview staging lets the platform apply the pending swap state and hit warm-up routes while production traffic still hits the old bits; completing the swap afterward lands riders on already-initialized workers. That technique specifically targets post-swap cold-start and JIT latency.
Disabling HTTPS-only for five minutes during every production swap weakens transport security and does nothing to pre-JIT application code on the destination slot. Replacing slot swap with an Application Insights availability test as the release gate monitors endpoint health but does not warm the destination worker as part of the swap workflow. Lowering the App Service minimum TLS version to speed the first post-swap handshake trades security for a misunderstanding—TLS negotiation time is not the JIT compile pause, and weakening TLS is the wrong lever.
Exam caveat: configure applicationInitialization (or warm-up paths) so preview actually exercises the code paths that JIT; an empty warm-up still leaves first real requests cold. Operational check: enable swap with preview, confirm warm-up requests hit the destination, complete the swap, and compare first-request latency after cutover against a previous cold swap.