Microsoft AZ-204: Azure App Service and Web Apps — Study Guide

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Part of the Microsoft Azure Developer Associate AZ-204 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure App Service is a fully managed HTTP-based hosting platform for web apps, REST APIs, and backend services, supporting code and container workloads on Windows and Linux. It provides first-class features for scaling, deployment workflows, authentication, networking isolation, background processing, and secure configuration. Mastery involves understanding App Service plans and scaling, deployment slots and traffic management, CI/CD integration paths, Easy Auth, custom domains and TLS, WebJobs, App Service Environment (ASE), and secure configuration patterns with Key Vault.

Plans, scaling, and deployment slots

An App Service plan defines the compute resources hosting your apps. All apps in a plan share the same VM pool and scale configuration.

• Pricing tiers:

  • Free (F1)/Shared (D1): Development and testing only. No SLA. No custom TLS. No deployment slots.
  • Basic (B1–B3): Dedicated VMs, manual scale out. No autoscale. Limited features.
  • Standard (S1–S3): Adds autoscale and deployment slots. Production baseline.
  • Premium v2/v3 (P1v2/P1v3+): Newer compute, faster storage, enhanced networking features, zone redundancy (on supported SKUs), and higher scale. Best for enterprise production and high throughput.
  • Isolated (I1v2+) in ASE: Dedicated to a customer’s virtual network with network isolation and massive scale.

• Scale up vs scale out:

  • Scale up moves the plan to a higher SKU for more CPU, memory, faster disks, or advanced capabilities (e.g., Premium v3 for better performance and features).
  • Scale out increases instance count to distribute load horizontally. Standard and above support autoscale with rules based on metrics such as CPU, memory (Linux), HTTP queue length, requests, custom metrics, or schedules. Basic supports only manual scale out. Scaling applies to all apps within a plan.

• Deployment slots and slot swaps:

  • Standard and higher tiers support multiple slots (for example, staging and production). Slots run on the same plan, each with its own host name and configuration.
  • Swap moves the content and runtime state from a source slot to a target slot with near-zero downtime by warming the destination before traffic cutover. Use applicationInitialization (Windows) or health checks to ensure readiness before swap. Swap with preview allows validation before finalizing.
  • Mark configuration entries as slot settings to keep them sticky to the slot during swaps (e.g., database connection strings, secrets, and diagnostic endpoints). Unmarked settings move with code during swap.

• Traffic routing with slots:

  • Route a percentage of live traffic to a non-production slot for canary testing (testing in production). Cookies pin users to a slot after assignment to preserve session consistency.

Deployment and CI/CD: GitHub, Azure DevOps, and container registries

Deployment Center integrates common CI/CD flows:

• GitHub Actions:
  • App Service can scaffold a workflow using Oryx build or container deployment. On push to a branch, Actions build and deploy to the selected slot. Support for matrix builds, environments, and secrets. For Linux containers, the workflow can build and push to ACR or Docker Hub, then trigger a web app deployment.
• Azure DevOps:
  • Pipelines (YAML or classic) deliver build and release stages, approvals, environment checks, and multistage gating. Use tasks: Azure Web App, Azure Web App for Container, or AzureCLI for ARM/Bicep-enabled deployments. Variable groups and Key Vault-backed secrets centralize configuration.
• Container registries:
  • App Service for Containers pulls images from ACR, Docker Hub, or private registries. Configure continuous deployment via ACR webhooks to the app; a new image push triggers a pull and restart. Pin by tag or digest. For production safety, use image digests and canary slots before promoting.
• Additional deployment mechanics:
  • Kudu supports Git-based push, Zip Deploy, and Run From Package for reproducible builds. The .deployment file and custom scripts can coordinate build steps before the site serves traffic. For enterprise-grade release hygiene, combine slots with CI/CD to validate health checks and warm-up before swap.

Security, identity, domains, and TLS

App Service authentication/authorization (Easy Auth) offloads identity to the platform without requiring middleware in your code.

• Providers:
  • Microsoft Entra ID (Microsoft identity platform), Google, Facebook, GitHub, and Twitter, plus any OpenID Connect-compatible provider including Entra ID B2C. Configure client IDs/secrets, issuer, and allowed token audiences/scopes. Choose login action (allow anonymous vs require authentication).
• Token store and headers:
  • Enable the token store to cache access/refresh tokens obtained during the sign-in flow, retrievable via /.auth/me and refreshed via /.auth/refresh. App Service injects user claims in request headers (for example, X-MS-CLIENT-PRINCIPAL in Base64) so the app can derive identity without SDK dependencies. Use the platform’s logout endpoint to clear sessions.
• Custom domains:
  • Map CNAME (recommended) or A/ALIAS records to the app’s default hostname. Verify domain ownership with TXT records if required. Bind the custom hostname in App Service.
• SSL/TLS certificates:
  • Enforce HTTPS Only and set minimum TLS version. Bind certificates via SNI (multiple certs per IP) or IP-based SSL (dedicated IP). Upload private certificates (PFX) for production-grade cert control. App Service Managed Certificate provides a free, auto-renewing, domain-validated certificate for non-wildcard hostnames; it cannot be exported and requires a supported tier. Use Key Vault integration to manage and auto-rotate private certs at scale.
• Client certificates (mTLS):
  • Optionally require incoming client certs and pass them to the app for validation. Combine with Web Application Firewall and reverse proxies (for example, Application Gateway) for end-to-end TLS.

Background processing and isolated environments

