Compute · Lesson 15 of 24

App Service: plans, scaling, slots, TLS, networking

Hosting a website with no server to patch. The plan is what you pay for; the app is what you deploy into it.

About 10 min · Interactive · 3 practice questions

Exam objective
Provision an App Service plan · Configure scaling · Create an App Service · Configure certificates and TLS · Map a custom DNS name · Configure backup · Configure networking settings · Configure deployment slotsDeploy and manage Azure compute resources · 20–25% of the exam · typical question: "Minimum tier for N slots/autoscale", slot-swap side effects, custom domain record types, inbound vs outbound networking
In one sentence. App Service is managed web hosting: you rent a plan (a pool of servers of a chosen tier), deploy one or more apps into it, and use slots to test a new version then swap it live. App Service is web hosting. You upload code (or point it at a repo) and Microsoft runs the web servers, patches them and restarts them. You rent a plan, which is a pool of servers of a certain size; several apps can share one plan. Deployment slots let you test a new version on the same plan and swap it live with no downtime.
App Service plan: Standard S1, Australia East, Linuxthe pool of servers you pay for · scale UP = bigger tier · scale OUT = more instancesapp: contoso-webslots: production, stagingapp: contoso-apishares the same serversinstances: 1 → 3all apps run on all instances
Apps do not have their own compute. The plan does.

You, the admin: publish contoso-web

  1. App Services › + Create › Web App. Name (becomes contoso-web.azurewebsites.net), runtime (.NET, Node, Python…), OS, region, App Service plan: create new, pick a tier (Standard S1 for production).
  2. Deploy code: App › Deployment Center (GitHub, Azure DevOps, ZIP) or az webapp up.
  3. Add a slot: App › Deployment slots › + Add slot "staging". Deploy the new build there, test at contoso-web-staging.azurewebsites.net, then Swap.
  4. Scale: App Service plan › Scale up to change tier; Scale out for manual count or Custom autoscale rules (CPU > 70% for 10 min → +1, cooldown 5 min; schedule profiles for business hours).
TierMax instancesSlotsAutoscaleCustom domain + TLSBackupVNet integration
Free / Sharedshared0NoNo TLSNoNo
Basic3 manual0NoYesNoYes
Standard105YesYesYesYes
Premium v33020YesYesYesYes
Isolated (ASE)10020YesYesYesDedicated VNet

Slots and swapping

A slot is a complete second copy of the app with its own URL and its own settings, on the same plan. Swap exchanges which one answers the production URL, instantly, and the old production stays in the slot so you can swap back. Every app setting and connection string travels with the swap unless you tick Deployment slot setting on it; sticky settings stay with the slot (a staging database string should be sticky). Swap with preview applies production settings to staging first so you can test before completing.

Your own domain and HTTPS

  1. App › Custom domains › + Add. Prove ownership at your DNS host: for www.contoso.com a CNAME to contoso-web.azurewebsites.net; for the bare contoso.com an A record to the app's IP plus a TXT record asuid.
  2. Certificate: App Service managed certificate (free; no wildcard, cannot be exported), buy an App Service certificate, upload your own PFX, or import from Key Vault.
  3. Binding: SNI SSL (default, free) or IP-based SSL (dedicated IP, Basic tier or above). Then Configuration › General settings: HTTPS Only = On, minimum TLS 1.2.

Networking

DirectionFeatureDoes
InboundAccess restrictionsAllow list of IPs or subnets (service endpoint); everyone else gets 403
InboundPrivate endpointApp reachable only on a private IP inside your VNet
OutboundVNet integrationApp can call servers inside a VNet (a SQL VM). Needs an empty, delegated subnet
OutboundHybrid connectionReach one on-prem host:port without a VPN

Backup (App › Backups, Standard and above): schedule to a storage account; includes files, configuration and optionally a linked database; restore to the same app or a new one. App settings become environment variables; Always On keeps the app loaded; Kudu at <app>.scm.azurewebsites.net is the advanced console.

Trap wording. "Needs slots or autoscale on Basic" = scale up to Standard. "Production now points at the test database" = connection string was not sticky. "App must reach a private SQL server" = VNet integration (outbound). "App reachable only from the VNet" = private endpoint (inbound).

Key points

  • The plan is what you pay for; apps share it. Scale up = bigger tier (unlocks features), scale out = more instances.
  • Standard is the first tier with slots (5) and autoscale; Premium v3 gives 20 slots and 30 instances.
  • Swap exchanges slots with no downtime; settings marked as slot settings stay behind.
  • Inbound privacy = private endpoint; outbound to a VNet = VNet integration.
  • Free managed certificate works for www names, no wildcard, cannot be exported.

Formal terms: App Service plan, scale up vs scale out, deployment slot, sticky (slot) setting, swap with preview, SNI, App Service Environment (ASE), Kudu.

Check your understanding

3 exam-style questions in the formats AZ-104 uses. Each is marked when you check it, with the reasoning.

0 of 3 checked

All scenarios and questions are original. None are taken from the exam, Microsoft's practice assessment or any question bank. PrepToExcel is not affiliated with Microsoft.