What's changed: Deepened AZ-204 Chapter 1 to Associate depth (tables, scenarios, FAQ, traps; localized figures)
1.1Developing Web Apps with App Service
Understand managed hosting of web apps/APIs with Azure App Service, App Service plans, deployment slots (staging → swap), and scaling (up/out). The starting point for "Develop Azure compute solutions" in AZ-204.
Azure App Service lets you publish web apps/APIs quickly without managing the OS (PaaS). Developers focus on deploying code.
1.1.1App Service building blocks
- App Service plan: defines the compute (size/tier) that hosts apps; can be shared by multiple apps.
- Deployment slots: validate in staging, then swap with prod for zero-downtime releases.
- Scaling: scale up (change plan size) and scale out (add/remove instances).
- Settings: externalize config via app settings (env vars)/connection strings; prefer Key Vault references for secrets.
Common on AZ-204: zero-downtime release = deployment slot swap, adjust instance count by load = scale out, web hosting without OS management = App Service. Swap routes to pre-warmed instances.
App Service is PaaS for web apps/APIs/containers. Apps run on an App Service plan whose SKU/tier (Free/Shared → Basic → Standard → Premium v3 → Isolated) sets performance, scale limits, and features (custom domain/SSL, slot count, VNet integration). Deployment slots validate in staging then swap with production, switching to pre-warmed instances for zero downtime; roll back by simply swapping back. Items marked as a slot setting (e.g., connection strings) stay pinned to the slot and aren’t swapped. Scale via scale up (change plan SKU) and scale out (instance count, autoscale rules). Externalize config with app settings (env vars)/connection strings, inject secrets safely with Key Vault references, and use a managed identity for the app’s identity. Deploy via ZIP/Run From Package, CI/CD, or containers. Diagnose with App Service diagnostics/log stream/Application Insights. The axes: "zero downtime = slot swap," "instance count = scale out," "performance/features = change SKU (up)," "secrets = Key Vault references."
| Goal | Means |
|---|---|
| Zero-downtime release | Deployment slot swap |
| Adjust instance count by load | Scale out (autoscale) |
| Raise performance/features | Change SKU = scale up |
| Inject secrets safely | Key Vault references + managed identity |
Scenario: update production without downtime and pin the DB connection string per slot. Deploy to a staging slot, validate, then swap with production (pre-warmed, zero downtime). Mark the connection string as a slot setting so it isn’t swapped. Inject the DB password via a Key Vault reference + managed identity. Absorb spikes with autoscale (scale out).
Q. Zero-downtime release? Deployment slot swap. Q. Add instances? Scale out. Q. Raise performance/features? Change SKU (scale up). Q. Inject secrets? Key Vault references + managed identity. Q. Don’t swap a setting? Mark it a slot setting.
Watch the mix-ups: (1) Scale up (SKU) ≠ scale out (instances)—load needs instances; features/limits need SKU. (2) Slot count/availability depends on SKU (none/few on Free/Basic). (3) Without marking it a slot setting, even connection strings get swapped. (4) Don’t hard-code app settings—externalize and use Key Vault references for secrets.
Marking a setting as a "slot setting" keeps it pinned to the slot (not swapped), useful for connection strings, etc.
1.1.2Section summary
- App Service = PaaS web hosting (plan = compute)
- Zero-downtime via slots, scale up/out
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want zero-downtime updates to production in App Service. Which fits best?
Q2. Which Azure PaaS hosts web apps without minding OS/patching?
Q3. What is increasing App Service instance count under load called?