WebJobs and ASE address background processing and network isolation scenarios.

• WebJobs:
  • Continuous WebJobs run perpetually on each instance of the web app, suitable for queue processing or event loops. Requires Always On (Standard and above) to keep them running. Scale follows the app plan’s instance count; apply singleton behavior in code if only one active worker is desired.
  • Triggered WebJobs run on-demand or on a schedule (CRON via settings.job). Ideal for batch jobs, ETL, or periodic maintenance.
  • WebJobs SDK provides triggers and bindings for Azure Storage Queues, Service Bus queues/topics, Blobs, and Timers with declarative function methods and automatic checkpointing. A queue-triggered WebJob reacts immediately to new messages, scales with app instances, and uses poison queue handling for fault isolation. Logs and dashboards are accessible in Kudu.
• App Service Environment (ASE):
  • ASEv3 hosts App Service plans inside your VNet with Isolated v2 SKUs, providing dedicated compute, data plane isolation, and private IPs. Choose External ASE for public ingress or Internal Load Balancer (ILB) ASE to keep all inbound private within the VNet. Integrate with private DNS, firewalls, and NVA/WAF as needed.
  • ASE allows granular egress control, network inspection, and compliance alignment. It supports large-scale hosting with predictable network boundaries and is billed separately from plan instances.

Configuration, connection strings, and Key Vault references

App configuration is injected at runtime and can be slot-specific.

• App settings:
  • Key-value pairs available to the app as environment variables. Mark as slot settings to keep distinct values per slot. Leverage Health check path to remove unhealthy instances from rotation during rollouts. Changes trigger app restarts unless configured with dynamic reload patterns in your framework.
• Connection strings:
  • Managed separately and surfaced as environment variables; .NET apps also receive provider-specific configuration. Types include SQLAzure, SQLServer, MySQL, PostgreSQL, and Custom. Mark as slot settings where appropriate to avoid swapping secrets.
• Key Vault references:
  • Reference secrets directly in App Settings and Connection Strings using the special syntax @Microsoft.KeyVault(SecretUri=https://<vault>.vault.azure.net/secrets/<name>/<version>) or versionless URIs to pick up rotations automatically. Assign a system- or user-assigned managed identity to the app, then grant it Get secret permissions (RBAC or access policy) on the vault. The platform resolves and refreshes values without exposing secrets in the App Service configuration. To use TLS certificates from Key Vault, import them as certificates or use certificate references supported by the platform.

Deployment slots deep-dive and operational excellence

Use a staging slot as the CI/CD target. After deployment:

• Run warm-up pings and health checks to prime JIT, caches, and database connections.
• Validate configuration differences using slot settings to isolate production secrets and endpoints.
• Perform swap with preview to test the staging slot at the production hostname before finalizing. If errors arise, cancel swap to instantly roll back.
• For progressive delivery, use traffic routing to direct a small percentage to the canary slot and monitor App Insights metrics and logs. Increase gradually, then complete the swap when SLOs hold.

Practical Problem Scenario

Starbucks is launching a new web ordering platform that must handle surges during promotions, integrate with social logins, protect internal APIs, and process background order workflows reliably.

1. Choose Premium v3 App Service plan with two deployment slots (staging, production)

• Why: Premium v3 provides faster CPUs and SSDs for low-latency page loads and higher throughput, plus slots and autoscale. Slots enable zero-downtime swaps and quick rollback under promotional traffic spikes.

2. Implement CI/CD with GitHub Actions to deploy to the staging slot

• Why: GitHub Actions offers repository-native automation. Deploying to staging allows warm-up and validation before any customer traffic is affected. The workflow uses Oryx to build and deploy on push to main, ensuring consistent builds.

3. Enable Easy Auth with Microsoft Entra ID and Google providers; enable Token Store

• Why: Easy Auth offloads OAuth/OIDC flows, reducing custom security code surface. Multiple providers support consumer sign-in preferences. The Token Store makes downstream API calls (for example, loyalty profile microservice) straightforward using cached tokens exposed via /.auth endpoints.

4. Configure custom domains and TLS

• Why: Bind order.starbucks.com via CNAME, enforce HTTPS Only, and set minimum TLS 1.2 for compliance. Use an App Service Managed Certificate for the staging slot to reduce management overhead, and upload a PFX from the corporate CA for production to satisfy brand and certificate policy.

5. Use WebJobs SDK with an Azure Storage Queue trigger for order fulfillment

• Why: A continuous WebJob processes messages as they arrive, decoupling checkout from fulfillment and smoothing peaks. With Always On and plan-based scale-out, throughput increases automatically with additional instances. Poison queue handling isolates bad messages without disrupting the pipeline.

6. Secure outbound secrets with Key Vault references and a system-assigned managed identity

• Why: Secrets never reside in App Service config. The identity has least-privilege access to Key Vault, and versionless secret URIs enable seamless rotation.

7. Protect internal APIs with networking

• Why: Place internal microservices behind a private endpoint; the public web app calls them over VNet Integration (Premium v3) to a secured backend. If stricter isolation is needed in the future, migrate the web tier into an ILB ASE to make all ingress private while maintaining App Service capabilities.

8. Release strategy with canarying and swap

• Why: Route 5% of traffic to staging for live validation during a promotion. Monitor latency, error budgets, and checkout conversion via Application Insights. If healthy, perform a swap with preview; if not, cancel and investigate, preserving customer experience.

All domains · Azure Functions and Serverless Computing →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →