Azure App Service for AZ-104: Plans, Scaling, Backups and Slots

Introduction

Configuring Azure App Service for AZ-104 means choosing a hosting plan, securing web traffic and deploying recoverable releases. This lesson completes the AZ-104 skills area Deploy and manage Azure compute resources (20–25% of the exam). The study guide objective is create and configure Azure App Service: provision an App Service plan, configure scaling for an App Service plan, create an App Service, configure certificates and Transport Layer Security (TLS) for an App Service, map an existing custom DNS name to an App Service, configure backup for an App Service, configure networking settings for an App Service, and configure deployment slots for an App Service.

App Service is Azure's fully managed platform for web apps, REST APIs and mobile back ends. Microsoft patches the operating system and runtime, and you manage the application and its settings. Exam scenarios revolve around one question: which plan tier and which setting gives the app the feature it needs (slots, autoscale, backup, private networking) at a sensible cost?

After this lesson you will be able to choose and scale an App Service plan, create an app, secure it with TLS and a custom domain, back it up, control its inbound and outbound networking, and release safely with deployment slots.

Learning objectives

• Explain the relationship between an App Service plan and the apps that run in it.
• Compare pricing tiers and name the features that appear in each.
• Scale a plan up, out and automatically with autoscale rules.
• Create an app and set application settings, connection strings and runtime stack.
• Bind a custom domain and certificate, and enforce HTTPS and minimum TLS version.
• Configure backups and understand what they include.
• Configure access restrictions, private endpoints and virtual network integration.
• Use deployment slots, slot settings and swap.

App Service plans

Plan versus app

An App Service plan defines the compute: operating system (Windows or Linux), region, number of instances, and size and pricing tier. An App Service (web app) is the application deployed into a plan. Many apps can share one plan, and they all share its CPU and memory. You pay for the plan, not for each app, so consolidating small apps onto one plan saves money while a busy app that starves its neighbours should move to its own plan.

Important constraints:

• A plan is tied to a region and an operating system. Windows and Linux apps cannot share a plan.
• You can move an app to another plan only when they are compatible and belong to the same webspace. Plans created in the same resource group, region and OS combination share a webspace; merely moving a plan into that resource group later does not change its webspace. Disable the app’s VNet integration before moving it to another plan, then reconfigure it.
• Stopping an app does not stop billing; the plan keeps charging for its instances. Delete or scale down the plan to cut cost (the Free tier has no charge).

Pricing tiers

Backups are also available on Basic; backup frequency is not the Standard/Premium distinction. Exact slot counts and instance limits are documented on Microsoft Learn; exam questions focus on the threshold features: slots and autoscale begin at Standard, private endpoints and VNet integration need a dedicated tier (Basic or higher for most scenarios, Premium v3 recommended), and full isolation is Isolated.

Exam tip: "The app needs staging slots" or "must scale automatically" means at least Standard. "Needs a custom domain" means not Free.

Scaling

Scale up and scale out

Manual scaling and Azure Monitor autoscale change the plan’s worker count. By default all apps run on all those workers. Per-app scaling can restrict an app to a subset of workers; it does not reduce the allocated plan’s bill. Scale up when the app needs a feature (slots) or more memory per instance. Scale out when you need more concurrent capacity. A stateful in-memory session needs shared storage or a distributed cache before scaling out.

Autoscale

Autoscale (Standard and above) is configured in Azure Monitor autoscale settings for the plan. A profile contains:

• Minimum, maximum and default instance counts
• Rules: a metric (CPU percentage, memory percentage, HTTP queue length), a threshold, a time window, an operator, and the action (increase or decrease by a count or percentage) with a cooldown
• Optional schedule profiles (for example more instances during business hours or on a date)

For a metric-based profile, define both scale-out and scale-in behavior; without a scale-in rule it will not shrink in response to lower metrics. A scheduled profile can separately change the active capacity range. Leave a gap between thresholds (for example out above 70% CPU, in below 30%) to avoid flapping.

az appservice plan create -g rg-web -n plan-shop --sku S1 --is-linux
az monitor autoscale create -g rg-web --resource plan-shop \
  --resource-type Microsoft.Web/serverfarms --name autoscale-shop --min-count 2 --max-count 6 --count 2
az monitor autoscale rule create -g rg-web --autoscale-name autoscale-shop \
  --condition "CpuPercentage > 70 avg 10m" --scale out 1
az monitor autoscale rule create -g rg-web --autoscale-name autoscale-shop \
  --condition "CpuPercentage < 30 avg 10m" --scale in 1

