This chapter covers Azure App Service, a fully managed platform for building, deploying, and scaling web apps, REST APIs, and mobile backends. For the AZ-204 exam, App Service is a critical topic — approximately 15-20% of questions touch on compute services, with App Service being the most frequently tested. You will need to understand its architecture, scaling options, deployment slots, authentication, and integration with other Azure services. Mastery of App Service is essential for any Azure developer role.
Jump to a section
Think of Azure App Service as a full-service restaurant where you, the developer, are the chef. You provide the recipe (your code), and the restaurant handles everything else: the building, utilities, tables, staff, and even the fire suppression system. You don't worry about buying stoves (servers) or hiring waitstaff (load balancers) — those are managed by the restaurant. However, you must follow the restaurant's rules: you can only cook in the designated kitchen (sandbox restrictions), you must store ingredients in the provided pantry (storage limits), and you can't install your own industrial fryer (no arbitrary OS-level changes). The restaurant offers different seating sections (App Service Plans) with varying levels of service: the Basic section shares a single waiter (shared VM), while the Premium section gives you a dedicated waiter and a private kitchen (dedicated VMs with isolated network). If a customer complains about slow service, the restaurant can automatically add more waitstaff (autoscale) or switch to a faster kitchen (scale up). You, as the chef, only need to focus on making the food delicious (writing code) and occasionally check the restaurant's performance metrics in the manager's office (Azure portal).
What is Azure App Service?
Azure App Service is a Platform as a Service (PaaS) offering that enables you to build and host web applications, RESTful APIs, and mobile backends in your preferred programming language without managing infrastructure. It supports .NET, .NET Core, Java, Node.js, Python, PHP, and Ruby. App Service runs on Azure App Service Plans, which define the underlying compute resources (VMs) and pricing tier.
App Service Plans and Tiers
An App Service Plan defines a set of compute resources for a web app to run. Each plan has a pricing tier that determines: - Compute resources: CPU, memory, storage - Scalability: Manual or automatic scaling limits - Features: Custom domains, SSL, staging slots, VNet integration, etc.
Tiers include: - Free (F1): Shared infrastructure, 1 GB storage, 60 CPU minutes/day — for testing only. - Shared (D1): Shared infrastructure, 1 GB storage, 240 CPU minutes/day — for testing only. - Basic (B1, B2, B3): Dedicated VMs, supports manual scale up to 3 instances, no autoscale, no staging slots, no custom domains/SSL (with some limitations). - Standard (S1, S2, S3): Dedicated VMs, supports autoscale up to 10 instances (can be increased by support), staging slots, custom domains, SSL, daily backups. - Premium (P1v2, P1v3, etc.): More powerful VMs, up to 30 instances (default), advanced networking (VNet integration, private endpoints), faster storage, more staging slots. - Isolated (I1, I2, I3): Runs on dedicated, isolated VMs in an App Service Environment (ASE) for maximum security and scale.
Default values:
Default number of instances in Standard tier: 1 (can scale up to 10, up to 30 with request).
Default autoscale rules: None — you must configure.
Default health check path: / (can be customized).
Default session affinity (ARR cookie): Enabled for Standard and above.
How App Service Works Internally
When you create an App Service, Azure provisions a sandboxed environment on a VM. The VM runs a sandbox that isolates each app. The sandbox has:
- File system: Each app has its own D:\home directory (on Windows) or /home (on Linux). This is persistent storage shared across all instances of the app. The total storage depends on the tier (e.g., 1 GB for Free, 10 GB for Standard, 250 GB for Premium).
- Memory and CPU: Each app is limited to the resources of its plan tier. The sandbox enforces quotas.
- Network: Outbound connections are allowed; inbound traffic goes through the Azure load balancer. The sandbox prevents listening on arbitrary ports (only ports 80 and 443 are exposed).
Scaling: When you scale out (add instances), App Service creates additional sandboxes on different VMs (or the same VM if capacity allows). Each instance runs your code independently. A load balancer distributes requests across instances. If session affinity is enabled (via ARR cookie), the load balancer routes subsequent requests from the same client to the same instance.
Autoscale: You can configure autoscale rules based on metrics like CPU %, memory %, or HTTP queue length. Autoscale is only available in Standard, Premium, and Isolated tiers. The autoscale engine uses a cool-down period of 5-10 minutes to avoid flapping (rapid scaling in and out).
Deployment Slots
App Service supports deployment slots, which are live apps with their own hostnames. Slot swapping allows you to swap the production slot with a staging slot, enabling zero-downtime deployments. Key points:
Each slot has its own app settings and connection strings (which can be marked as "slot-specific" to stay with the slot during swap).
Standard tier supports 5 slots, Premium supports up to 20.
Traffic routing: You can direct a percentage of traffic to a specific slot (e.g., for A/B testing) without swapping.
Auto swap: When enabled, the app automatically swaps from a staging slot to production after a successful deployment.
Authentication and Authorization
App Service has built-in authentication (EasyAuth) that integrates with Azure AD, Microsoft Account, Facebook, Google, Twitter, and any OpenID Connect provider. When enabled, App Service handles token validation, session management, and redirects. You can configure it in the portal or via app settings:
- WEBSITE_AUTH_ENABLED = True
- WEBSITE_AUTH_DEFAULT_PROVIDER = AzureActiveDirectory (or others)
Networking Features
VNet Integration (Regional): Allows your app to access resources in a virtual network. Only outbound traffic is supported (the app cannot receive inbound traffic from the VNet). Requires Standard or Premium tier.
VNet Integration (Gateway): Uses point-to-site VPN to connect to a VNet. Slower and less recommended.
Private Endpoints: Inbound access from a VNet to your app via a private IP (Isolated tier or Premium v2/v3 with Private Endpoints).
Hybrid Connections: Connect to on-premises resources via Azure Relay.
Backup and Restore
App Service can automatically back up your app's files and databases (Azure SQL, MySQL, etc.) to an Azure Storage account. Backups are taken every 1-12 hours (configurable). You can restore to the same app or a different app. Only Standard and Premium tiers support backups.
Monitoring and Diagnostics
App Service integrates with Azure Monitor. You can:
View live metrics (CPU, memory, requests, errors) in the portal.
Enable application logging (filesystem or blob storage) for debugging.
Use Application Insights for advanced monitoring (distributed tracing, dependency tracking).
Set up alerts based on metrics.
Interactions with Related Services
Azure DevOps / GitHub Actions: CI/CD pipelines can deploy directly to App Service.
Azure Functions: Share the same App Service Plan (Hosting Plan) — you can run Functions on the same plan as web apps.
Azure SQL Database: Common backend database; connection strings are stored in app settings.
Azure Storage: Used for backups, static content, or logs.
Azure Front Door / Traffic Manager: For global load balancing and CDN.
Command Examples
Create an App Service Plan and Web App using Azure CLI:
az appservice plan create --name myPlan --resource-group myRG --sku S1 --is-linux
az webapp create --name myApp --plan myPlan --resource-group myRG --runtime "PYTHON|3.9"Deploy from a local Git repository:
az webapp deployment source config-local-git --name myApp --resource-group myRG
git remote add azure <url>
git push azure mainConfigure autoscale:
az monitor autoscale create --resource-group myRG --resource myApp --resource-type Microsoft.Web/sites --name myAutoscale --count 2 --min-count 1 --max-count 10
az monitor autoscale rule create --autoscale-name myAutoscale --resource-group myRG --scale out --condition "Percentage CPU > 80 avg 5m" --scale-count 1 --cooldown 10Create an App Service Plan
First, define the compute resources for your app. Choose a pricing tier (e.g., S1 for Standard). The plan determines the VM size, number of instances, and features. Use Azure CLI: `az appservice plan create --name myPlan --resource-group myRG --sku S1`. The plan can host multiple web apps, but all share the same resources. For Linux apps, add `--is-linux`. The plan is regional; you cannot change the region after creation.
Create the Web App
Next, create the web app within the plan. Specify the runtime stack (e.g., .NET 6, Node 14). Use Azure CLI: `az webapp create --name myApp --plan myPlan --resource-group myRG --runtime "DOTNET|6.0"`. The name must be globally unique (it becomes part of the URL `myApp.azurewebsites.net`). Behind the scenes, Azure provisions the sandbox environment and configures the load balancer.
Configure Application Settings
Set environment variables (app settings) and connection strings. These are injected into the app at runtime. Use Azure CLI: `az webapp config appsettings set --name myApp --resource-group myRG --settings "KEY=VALUE"`. Settings are stored encrypted and can be marked as slot-specific to persist during slot swaps. Common settings include database connection strings, API keys, and framework-specific configurations.
Deploy Application Code
Deploy your code via Git, FTP, ZIP deploy, or CI/CD. For local Git, enable it: `az webapp deployment source config-local-git --name myApp --resource-group myRG`. Then add the remote and push. The Kudu service (or Oryx for Linux) processes the deployment, runs build scripts if needed, and places files in the `site/wwwroot` directory. The app restarts automatically after deployment.
Scale the App
Scale manually or configure autoscale. For manual scale, go to the portal or use CLI: `az appservice plan update --name myPlan --resource-group myRG --number-of-workers 3`. For autoscale, define rules based on metrics like CPU or memory. Autoscale only works in Standard and above tiers. The cool-down period prevents rapid scaling. After scaling, new instances are added within a few minutes.
Scenario 1: E-commerce Platform with Seasonal Traffic
A retail company runs an e-commerce site on Azure App Service. During Black Friday, traffic spikes to 10x normal. They use the Standard tier with autoscale configured to scale out when CPU exceeds 70% for 5 minutes, up to 20 instances (after requesting a quota increase). They also use deployment slots to stage a new feature before swapping to production. The app uses Azure SQL Database with connection strings stored as slot-specific settings to ensure the staging slot points to a separate database. Misconfiguration: forgetting to mark connection strings as slot-specific caused the staging slot to accidentally use the production database during a swap, leading to data corruption. Lesson: always use slot-specific settings for any resource that should not be shared between slots.
Scenario 2: API Backend with Private Network Access
A financial services company hosts a REST API on App Service that must access an Azure SQL Database inside a VNet. They use the Premium v2 tier with Regional VNet Integration. They configure the VNet integration in the portal, selecting the VNet and subnet. The API can now connect to the database via its private IP. They also enable Private Endpoints for inbound traffic from a specific VNet, ensuring the API is not accessible from the public internet. Common issue: the VNet integration subnet must be delegated to Microsoft.Web/serverFarms, and the subnet must have a route table that does not force tunnel to on-premises (unless desired).
Scenario 3: Multi-region Deployment with Traffic Manager
A global SaaS provider needs low latency worldwide. They deploy the same web app to App Service instances in three regions (West US, West Europe, Southeast Asia). They use Azure Traffic Manager with performance routing to direct users to the nearest region. Each regional app uses a separate App Service Plan. They configure custom domains with SSL certificates. For disaster recovery, they use Traffic Manager's failover routing. They also enable Application Insights to monitor performance across regions. Challenge: ensuring session state is consistent across regions — they use Azure Redis Cache for distributed session state instead of in-memory session.
AZ-204 Objective Coverage
This chapter directly supports objective 1.3: Develop Azure App Service apps. The exam tests:
Creating and configuring App Service Plans and Web Apps (including scaling, autoscale, and networking)
Using deployment slots (swap, traffic routing, slot-specific settings)
Implementing authentication (EasyAuth) and authorization
Configuring custom domains and SSL certificates
Managing app settings and connection strings
Using Azure CLI and PowerShell for automation
Common Wrong Answers and Traps
Trap: Scaling up vs. scaling out — Many candidates confuse scaling up (increasing VM size) with scaling out (adding instances). The exam asks: "Which action improves performance without changing the underlying VM?". Answer: scaling out. Wrong answer: scaling up (which changes the VM).
Trap: Slot-specific settings — A common question: "You swap a staging slot to production. What happens to the connection string that is not marked as slot-specific?". Wrong answer: it stays with the slot. Correct: it moves with the app (i.e., the production slot gets the staging slot's setting). Slot-specific settings stay with the slot.
Trap: Autoscale limits — The exam states: "You need to scale to 15 instances. What tier do you need?". Many choose Standard (max 10 default). Correct: Premium (max 30 default) or request increase on Standard.
Trap: VNet Integration direction — A question: "Your app needs to be accessed from a VNet.". Many choose Regional VNet Integration. Wrong — that only supports outbound. Correct: Private Endpoint or App Service Environment.
Specific Numbers and Values
Free tier: 1 GB storage, 60 CPU minutes/day
Standard tier: up to 10 instances (default), 5 deployment slots
Premium v2/v3: up to 30 instances (default), 20 slots
Autoscale cool-down: 5-10 minutes
Health check path: default /
Default session affinity: enabled for Standard+
Backup interval: 1-12 hours
Custom domains: supported in Basic and above (Shared/F1 require upgrade)
Edge Cases
Linux vs. Windows: Some features (like VNet integration) have differences. The exam may ask about Linux-specific behaviors (e.g., Oryx build process).
App Service on ASE: Isolated tier runs on dedicated VMs in a VNet — full network isolation.
Containerized apps: App Service supports custom containers (Web App for Containers). The exam may ask about Docker Compose support or registry authentication.
Elimination Strategy
When you see a question about App Service, first identify the tier (if given) — that eliminates many options. For scaling questions, check if the need is for more resources (scale up) or more instances (scale out). For networking, determine if the requirement is inbound or outbound access to a VNet.
App Service is a PaaS for hosting web apps, APIs, and mobile backends — no infrastructure management.
App Service Plan defines compute resources (VM size, instances) and tier (Free, Shared, Basic, Standard, Premium, Isolated).
Scaling out (adding instances) is different from scaling up (bigger VM); autoscale only works in Standard and above.
Deployment slots enable zero-downtime deployments; slot-specific settings stay with the slot during swap.
VNet Integration is outbound-only; Private Endpoints are inbound-only for VNet access.
Built-in authentication (EasyAuth) supports multiple providers and handles token validation.
Default instance limit for Standard is 10, Premium 30; can be increased by support request.
Autoscale cool-down is 5-10 minutes to prevent flapping.
Backups are only available in Standard and Premium tiers; interval 1-12 hours.
Custom domains and SSL certificates are supported from Basic tier upward.
These come up on the exam all the time. Here's how to tell them apart.
Azure App Service
Fully managed PaaS — no OS patching, no infrastructure management
Supports multiple runtimes ( .NET, Java, Node, Python, PHP, Ruby)
Built-in scaling, load balancing, and high availability
Integrated authentication (EasyAuth) and deployment slots
Limited to sandbox — cannot install custom software or change OS
Azure Virtual Machines
IaaS — full control over OS and installed software
Requires manual configuration of runtime and dependencies
Manual scaling and load balancing (though VMSS can help)
No built-in authentication or slot swapping (must implement yourself)
Full control — can install any software, configure firewall, etc.
Mistake
App Service can scale infinitely without changing tiers.
Correct
Each tier has maximum instance limits: Standard (10 default), Premium (30 default), Isolated (100). To exceed these, you must request a quota increase from Azure support.
Mistake
Deployment slots share the same hostname.
Correct
Each slot has its own hostname (e.g., myapp-staging.azurewebsites.net). Only the production slot uses the default hostname (myapp.azurewebsites.net).
Mistake
VNet Integration allows inbound traffic from the VNet.
Correct
Regional VNet Integration only enables outbound traffic from the app to resources in the VNet. For inbound, you need Private Endpoints or an App Service Environment.
Mistake
App Service supports any operating system level configuration.
Correct
App Service runs in a sandbox. You cannot install custom software or modify the OS. For custom environments, use Web App for Containers or Azure Virtual Machines.
Mistake
Autoscale works instantly when a metric threshold is crossed.
Correct
Autoscale has a cool-down period (default 5-10 minutes) to prevent flapping. Scaling actions take time to provision new instances.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, but not directly as a continuous background task. App Service is designed for request-driven apps. For background tasks, use WebJobs (continuous or triggered) or Azure Functions. WebJobs run in the same sandbox as the web app and can be triggered by a schedule or queue message. For long-running tasks, consider Azure Functions on a dedicated plan.
First, you must have a Basic tier or higher (Free/Shared do not support custom domains). In the portal, go to Custom Domains, add your domain, and verify ownership by adding a TXT or CNAME record. Then configure the DNS record (A record for root domain, CNAME for subdomain). Finally, bind an SSL certificate (you can use Azure App Service Managed Certificate for free, or upload your own).
During a swap, the production slot and staging slot exchange their app settings (unless marked as slot-specific) and deployment content. The swap is warm — the staging slot is already running the new code, so there is no cold start. The process takes a few seconds. You can also perform a swap with preview to validate before finalizing.
Yes, you can create multiple web apps (or API apps, mobile apps) within the same plan. They share the same VM resources (CPU, memory, instances). This is cost-effective but can lead to resource contention. Each app is isolated in its own sandbox, but the total resource usage is capped by the plan's tier.
Autoscale is available for Standard, Premium, and Isolated tiers. In the portal, go to the App Service Plan (not the web app), then Scale Out (App Service Plan). You can define rules based on metrics like CPU percentage, memory, or HTTP queue length. You can also set instance limits (min, max, default). Use CLI: `az monitor autoscale create` and `az monitor autoscale rule create`.
Azure Functions is a serverless compute service for event-driven, short-lived functions. It shares the same underlying App Service infrastructure but is billed per execution and can scale to zero. App Service is for long-running web apps and APIs. Functions can run on a Consumption plan (serverless) or on an App Service Plan (dedicated).
Enable application logging (Filesystem or Blob) in the portal under App Service logs. Review the stdout and error logs. You can also stream logs in real-time using `az webapp log tail`. For .NET apps, enable detailed errors in web.config. For deeper diagnostics, use Application Insights to capture exceptions and dependencies.
You've just covered App Service Development — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?