AZ-104
Deep Dive
Microsoft's PaaS for hosting web apps, REST APIs, and mobile backends. The AZ-104 exam tests App Service Plans, deployment slots, scaling, and networking.
Contents
Azure App Service is a fully managed HTTP PaaS platform. It hosts web apps, REST APIs, WebJobs, and mobile applications without managing servers or the OS. It supports .NET, Node.js, Python, Java, PHP, Ruby, and Docker containers.
App Service automatically manages: OS patching, infrastructure scaling, load balancing, TLS certificates, and basic high availability.
Web App
HTTP/HTTPS web applications. Code or container deploys. Multiple runtimes. Ideal for websites, portals, enterprise applications.
API App
REST APIs. Built-in Swagger/OpenAPI. CORS configured. Technically the same as a Web App but with integrated API tooling.
WebJob
Background tasks that run on the same plan as a Web App. Can be continuous or scheduled (cron). A lightweight alternative to Azure Functions.
The App Service Plan defines the underlying compute resources (region, vCPUs, RAM, number of instances). Apps within a plan share the same resources. Multiple apps on one plan = economy of scale.
Plan vs App — the key relationship
App Service Plan
The "server farm" — defines region, OS (Windows/Linux), tier, and number of instances. Billed by the plan, not by the apps.
App Service (the app)
The application that lives inside the plan. A plan can host multiple apps. They all share the same compute resources of the plan.
Important: if the plan has 2 instances and there are 3 apps, each instance runs all 3 apps. It's not that each app gets 2 instances of its own.
Combination restrictions
Windows vs Linux
A plan is either Windows OR Linux — you cannot mix apps of both OSes on the same plan.
Free/Shared vs Paid
On the Free and Shared tiers, apps share resources with apps from OTHER customers (multitenancy). On Basic and above: VMs dedicated solely to you.
Isolated (ASE)
App Service Environment: dedicated infrastructure inside your VNet. Maximum isolation, higher cost. For compliance and apps requiring a private VNet.
| Tier | SKUs | Instances | Key features | SLA |
|---|---|---|---|---|
| Free | F1 | 1 (shared) | No custom domain, no SSL, 60 min CPU/day | No SLA |
| Shared | D1 | 1 (shared) | Custom domain, no SSL | No SLA |
| Basic | B1, B2, B3 | Up to 3 dedicated | Custom domain + SSL, manual scale, no autoscale, no slots | 99.95% |
| Standard | S1, S2, S3 | Up to 10 dedicated | Autoscale, 5 deployment slots, unlimited custom domains + SSL, backups | 99.95% |
| Premium v2/v3 | P1v3, P2v3, P3v3 | Up to 30 dedicated | Everything in Standard plus more RAM/CPU, 20 slots, VNet integration, Private Endpoints | 99.95% |
| Isolated v2 (ASE) | I1v2, I2v2, I3v2 | Up to 100 | Everything in Premium plus dedicated VNet, inbound/outbound in VNet, no mandatory public IP | 99.95% |
For the exam
→ Deployment Slots: Basic has none. Standard = 5. Premium = 20.
→ Autoscale: only from Standard and above.
→ VNet Integration: available from Standard and above (outbound to VNet). Inbound requires Isolated or a Private Endpoint.
→ Custom domains + SSL: from Basic onward.
GitHub Actions / Azure DevOps
Automated CI/CD. Every push/PR can trigger a build + deploy to App Service. Azure provides pre-configured GitHub Actions workflows.
Recommended for production. Deployment slots + swap for zero-downtime.
ZIP Deploy / War Deploy
Upload a ZIP or WAR file directly via REST API or az webapp deploy. Simple, no CI/CD pipeline to configure.
Useful for demos, POCs, or quick deploys from scripts.
Container (Docker)
Deploy a Docker image from Docker Hub, Azure Container Registry, or GitHub Container Registry. The app runs inside the container.
For apps with specific OS dependencies or an unconventional stack.
FTP / FTPS
Upload files directly via FTP/FTPS. Deployment credentials in Portal → Deployment Center. Not recommended for production.
Legacy. Only use when there is no other option.
A Deployment Slot is an additional live instance of the app with its own URL (app-staging.azurewebsites.net). A swap exchanges production traffic with the slot (and vice versa) atomically — zero downtime.
Deployment flow with slots
Sticky vs. non-sticky configuration
Each slot has its own configuration (app settings, connection strings). On swap, the configuration is exchanged along with the code — unless it's marked as a "Slot Setting" (sticky).
• Sticky (slot setting): stays with the slot even after a swap. E.g.: the staging connection string pointing to the staging DB.
• Non-sticky: travels with the code. E.g.: feature flags, configuration variables.
Traffic Routing — canary deployment
You can route a % of production traffic to a slot. E.g.: 10% to the "v2" slot to test with real users before the full swap. Configured in Portal → Deployment Slots → Traffic %.
Scale Up (vertical) vs Scale Out (horizontal)
Scale Up (vertical)
Switch to a larger plan (more vCPUs/RAM). E.g.: S1 → S3. Involves moving the app to a bigger VM — there may be a brief interruption.
Scale Out (horizontal)
Add more instances of the same size. Load is distributed across instances via the built-in load balancer. No interruption.
Autoscale (Standard+)
Automatically scales the number of instances based on metric rules or a time-based schedule.
Metric-based
Scale out when average CPU > 70% for 10 min. Scale in when CPU < 30% for 15 min. Metrics: CPU, memory, requests, latency, message queue length.
Schedule-based
Increase instances on Mondays at 8:00 AM, reduce on Fridays at 7:00 PM. For predictable workloads (business hours).
Combined
Base schedule rules plus metric-based adjustment on top of the scheduled baseline.
Minimum and maximum instance counts are always configurable. Autoscale never exceeds the defined maximum.
| Feature | Traffic direction | Minimum tier | What it's for |
|---|---|---|---|
| VNet Integration | Outbound from the app | Standard / Basic (regional) | So the app can reach resources in a VNet: private DBs, VMs, internal services |
| Private Endpoint | Inbound to the app | Standard+ | So the app is only reachable from inside the VNet (no public IP) |
| App Service Environment (ASE) | Inbound and outbound in VNet | Isolated v2 | Full isolation: the app lives inside the VNet. No mandatory public IP. |
| Access Restrictions | Inbound | All | Whitelist of IPs or CIDR ranges. Block everything except trusted IPs or Application Gateway. |
| Hybrid Connections | Outbound | Basic+ | Reach on-premises resources without a VPN or ExpressRoute (relayed via Service Bus) |
App Settings (environment variables)
App settings are injected as environment variables into the app's process. They override any settings in the app's config file (web.config, appsettings.json).
• Portal → App Service → Configuration → Application settings
• Visible in plain text by default to anyone with portal access
• Key Vault Reference: instead of the value, put @Microsoft.KeyVault(SecretUri=...) — the app reads the secret from Key Vault at runtime
• Mark as "Deployment slot setting" to make it sticky to the slot (not exchanged on swap)
Connection Strings
Similar to App Settings but typed by DB engine (SQL Server, PostgreSQL, MySQL, Custom). In .NET, they are automatically injected as connection strings, overriding those in web.config/appsettings.
• Can be marked sticky just like app settings
• Support Key Vault References so connection strings aren't exposed in the portal
• For other languages (Python, Node): injected as environment variables prefixed with SQLCONNSTR_, MYSQLCONNSTR_, etc.
Best practice: use Key Vault References instead of hardcoding credentials in App Settings. The app's Managed Identity reads the secret from KV automatically.
Azure Functions is Azure's serverless platform. It runs code in response to events (triggers) without managing servers. It scales to zero automatically.
Consumption Plan
Scales to zero. You pay per execution and CPU time. 5-minute timeout by default (10 min max). No always-on instances.
Best for
Low-traffic APIs, event processing, automation.
Flex Consumption (new)
Consumption with native VNet Integration, optional pre-provisioned instances, more concurrency control. The future of Functions.
Best for
Apps that need VNet access along with the serverless model.
Premium Plan
Pre-warmed instances (no cold start). VNet Integration. No maximum timeout. Unlimited horizontal scale. More expensive.
Best for
APIs with latency SLAs, access to VNet resources, long-running executions.
Common Azure Functions triggers
| Trigger | Triggering event | Typical use case |
|---|---|---|
| HTTP | HTTP/HTTPS request | REST API, webhook, SPA backend |
| Timer | Cron expression (e.g.: "0 0 * * * *") | Scheduled jobs, nightly cleanup, periodic reports |
| Blob Storage | New/modified file in a container | Process an uploaded image, generate a thumbnail |
| Queue Storage | Message in a queue | Asynchronous processing, service decoupling |
| Service Bus | Message on a Service Bus topic/queue | Enterprise messaging, pub/sub patterns |
| Cosmos DB | Cosmos DB change feed | Data synchronization, read-model projections |
| Event Grid | Event from any Azure source | React to Azure Monitor, Storage, and other events |
Did you get this topic?
Test what you just learned
A team deployed a new version of their app to the 'staging' deployment slot. When swapping with production, the app failed because it tried to connect to the production database using the staging slot's connection string. How should the slots have been configured to avoid this?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.