Automatic scaling is a different mode. Premium v2, v3 and v4 plans support HTTP-based per-app automatic scaling, with always-ready/prewarmed capacity and app limits. Azure Monitor autoscale instead evaluates plan metrics or schedules. Only one scaling mode is active for a plan; deployment-slot traffic is not supported by automatic scaling. Select the mode that matches the workload and budget, rather than treating the two names as interchangeable.

Creating an App Service

When creating an app you choose:

• Name: globally unique. Read the assigned defaultHostName; new secure unique hostnames can contain a generated suffix, so do not construct DNS targets from the app name alone.
• Publish: code or container. With code you pick a runtime stack (.NET, Java, Node.js, Python, PHP) and version; with a container you pick an image, for example from Azure Container Registry.
• Operating system and region: must match the plan.
• Plan: an existing one or a new one.

az webapp create -g rg-web -p plan-shop -n shop-contoso-web --runtime "NODE:24-lts"
az webapp config appsettings set -g rg-web -n shop-contoso-web \
  --settings API_URL=https://api.contoso.example
az webapp deploy -g rg-web -n shop-contoso-web --src-path app.zip --type zip

These Bash commands assume the resource group and a deployable Node.js ZIP already exist. Check the currently supported Linux runtimes with az webapp list-runtimes --os linux; Microsoft manages supported runtime patches. Use a custom container when an exact runtime image must be pinned.

Application settings are exposed to the app as environment variables and override values in configuration files. Connection strings are a separate list that also surfaces as prefixed environment variables. Settings can reference Key Vault secrets (@Microsoft.KeyVault(...)) when the app has a managed identity with access. Enable Always On (Basic and above) so a low-traffic app is not unloaded after idle time.

Certificates, TLS and custom domains

Mapping a custom domain

Every app has the default *.azurewebsites.net name. To use www.contoso.com:

1. Create a DNS record at your DNS provider (Azure DNS or elsewhere). Use a CNAME record from www to the app’s assigned default hostname for subdomains, or an A record to the app's inbound IP for the apex domain (contoso.com).
2. Add a TXT record asuid.www containing the app's custom domain verification ID, which proves ownership. For an apex domain use asuid instead of asuid.www. Keep the verification record to help prevent subdomain takeover.
3. In the app, open Custom domains, add the hostname and validate.

Custom domains require a tier above Free (Shared is the lowest that allows them).

Certificates and TLS

For a managed certificate, keep the documented DNS validation path valid: a subdomain CNAME must point directly to the app or supported Traffic Manager endpoint; an intermediate CNAME can prevent issuance or renewal. If CAA records exist, allow the documented DigiCert issuer. An apex domain uses the app’s inbound A record. Check these conditions again before changing DNS.

After the certificate exists you create a TLS/SSL binding between the hostname and the certificate. Prefer SNI SSL (no dedicated IP). Then harden the app:

• HTTPS Only: redirects HTTP to HTTPS.
• Minimum TLS version: set to 1.2 or higher to refuse older protocols.
• Client certificates: optionally require mutual TLS.

Backup

App Service offers automatic backups and custom backups on supported Basic, Standard, Premium and Isolated tiers. They have different storage, size and retention rules.

New linked MySQL/PostgreSQL backup configurations were removed in November 2025; new Azure SQL linked backup configurations were removed in April 2026. Existing linked database configurations are scheduled to stop working on March 31, 2028. Configure each database service’s native backup and point-in-time recovery instead. App content and configuration recovery do not by themselves recover a consistent database.

Custom backups require storage connectivity, permissions and a valid SAS; storage firewalls or private networking can block them. Protect mounted Azure Storage and other external data with their own recovery policies; an app backup is not a backup of every connected service. Restoring stops the target app or slot. Prefer a separate slot, review the restored configuration and database compatibility, then swap only after testing.

Networking settings

Two ideas are often confused. VNet integration controls how the app calls out into a network; it does not give the app a private inbound address. A private endpoint controls how clients reach the app; it does not give the app outbound access to the VNet. A private application that also calls a private database needs both. A private endpoint can coexist with the public endpoint when public network access is enabled; explicitly disable public network access for private-only inbound access and configure private DNS. VNet integration requires a dedicated, empty delegated subnet (delegation to Microsoft.Web/serverFarms).

Access restrictions are evaluated by priority; the first matching rule wins. The unmatched-rule action is configurable; explicitly check it rather than assuming every configuration ends in deny. A separate rule set controls the SCM site (Kudu), which you may want to lock down more tightly than the main site.

Deployment slots

What a slot is

A deployment slot is a live app with its own hostname, configuration and content, running in the same plan as the production app. Typical flow: deploy to staging, warm it up and test at shop-staging.azurewebsites.net, then swap staging with production. Azure applies production's slot-specific settings to the staging instance, warms it up and redirects traffic to reduce release interruption. Worker recycling can interrupt long-running operations. Swapping back restores the previous app version, but does not undo database writes, schema changes or other external effects.

