App Service web runtime decisions

Where it sits in the route

This module follows container packaging and introduces a managed HTTP runtime before Functions, storage, and API integration.

Prerequisites and outcomes

Know HTTP requests, DNS, TLS, processes, environment variables, and App Service plans. You should be able to trace code or an image into an app, explain plan capacity, separate slot configuration from production configuration, and choose a safe promotion or rollback boundary.

Concept sequence and relationships

An App Service plan supplies the compute boundary; an app serves HTTP; settings and certificates configure its behavior; a slot hosts a candidate version; a swap changes production routing. The deployment artifact or image is promoted into the slot, and telemetry flows to Application Insights. TLS protects transport, but it does not authorize the caller or fix an application bug.

Worked scenario and distinctions

Deploy an API to staging, set a staging connection setting, call its health endpoint, inspect logs, and swap only after the response and dependency checks pass. A slot is a version boundary; an environment is a broader delivery boundary. Scale-out adds instances; scale-up changes the plan’s capacity. A slot-specific setting that is missing after swap explains a configuration failure; it is not evidence that the deployment artifact is corrupt.

Conceptual checkpoint

Explain what changes when a slot swap occurs, which settings must remain slot-specific, and how you would distinguish a TLS failure, a platform-capacity failure, and an application exception from their observable signals.

Hands-on / what to try

Read a sample App Service deployment configuration and predict the production slot, setting, certificate, and telemetry state after a swap and a rollback. This is a static procedure; live execution and resource cleanup are not claimed.

Sources and re-audit

Re-audit when App Service plans, slots, TLS, deployment, or scaling behavior changes.