An App Service plan controls the compute envelope
An Azure App Service plan determines the hosting capacity, tier, region and scaling envelope for web apps running in the plan. The web app defines application runtime, configuration and network-facing behavior. Several apps may share a plan and its resources, so adding an application does not necessarily provision an isolated compute fleet. For Microsoft AZ-104, this distinction is essential when an application slows down, needs a feature on a higher tier, or requires more instances.
Imagine a support API with a custom domain, HTTPS, a private backend and zero-surprise releases. Choose the plan based on expected memory, CPU, traffic, resilience and required slots or networking features. Do not assume every App Service tier supports all capabilities. A seemingly inexpensive tier can be inappropriate when the application’s security or release requirements cannot be met.
Separate scaling up from scaling out
Scale-up changes the plan’s capacity characteristics or pricing tier. Scale-out changes instance count within supported bounds. A memory-bound app may benefit from a different size, while an app with independent concurrent requests might scale horizontally. Both changes affect shared apps in the same plan and can have billing implications. Review measured load and the plan’s supported limits before changing configuration.
Use a sandbox web app to compare one scale-up choice and a scaling rule. Check actual instance count, error rate, response time and cost under controlled test load. Do not claim that setting an autoscale minimum of two instances guarantees application availability; database dependencies, application health and state management still matter.
Configure an application endpoint and TLS
A web app can respond at a platform-provided hostname, but a custom DNS name must be proven by the required validation records before clients can reliably use it. Map the hostname to the correct application, set supported DNS records, then confirm resolution, HTTPS and certificate binding. DNS propagation and TLS certificate issuance are separate stages; an app may be reachable on the platform hostname while its custom endpoint fails.
Choose a supported managed or uploaded certificate according to the application and service tier. Maintain certificate ownership and renewal. Verify that the desired HTTPS-only or minimum TLS policy is applied and test from a client. The presence of a certificate object alone is not proof traffic is encrypted end to end or that every redirect and binding is correct. Use Microsoft TLS guidance for current limitations.
Understand outbound VNet integration and inbound access
App Service virtual network integration is primarily an outbound connectivity mechanism for an app to reach supported network resources; it is not automatically the same as publishing the app privately. Private endpoints, access restrictions and frontends address different ingress designs. Draw arrows for customer-to-app traffic and app-to-database traffic before selecting a network feature.
Test an app connecting to a private backend under an approved configuration. Confirm name resolution, service route, port and destination authorization. When the app returns a connection timeout, inspect DNS and routing as well as target firewall rules. Giving the app a more privileged identity does not fix an unresolvable private hostname.
Plan application backup and recovery explicitly
App Service provides automatic backups on supported pricing tiers and optional custom backups that require configuration and a storage destination. Those mechanisms are not interchangeable. Automatic backups cover supported app content and certain configuration, but they do not back up a linked database. Custom backups may offer scheduled or on-demand control, but their supported size, storage authentication and networking conditions must be checked for the actual App Service tier and deployment. Microsoft’s App Service backup and restore guidance distinguishes those behaviors.
First decide what a restore must recover. Application files are not the same as persistent database records, private-endpoint assignments, custom domain and TLS bindings, managed identities, application monitoring or the full release pipeline. Some settings and integrations must be recreated or separately protected. For a stateful web app, the database needs its own service-supported backup and restore process even when the web content can be recovered from App Service backups.
Next, test the network and authorization path to the custom-backup destination. A custom backup configured to use a protected storage account can fail when network integration or storage firewall rules stop the app reaching that account. A successful application request to a private backend does not establish that backup storage is accessible; inspect the intended VNet integration and destination access separately. Do not place active storage credentials into a published runbook to make the test easier.
For a restore rehearsal, use a disposable app or supported staging slot. Capture an approved backup, change only a harmless test file or configuration item, and restore through the documented path. Record expected downtime, the target app or slot, restored content and configuration, and settings that require manual re-establishment. An existing slot’s file contents can be overwritten during restoration, so the target choice is part of the change-control decision.
Finally test both the HTTP endpoint and a representative database-backed operation; verify HTTPS, DNS, network integration, identity and monitoring independently where they are part of the application. A green backup or restore job is evidence of a platform operation, not proof that customers can sign in or that a transaction will work. The exercise is illustrative and must not be reported as an executed Azure test without actual recorded results.
Use deployment slots as controlled release boundaries
Deployment slots let supported App Service apps keep staging and production configurations and swap compatible application content. Slot-specific settings require careful treatment: an incorrect assumption about which values swap can expose a test dependency in production. Decide which secrets and connection strings must remain bound to a slot and test the actual supported behavior in staging.
Deploy a test build to staging, warm the app, inspect health and exercise a known request before approving swap. Use a release plan with a clear rollback path. If the newly promoted version fails under real traffic, a reversible slot strategy can be useful, but it should not be promised to undo irreversible database schema changes automatically. Review the deployment slot documentation for swap rules.
Diagnose service, plan and application failures separately
If the application cannot start, inspect runtime configuration, application logs, supported language stack and resource limits. If it runs but its domain fails, inspect DNS, TLS binding and access restrictions. If outbound calls fail, inspect VNet integration, destination firewall and identity. If requests slow down only at peak hours, look at instance metrics and the dependencies rather than immediately recreating the app.
The current Microsoft AZ-104 exam objectives measure App Service plans, scale, TLS, custom DNS, backups, networking and slots. An end-to-end administrator exercise should demonstrate each through evidence. A candidate who can identify which layer failed has stronger preparation than one who memorizes menus without testing the configured endpoint.
Rehearse a release and diagnose failures by the affected layer
Use a disposable web application and a supported App Service plan, then record its DNS name, certificate binding, instance count and expected backend request. If a staging slot is supported, deploy a harmless application change there and check readiness before promotion. Record which configuration values remain slot-specific and which could follow a swap. A slot swap is not a database rollback: preserve a separate plan for irreversible schema or persistent-data changes.
Introduce one failure at a time. If a custom hostname fails while the platform hostname works, check DNS ownership, records and TLS binding. If the app answers HTTPS requests but cannot reach a private database, investigate outbound VNet integration, the backend’s DNS resolution, route and firewall rules; App Service’s outbound integration is not the same as private inbound access.
If the app is slow only under load, compare plan capacity and actual dependency latency instead of assuming an extra instance always fixes the problem.
Finish with a release record naming the original and candidate build, staging behavior, observed HTTP and backend results, certificate status, monitoring signals and rollback owner. Test recovery of application content separately from a supported database restore, because a green App Service backup job does not prove that every dependent workload or connection string is recoverable. This is a proposed exercise; report successful outcomes only after they have been observed in an approved environment.