Requirements and behaviour:

• Standard tier or above. Slots share the plan's resources, so heavy load tests in a slot can affect production.
• App settings and connection strings are swapped with the app unless marked "Deployment slot setting" (sticky). Mark environment-specific values (a database connection string, a feature flag) as slot settings so they stay with the slot.
• Swap with preview applies the target’s settings to the source first so you can validate before completing. It is not supported when App Service authentication is enabled on either slot.
• Traffic routing (testing in production) sends a percentage of production traffic to a slot, for example 10%, before a full swap.
• Slots have their own hostname bindings, custom domain/TLS bindings and managed identity. These are not swapped. Certificate objects can be shared within the webspace; distinguish the certificate from its binding. VNet integration is also not swapped. Auto swap is not supported for Linux web apps or Web App for Containers.

Worked example: staged release with controlled database changes

Scenario. Fabrikam runs fabrikam-shop on a Basic B2 plan. Releases cause a minute of downtime and sometimes break the app because the new code ships before configuration. The manager wants a staging environment, low-interruption releases, separate staging and production databases, and fast application rollback. Database migrations must be controlled separately.

Step 1 – Tier. Basic has no slots. Scale the plan up to Standard (or Premium), selecting enough CPU and memory for the existing B2 workload and both slots; S1 is not automatically a capacity upgrade.

Step 2 – Create the slot. az webapp deployment slot create -g rg-web -n fabrikam-shop --slot staging --configuration-source fabrikam-shop. This clones the production configuration. Before deploying or starting test workloads, replace production secrets and connection strings in staging.

Step 3 – Sticky settings. Mark ConnectionStrings:Db and ENVIRONMENT as Deployment slot settings in both slots, with the production values on production and the staging values on staging. During swap warm-up, production’s sticky settings are applied to the source workers: new code can therefore connect to the production database before traffic switches. Sticky flags alone do not isolate side effects. Use backward-compatible schemas, disable startup migrations and control background jobs during warm-up.

Step 4 – Release. Deploy the new package to staging, test the staging URL, then run az webapp deployment slot swap -g rg-web -n fabrikam-shop --slot staging --target-slot production. The source instances warm up using target configuration, then traffic is rerouted. Test that warm-up does not modify either database unexpectedly.

Step 5 – Rollback. If errors appear, swap again; the previous version is now in the staging slot. Verify database compatibility first; swapping cannot reverse a migration or a completed transaction.

Why alternatives are weaker. Deploying straight to production gives downtime and no rollback. Scaling out to two instances does not remove the configuration risk. A second app in a separate plan costs more and requires a separate deployment and traffic-switching design.

Worked example: scaling a plan that hosts three apps

Scenario. One S2 plan hosts a public website, an internal admin portal and a reporting API. CPU reaches 95% each weekday at 9:00 for about an hour. Only the website matters at that time, but all apps slow down. The company wants to keep costs low.

Reasoning. Because the load is predictable, a scheduled autoscale profile for weekday mornings (minimum 4 instances) with CPU rules as a safety net is cheaper than permanently running more instances. If the reporting API is the culprit, moving it to its own plan isolates the impact. Scaling up to S3 helps CPU per instance but raises cost all day.

Check. Autoscale needs Standard or above (the plan is S2, so it qualifies) and changes the plan capacity shared by all three apps in the default configuration.

Pitfalls and exam tips

• Stopping an app doesn't stop the plan's cost. Scale down or delete the plan.
• Slots start at Standard. If a scenario requires slots on a Basic plan, scale up first.
• Azure Monitor autoscale is plan-level and starts at Standard. Add both out and in rules.
• Sticky settings: forgetting "deployment slot setting" sends staging connection strings to production after a swap.
• Managed certificates are free and auto-renewing but do not cover wildcards; wildcard needs a purchased or imported certificate.
• A vs. CNAME records: apex domains use A (plus TXT); subdomains use CNAME (plus TXT asuid).
• VNet integration is outbound; private endpoint is inbound.
• Custom backups need your storage container; automatic backups do not. Neither replaces controlled deployment and database recovery.
• Custom domain on Free is not possible; Shared or higher is required, and TLS bindings need Basic or higher.

Exam tip: When the scenario says "without downtime" or "roll back quickly", think deployment slot swap. When it says "only reachable from the corporate network", compare access restrictions (allow list over the public endpoint) with a private endpoint with public network access explicitly disabled.

Mini case study: Tailspin Toys campaign site

Tailspin Toys launches a holiday campaign site www.tailspintoys.com on App Service.

Requirements:

1. Traffic is low until a TV advert, then spikes five-fold for 30 minutes.
2. Marketing must preview each release before it goes live and support a quick application rollback with backward-compatible database changes.
3. The site must call a private SQL database over a VNet and be reachable by the public.
4. HTTPS with the company's own domain; TLS older than 1.2 is not allowed.
5. Nightly backups retained for 14 days.

Solution.

1. Use a Premium v3 (or Standard) plan with autoscale (minimum 2, maximum 10) and a CPU or HTTP queue scale-out rule plus a scale-in rule. A scheduled profile can raise the minimum shortly before the advert.
2. Add a staging slot; mark environment-specific settings as slot settings; swap for release and swap back for rollback.
3. Enable regional VNet integration in a delegated subnet to reach the SQL private endpoint. Put the database private endpoint in a different subnet from the delegated integration subnet and configure private DNS. The web app’s inbound side stays public, so it does not need its own private endpoint.
4. Add the custom domain with a CNAME for www and the asuid TXT record; create an App Service managed certificate (single hostname) and bind it with SNI SSL; turn on HTTPS Only and set minimum TLS 1.2.
5. Configure a custom backup with a daily schedule and 14-day retention to a storage account.

Commentary. Each requirement maps to one feature: autoscale for spikes, slots for safe release, VNet integration for outbound private access, managed certificate and TLS settings for security, backup for recovery. A web-app private endpoint is unnecessary for this requirement; adding one does not automatically remove public access when that access remains explicitly enabled. Database backup and restore must be planned separately from the web-app backup.

Key terms

• App Service plan: the compute (OS, region, size, instances) shared by apps.
• Scale up / scale out: bigger instances versus more instances.
• Autoscale: rule-based or scheduled instance count changes (Standard and above).
• Deployment slot: a live staging copy of an app that can be swapped with production.
• Slot setting (sticky): configuration value that stays with the slot during a swap.
• App Service managed certificate: free, auto-renewed single-host certificate.
• SNI SSL binding: certificate binding that uses Server Name Indication.
• Access restrictions: inbound IP and subnet allow or deny rules.
• Private endpoint: private inbound IP in your VNet for the app.
• VNet integration: outbound connectivity from the app into a VNet.
• Always On: keeps the app loaded between requests.

Summary checklist

• I can explain plan versus app and choose a tier from required features (slots and autoscale need Standard).
• I can scale up, scale out and configure autoscale with both out and in rules.
• I can create an app, set app settings, connection strings and a runtime stack.
• I can map a custom domain (CNAME or A plus asuid TXT) and bind a certificate.
• I can enforce HTTPS Only and a minimum TLS version.
• I can distinguish automatic backups from custom storage-backed backups and plan database recovery separately.
• I can distinguish access restrictions, private endpoints and VNet integration.
• I can use slots, sticky settings, swap, swap with preview and rollback.

Continue learning

For a container-based web app, compare Azure containers and registry authentication. Learn how to secure access to Azure virtual networks when designing private database connectivity, and review Azure DNS and load-balancing configuration before changing a production hostname.

Official sources

• AZ-104 study guide: https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/az-104 (opens in a new tab)
• App Service plans overview: https://learn.microsoft.com/en-us/azure/app-service/overview-hosting-plans (opens in a new tab)
• Azure subscription and service limits (App Service tier limits): https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits (opens in a new tab)
• Set up staging environments: https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots (opens in a new tab)
• Back up and restore an app: https://learn.microsoft.com/en-us/azure/app-service/manage-backup (opens in a new tab)
• Custom domain and TLS: https://learn.microsoft.com/en-us/azure/app-service/configure-ssl-certificate (opens in a new tab)
• Microsoft documentation: https://learn.microsoft.com/en-us/azure/app-service/manage-scale-per-app (opens in a new tab)
• Microsoft documentation: https://learn.microsoft.com/en-us/azure/app-service/manage-automatic-scaling (opens in a new tab)
• Microsoft documentation: https://learn.microsoft.com/en-us/azure/app-service/app-service-plan-manage (opens in a new tab)
• Microsoft documentation: https://learn.microsoft.com/en-us/azure/app-service/networking/private-endpoint (opens in a new tab)
• Microsoft documentation: https://learn.microsoft.com/en-us/azure/app-service/overview-access-restrictions (opens in a new tab)
• Microsoft documentation: https://learn.microsoft.com/en-us/azure/app-service/networking-features (opens in a new tab)
• Microsoft documentation: https://learn.microsoft.com/en-us/azure/app-service/language-support-policy (opens in a new tab)
• Microsoft documentation: https://learn.microsoft.com/en-us/azure/app-service/quickstart-nodejs (opens in a new tab)