App Service is one of the most important services on the AZ-204 exam. You need to clearly understand the tier structure, deployment slots, autoscaling, app settings, and diagnostic logging.
What Is App Service?
Think of an apartment complex. The entire complex is the App Service Plan (infrastructure), and each apartment unit is an individual app. Just as the size of the complex (tier) determines the number of units and available amenities, the tier of the App Service Plan determines which features are available.
App Service is a fully managed platform (PaaS) that lets you run web apps, REST APIs, and mobile backends without managing servers.
App Service Plan Tiers
An App Service Plan is a group of virtual machines on which your apps run. You can host multiple apps on the same Plan, and they all share the same computing resources.
| Tier | Features | Use Case | |------|---------|---------| | Free / Shared | Free or shared infrastructure, no deployment slots, limited custom domains | Learning and experimentation | | Basic | Dedicated VMs, manual scaling, no deployment slots | Small-scale apps | | Standard | Autoscaling, 5 deployment slots, backup, custom domain + SSL | General production | | Premium | High-performance VMs, 20 deployment slots, VNet integration | High-traffic apps | | Isolated (ASE) | Dedicated virtual network, highest security, App Service Environment | Finance, healthcare, compliance |
Key point: Deployment Slots and Autoscaling are only available in the Standard tier and above.
Deployment Slots
A deployment slot is a feature that lets you independently run multiple environments (staging, QA, production, etc.) within the same App Service. It is similar to a "tasting counter" at a restaurant. Before serving a new dish to customers, the staff first tests it at the tasting counter. If there are no issues, it goes on the main menu (production).
Slot Swap
After thorough testing in the staging slot, swap it with production in a single click. Because the app warms up before the swap completes, there is no downtime.
Zero-downtime deployment: The existing version keeps serving traffic until the new version is ready Rollback: If something goes wrong, immediately swap back to restore the previous version Auto Swap: Automatically swap with production when deployment to staging is complete (useful for CI/CD)
Sticky Settings
Some slot settings stay fixed to their slot and do not move when a swap occurs. For example, if you set a database connection string differently for each slot and mark it as sticky, the staging slot always uses the test database and production always uses the production database.
Sticky (Slot setting): Settings that remain in the slot after a swap (e.g., connection strings, specific app settings) Non-sticky: Settings that move together during a swap (e.g., general app settings)
Autoscaling
Just like a restaurant that assigns more staff during a lunch rush and fewer staff when it is quiet, App Service automatically increases or decreases the number of instances based on traffic.
Scaling Methods
| Method | Description | Example | |--------|-------------|---------| | Rule-based | Scale out or in when a metric crosses a threshold | Add one instance when CPU exceeds 80% | | Schedule-based | Pre-scale at specific times of day | Scale to 3 instances every day at 9 AM |
Supported metrics: CPU usage, memory usage, HTTP queue length, request count Scale Out: Increase the number of instances (horizontal scaling) Scale Up: Move to a larger VM tier (vertical scaling)
App Settings
App Settings inject environment variables into your app. Instead of writing passwords or API keys directly in code, you receive configuration values from outside. It is like not writing a safe combination in your code but entering it externally at the safe itself.
App Settings: Key-value pairs that code reads as environment variables Connection Strings: Database connection information (ADO.NET, MySQL, etc.) Key Vault Reference: Read app setting values directly from Azure Key Vault. Secrets are not stored in App Service, improving security.
App Settings Slot Behavior
If you mark an app setting as a slot setting, it does not move during a swap. Conversely, app settings that are not slot settings move together during a swap.
Diagnostic Logging
Used to find the cause when something goes wrong with your app. Just as a doctor examines test results when diagnosing a patient, you use diagnostic logging to analyze the state of your app.
| Log Type | Description | Supported OS | |----------|-------------|-------------| | Application Logging | Logs written by app code (console output, etc.) | Windows / Linux | | Web Server Logging | HTTP request/response records (IIS logs) | Windows | | Detailed Error Messages | Save HTTP 4xx/5xx error pages | Windows | | Failed Request Tracing | Detailed processing trace of failed requests | Windows |
Log destinations: App Service file system or Azure Blob Storage Log streaming: View live logs via the Azure Portal or Azure CLI
Exam Key Points
"Minimum tier that supports deployment slots and autoscaling" -- Standard
"Dedicated network, highest security, compliance" -- Isolated (ASE)
"Switch staging to production without downtime" -- Slot Swap
"Settings that stay in a slot after a swap" -- Sticky Settings
"Immediately restore the previous version when something goes wrong" -- Slot Swap rollback
"Automatically scale instances based on CPU / memory / HTTP queue" -- Rule-based autoscaling
"Inject configuration without putting passwords in code" -- App Settings
"Read app setting values directly from Key Vault" -- Key Vault Reference
"HTTP request/response records (IIS logs)" -- Web Server Logging
"Logs written directly by app code" -- Application Logging
"Scale Out vs Scale Up" -- Out = more instances / Up = move to a larger VM