An application can be perfectly healthy on a developer laptop and still be misconfigured when published to Azure App Service. It may have an outdated certificate, a DNS record pointing at the wrong endpoint, a staging slot holding production secrets or a plan too small for peak traffic. Administrators need to see App Service as a managed hosting and release environment, not merely a place to upload application code.
A staging slot can return healthy responses and still be unsafe to promote if it points at the wrong database or a certificate and hostname are configured only for production. Azure App Service swaps application content and selected configuration; identities, virtual-network integration and other slot-specific settings do not behave exactly like ordinary app settings. For Microsoft AZ-104 release administration, test the candidate against its real dependency and security boundaries. The operator must know which configuration follows a swap and which stays with its slot.
An App Service plan defines shared capacity
An App Service app holds application configuration and deployment settings, while its App Service plan defines the compute region, operating-system characteristics and pricing tier supporting hosted apps. Several apps may share one plan and therefore share available worker capacity. A noisy application can affect neighbors even if those neighbors have different names and release histories.
Unlike VM availability and scale sets, App Service plan scaling changes the capacity shared by hosted applications rather than the number and configuration of individual guest VMs. An incident review should identify which compute model is actually providing the service.
Scaling up changes the plan tier and available compute characteristics; scaling out changes how many worker instances run apps on the plan. These actions are not the same as scaling a standalone virtual machine. Before changing a plan, identify all dependent apps and consider what a tier change will do to cost, capacity, capabilities and compatible runtime settings.
Higher tiers may offer deployment slots, additional scaling options and networking capabilities not present in entry-level tiers. Do not build a production release process around a feature that the selected tier does not support. A plan choice should be tested against requirements for traffic volume, regional placement, deployment safety and operational ownership.
Custom domains need DNS and certificate coordination
Publishing an app under a company domain involves proving domain ownership and creating the appropriate DNS records. A working default azurewebsites.net address does not prove that the custom hostname is configured correctly. DNS changes may take time to propagate, and clients can continue using cached responses; administrators should test from relevant networks rather than only from their own workstation.
TLS configuration includes obtaining or importing a suitable certificate, binding it to the hostname and planning renewal. An expired certificate produces a user-visible failure even if the application responds perfectly on HTTP or its default host. Document who owns renewal and how an incident will be detected before the expiry date.
Custom-domain troubleshooting should separate name resolution, certificate binding and the route to the application. Azure DNS and load balancing concerns help distinguish a stale DNS answer from a healthy name pointing at a failing service. Do not relax TLS settings merely to conceal a misconfigured hostname.
Deployment slots separate candidate and active versions
A staging slot lets administrators deploy a candidate and test it before directing regular production traffic to that version. With supported App Service plan tiers, slot swapping can promote a validated build while warming the target environment to help avoid unnecessary downtime. This is safer than overwriting production directly and hoping every configuration difference is harmless.
Slot swaps also differ from Container Apps revisions, which manage application versions as deployable revisions. Choose rollback and traffic-shifting procedures for the platform in use rather than assuming the same promotion mechanics across services.
Some settings are slot-specific or sticky and others participate in swaps, so the configuration model must be understood before testing. A staging slot should not accidentally call a live payments endpoint or write to the same production database in a way that changes customer state. Review connection strings, secrets and hostname bindings before a swap, not after.
Prepare a rollback path that reverses the deployment without losing changes made to shared data stores. The application code may swap back quickly, while an incompatible database migration cannot be undone by changing which slot receives traffic. Release design should therefore coordinate application, schema, storage and external service contracts.
A healthy slot needs meaningful tests
A browser request returning HTTP 200 confirms that a route responded; it does not prove database connectivity, authentication, background work and customer operations are correct. Design smoke tests that exercise representative authorized paths and deliberately denied actions. Confirm which configuration and deployment version produced each result.
Logging and alert rules should exist before promotion. Use Azure Monitor and Network Watcher to compare the candidate with a baseline for request failures, latency and dependency reachability. A release that loads faster but fails more customer transactions is not a success.
Production-like testing also requires attention to secrets and user state. A staging slot may need synthetic records or a safe read-only integration mode for sensitive systems. A useful release gate identifies the tests that can run in staging and the additional checks that must occur after live traffic arrives.
Networking features require directional reasoning
Inbound access restrictions, private endpoints and outbound virtual-network integration solve different problems. A service can have restricted inbound traffic while still needing an approved outbound path to a private database. Conversely, a VNet-integrated app is not automatically private to every possible caller. Document inbound and outbound flows separately with DNS and identity requirements.
A private database connection may fail because the app resolves a public endpoint or uses a DNS resolver that cannot see the relevant private zone. Changing a firewall to allow all traffic hides the actual defect. Trace name resolution, route, allowed network and authenticated identity before adjusting exposure.
App Service deployment and runtime access can also come from different identities. The identity that pushes code should not automatically have unrestricted access to customer data, and a runtime managed identity should receive only the roles required by the app. Scope and service capability should drive the assignment.
Backup is not the same as disaster recovery
App Service backup capabilities can protect supported content and configuration, but the application may depend on databases, external storage and other services with separate recovery requirements. A saved app package does not guarantee that a restored site can process customer transactions when its data store is missing or several versions behind.
Establish recovery objectives and test the process. Decide what must be backed up, what can be rebuilt from infrastructure definitions and what data requires its own backup policy. Restore a controlled test app and verify that configuration, secrets and network access are consistent with the intended recovery environment.
Do not treat Backup and Site Recovery as a drop-in recovery mechanism for every App Service workload. Site Recovery coordinates supported workload replication and failover; App Service backups and its external databases have their own recovery procedures. Verify the actual supported restoration path and its dependencies.
Operate cost and capacity as one system
A shared plan can lower operational overhead, but its cost is tied to selected capacity even when traffic is uneven among apps. Right-sizing needs measured CPU, memory and request demand rather than guesses from a short quiet period. If two critical applications share one plan, the operational effect of resizing must be assessed for both.
Capacity decisions have a financial boundary: use Subscriptions, budgets and Advisor to establish the cost owner and budget threshold before choosing a larger plan. A budget can alert when spending rises after a plan upgrade, but it will not automatically return the plan to its previous tier. Define the operator, performance criterion and cost ceiling before an urgent scaling decision.
For AZ-104, build a small App Service exercise: choose a suitable plan, configure a custom domain with TLS, create a staging slot where supported, deploy a candidate, validate the slot and practice the swap/rollback sequence. Then investigate a failure by checking configuration, DNS, identity and telemetry separately. That operational chain is more valuable than memorizing isolated portal settings.
Diagnose an incident across plan, slot and application
Imagine a custom-domain outage immediately after a release. A developer blames the new code, but the default hostname works, staging works and the TLS certificate for the public domain expired overnight. Rolling back the application does not fix a certificate binding. Another incident may show healthy TLS and DNS while the staging slot was accidentally swapped with an incompatible database configuration. These situations look like “the site is down,” yet their remedies belong to different owners and layers.
Use the failing client path to classify the problem. First determine whether the public name resolves as intended and the TLS handshake is valid. Then inspect access restrictions and network routing, the active slot and deployed version, app settings, dependency reachability and application health telemetry. Compare observations from the default domain, custom domain and internal service calls before changing anything. The safest corrective action is the smallest one that addresses the identified boundary.
For a plan scaling incident, identify which applications share capacity, whether the plan has available workers and whether the workload is CPU-, memory-, network- or dependency-bound. Increasing worker count cannot solve an external database deadlock. Conversely, optimizing code cannot repair a plan that lacks a feature required by the release. Keep that reasoning tied to measurements so “scale up” does not become the automatic response to every slow page.
Keep the release environment honest
A slot only protects a release when it reproduces the dependencies that matter. If staging runs against a toy database and an unrestricted network, a successful test cannot prove that production’s managed identity, private storage or resource limits will work after a swap. Record where staging deliberately differs, which effects are simulated and which must be validated immediately after promotion. An explicit limitation is better than a green test report that hides important differences.
The operator also needs to know what to observe after swapping: status codes, authentication failures, database migrations, dependency timeouts, certificate health and resource pressure. Compare these against the release baseline before deciding to roll back. A reverse swap may restore code rapidly, but a bad shared-data migration needs its own recovery procedure. That is why App Service release quality depends on both slot mechanics and surrounding application architecture.