Operating an Azure App Service application requires more than deploying its code. This AZ-104 guide examines shared App Service plan capacity, scaling, deployment slots, configuration consistency, custom DNS, TLS certificates and the difference between application rollback and data recovery.
An app is different from its compute plan
Azure App Service runs web apps without requiring the team to maintain the host operating system. The App Service plan determines region, operating system, instance size, scale and pricing tier. Each web app has its own configuration and deployment, but apps sharing the same plan consume the plan’s underlying compute. This distinction matters when a deployment looks healthy but latency rises in another app on the same plan.
The current AZ-104 exam blueprint includes configuring App Service plans, scaling, certificates, custom DNS, backups, networking and deployment slots. This is not a repeat of Azure VM availability sets, zones and scale sets: App Service abstracts infrastructure placement but introduces a service-specific application lifecycle.
Select a plan from the workload
Imagine a fictional order-processing API that serves ordinary customer lookups and occasionally experiences sharp traffic bursts. Define its expected memory and CPU profile, acceptable latency, dependent data services, region, availability requirement and deployment schedule before choosing a pricing tier. A low-cost development tier cannot be assumed to support slots, advanced networking and every production feature.
A scale-up changes per-instance capacity or the plan tier. Scale-out changes instance count. Scaling out a service with application sessions stored only in process memory can cause consistency failures. Scaling up a service whose main delay comes from a database query may increase expense without fixing the bottleneck. Diagnose the request path before modifying the plan.
When two apps share a plan, both may feel the effect of scaling policies and noisy neighbors. Record which services can share capacity and which need a separate failure or billing boundary. Do not claim separate domain names imply independently provisioned compute.
Scaling requires application readiness
Choose metrics that reflect the user experience, such as request latency, failures, CPU, queue backlog and dependency performance. Scale triggers need cooldowns, minimum capacity and maximum capacity appropriate to the actual tier and budget. A poorly designed rule can oscillate and spend more while users see no improvement.
Background jobs and session state deserve special attention. A scale-in can terminate a worker that holds unfinished work in memory. Reliable apps place necessary state in a supported durable store and make retried operations safe. Test whether operations are completed after capacity changes, not simply whether the platform reports another instance.
Slot deployment is controlled application change
On eligible Standard, Premium and Isolated App Service tiers, deployment slots let teams place a candidate app version alongside production. The slot has its own URL. A swap can move a validated application build into production while handling supported configuration differences. It does not give each slot a wholly independent pool of compute.
Prepare a staging slot with safe, nonproduction test data. Before swapping, verify the application’s actual dependency behavior and the current Microsoft’s slot setting matrix. Some settings remain with the slot and some are swapped. Do not assume a staging connection string should become a production connection string simply because code moved.
The slot’s access restrictions, TLS hostname bindings, managed identity and virtual network settings need deliberate review. A private endpoint is not automatically cloned into a newly created slot. If an app passes tests under one path but production uses another, the successful test may not predict the user’s experience after swap.
Database compatibility and rollback
A web-app swap cannot undo every external side effect. Consider a staging release that performs a database schema migration not compatible with the previous version. Swapping back the web app may restore old code while leaving the production database changed. Release readiness therefore requires a plan for schema compatibility, feature flags, data migrations and irreversible messages. Use an approved change window for risky migrations, not an assumption that every application action is reversible.
An operator should check the build revision, package configuration, health endpoint, database migration status and secret references before a swap. After the swap, measure real requests and correct transaction outcomes; a green control-plane deployment event is insufficient evidence the whole service is healthy. If a release fails, record which parts must be rolled back separately and whether a manual reconciliation is required.
Custom domains, certificates and HTTPS
A custom hostname requires both the correct DNS entry and an App Service domain binding. A DNS record pointing at the right service does not prove the app will present a certificate for that hostname. A valid uploaded or managed certificate is not enough if the app is not configured to use it. Test DNS, host binding, certificate lifetime and a real TLS handshake as separate conditions.
If a fictitious service is assigned api.example.test, a controlled test should verify domain ownership, the required TXT or CNAME/A configuration where applicable, and the binding provided by the App Service platform. Keep HTTPS-only settings and the minimum TLS version aligned with organization security policy. Never copy a development certificate into a production release merely because it removes a browser error.
Certificate renewal is an operations responsibility. Record expiry, ownership and whether the active binding uses the renewed certificate. When a team says "the cert was updated", verify what the live endpoint actually serves. Some slot-level hostname and TLS settings stay with the target slot and need independent acceptance checks after a swap.
Inbound access and outbound integration
App Service access restrictions can limit incoming callers under supported configurations, while virtual network integration affects outbound paths toward protected dependencies. These features answer different questions; enabling one does not automatically configure the other. A service that loads in a browser may still be unable to reach a storage account privately because of routing, DNS or resource permissions.
Troubleshoot by identifying exactly where the flow stops. Does the application resolve the dependency hostname to the intended address? Does a subnet route reach the service? Does its identity hold the appropriate authorization? A firewall exception cannot grant a missing Azure data-role permission, and an administrator role cannot repair broken private DNS.
A realistic staging test should execute a harmless read from the intended dependent service using the slot’s actual configured identity. If the response is denied, distinguish 401/403 authorization behavior from socket timeout or DNS failure before changing security settings.
Backup is not a release switch
Backup and restore options depend on the plan and application configuration. A slot swap or previous deployment artifact can restore app content without restoring an external database or storage account. Define a recovery inventory: deployment package, environment settings, certificates, identity associations, data store, observability configuration and any queued tasks.
Azure App Service supports automatic and configurable custom backups in supported plans, but these are not equivalent to reverting a slot deployment or recovering an independent database. Automatic backups require no initial storage configuration and have a platform-managed schedule and retention. Custom backups can be taken on demand or scheduled, require a suitable storage account, and have different size, retention and authentication constraints. Design a synthetic restore test in which an app is re-created from yesterday’s backup while its external database was modified today: restoring app files cannot simply be assumed to roll back the database safely. To reduce production downtime during a restore, Microsoft recommends restoring to a deployment slot first and then swapping when appropriate; the target app or slot stops during restore and the chosen destination’s files may be overwritten. Verify connection strings, TLS/custom domains, dependencies, data consistency and app transactions before announcing recovery. Record the backup type, supported plan and exactly what was recovered, not just a green backup job indicator.
For an internal synthetic application, run a restore to an isolated test resource and then verify the complete business workflow. A backup reporting "successful" does not prove credentials, external connections and database schema are compatible with the restored app. Record the actual recovery time and whether the resulting environment met the business owner’s recovery objective.
A controlled release failure exercise
Create a mock release manifest for version 2 of the fictional order API. Version 2 has a new connection string, a certificate nearing expiration and a database change that may not be backwards compatible. Define what the staging checks should catch. The connection string should be correctly scoped to staging; a certificate should bind to the intended hostname; the database change must have a safe rollout and rollback path.
Next simulate a scale-out event. Does the app continue a user workflow when traffic shifts between instances? Can the downstream database sustain the additional requests? Inspect request failures and end-to-end latency rather than simply counting instances. Finally simulate a swap and an immediate health regression. The team should know exactly which application artifact to restore and which data changes require a separate response.
These examples are design exercises, not deployed tests. For a real Azure lab, verify the features against the current plan tier and documentation and use a harmless subscription with an explicit cleanup step.
What AZ-104 administrators need to demonstrate
An Azure administrator should be able to identify which plan hosts an app, how many apps share its capacity, which scale rule controls instance changes and why a deployment slot may preserve some settings. They should also verify custom domains, HTTPS/TLS binding, access restrictions, network integration and recovery readiness.
Safe App Service administration is a sequence of observable deployment decisions, not a declaration that the application is running. Use a staging slot to validate configuration and health checks, confirm which settings remain slot-specific during swap, inspect production TLS bindings and certificate ownership, and watch the real customer transaction after the change. An autoscale rule that improves CPU metrics can still leave a broken dependency or a misconfigured connection string. When examining third-party AZ-104 App Service practice questions, trace which component actually controls the failure and whether a slot swap, plan scaling or rollback is the least disruptive response. A successful status page alone is not proof of a safe production release.
Monitor an App Service change as an application event
After a scaling or slot deployment action, establish whether performance improved. Measure end-to-end request failure rates and dependency latency from the service actually receiving production traffic. A faster response for a lightweight health endpoint can coexist with broken customer transactions. Conversely, a brief startup spike may recover safely without a full rollback if the application’s release criteria explicitly allow it.
Separate the scaling action from a database connection issue. If the API starts timing out after scale-out, review connection-pool limits and whether each additional instance created new concurrent backend connections. Adding more instances may multiply pressure on the dependency. If only a slot swap changed application behavior, compare relevant sticky settings, build identifiers and the deployed artifact instead of immediately resizing the plan.
An operator can build a useful deployment record from the plan tier, slot names, app version, tested source configuration, approved TLS/hostname state, health metrics and rollback owner. This makes it possible to explain why a published endpoint was accepted or rejected without guessing that a platform deployment succeeded solely because Azure reported a completed control-plane command.