A web app deployment can pass a build pipeline yet fail for users because the App Service plan is undersized, the app settings differ between environments, or a certificate binding is wrong. The AZ-104 exam expects administrators to deploy and manage App Service as a platform, not simply upload application code. Plans supply capacity and certain features; apps provide the running application configuration; deployment slots allow supported release and swap workflows.
An administrator who understands these boundaries can tell whether a production failure calls for a scaling change, a rollback, a missing setting or a network repair. Treat the app as a service with identity, secrets, DNS, TLS, health and monitoring—not as a website URL in the portal.
The App Service plan is a shared capacity boundary
An App Service plan defines the hosting tier, region and underlying compute capacity for eligible apps. Multiple apps in one plan can share resources, which can be economical but also creates contention. Scaling up changes the plan’s instance capability; scaling out increases instance count when supported. Selecting a premium tier for one app does not automatically isolate it from other busy applications on the same plan.
Before resizing, inspect CPU, memory, connections, response time and workload variation for each app sharing the plan. One noisy background job can affect a customer-facing frontend. Separate critical apps into different plans when resource isolation or release independence matters. This decision should be guided by measured behavior and availability needs rather than by tier labels alone.
Two web apps sharing the same App Service plan can affect one another’s capacity even though they have separate URLs and configuration. If both apps experience high CPU after a release, adding one app-level setting may not resolve the contention. Inspect plan SKU, instance count, supported scaling features, per-instance CPU and memory and the actual traffic mix. A premium plan may provide deployment slots and scale options that a basic tier does not; current SKU capabilities matter more than a dated exam diagram. Design capacity at plan scope and set ownership for apps that share it.
Choose runtime and deployment method deliberately
App Service supports multiple runtime and deployment approaches with tier and platform dependencies. Decide whether the source will be built into a deployment artifact or a custom container and whether configuration belongs in application settings, environment variables or secret references. The deployment mechanism should produce a traceable version and allow a supported rollback.
A successful deployment log proves only that the platform accepted an artifact. It does not prove the application can reach its database, resolve an internal hostname or use its identity. Build a health endpoint that checks meaningful dependencies without exposing secrets or turning a momentary downstream delay into a cascade of unnecessary restarts. Keep build credentials separate from production runtime identities.
Deployment artifacts and configuration have different lifecycles. An app can deploy successfully while failing at startup because an environment variable or connection string points at the wrong backend. Separate code/package deployment from infrastructure and app settings; manage each in a repeatable configuration system. Avoid exposing credentials in deployment logs, and use supported secret-reference patterns where the platform and identity configuration permit them. For a Python or .NET app, test the exact runtime version and warm-up behavior that production uses instead of treating the ZIP upload or GitHub Action completion status as application health.
Understand deployment slots and what a swap moves
Deployment slots are supported in certain App Service tiers. They let an operator deploy and validate a candidate version separately from production and then swap routing/configuration according to the platform’s slot behavior. Some settings are slot-specific and should stay with the slot; others participate in the swap. Mistaking a sticky connection string or secret for swappable configuration can direct production traffic at test data.
Before swapping, inventory connection strings, application settings, managed identities, authentication configuration and external dependencies. Test the target version through its slot URL and any supported warm-up path. A controlled swap changes the active app version but does not roll back an incompatible database migration. Document what exactly the swap reverses and what still requires another action.
Slots help stage and swap supported application configurations, but swapping traffic is not the same as rolling back database schema changes. Imagine a new release that expects a renamed column. Even if a slot swap is quick, old code may fail after the schema migrates. Create forward/backward compatible database changes first and know which settings are slot-sticky versus those swapped with the application. After swap, verify the production hostname, authentication, settings, dependencies and health probe; if something fails, the rollback procedure must restore a coherent application state, not merely move a slot label back.
Treat TLS and custom-domain configuration as a chain
A custom domain needs the right DNS records, validated ownership and a certificate or managed-certificate configuration that meets the platform requirements. HTTPS requests can fail before reaching application code if the hostname resolves incorrectly or the certificate binding doesn’t cover it. Matching the certificate’s subject alternative names, chain and renewal status matters more than seeing a green deployment badge.
For a migration from one domain to another, validate the new hostname independently, plan DNS TTL behavior and preserve the original path until clients have transitioned. Enforce suitable HTTPS/TLS settings without silently breaking legacy integrations that require an agreed migration. Do not fix a hostname mismatch by disabling certificate validation in clients.
A certificate incident often begins before it looks like a certificate incident. A custom hostname’s DNS points at an old endpoint, validation succeeds for the wrong host, or the certificate is missing one of the required names. Check the requested hostname, authoritative DNS record, ownership verification, deployed certificate binding and expiration chain in that order. Then confirm the App Service’s required TLS version and HTTPS-only behavior match the client population. If a legacy integration cannot negotiate the configured protocol, disabling HTTPS is not a viable production fix; plan a client upgrade or an explicitly approved compatibility boundary.
Know App Service authentication versus application authorization
App Service authentication features can integrate with identity providers, but whether a signed-in user may read a specific business record is still an application authorization decision. Azure RBAC for administering the App Service resource is a separate management-plane concern. Don’t conflate a web app’s user login with who may restart the Azure resource or view its configuration.
Managed identity lets the running app obtain tokens for supported Azure services. The receiving service still needs a suitable role assignment or permission, and network access may be restricted independently. A 401 from a downstream API or a 403 from Key Vault deserves targeted diagnostics; assigning Contributor to the web app’s resource group is usually not the correct repair.
Scale based on observed user traffic
Autoscale behavior depends on hosting plan and configuration. A backend serving predictable weekday traffic may benefit from schedules, while bursty workloads need monitored metrics and safe min/max bounds. Changes to instance count do not compensate for inefficient database queries or an unavailable dependency, so measure end-to-end latency and errors along with App Service CPU.
If new instances start before an application’s caches are warm, response-time spikes can be mistaken for more demand, creating a feedback loop. Understand startup and readiness behavior, connection limits, queueing and downstream quotas. Configure alerts on failure rate and request latency, not just hardware percentage. Test scale-out under representative load and watch how work redistributes among instances.
Scale up changes the compute capability of instances; scale out changes their number. A CPU-bound app may benefit from more cores, while a horizontally scalable request service may be better served by more instances. Connection exhaustion, slow database calls and external API rate limits do not necessarily disappear with either action. Inspect request latency, memory, CPU, dependency timings and concurrency before modifying scale. If the app uses in-memory session state, additional instances can create inconsistent user experience unless sessions are externalized or an appropriate affinity strategy is intentionally selected.
Diagnose a failed release in the right order
A failed slot swap should prompt a comparison of artifact versions, slot settings, dependencies and live health. If the production site reports certificate errors, investigate DNS and TLS bindings separately. If the application can start but returns database timeouts, inspect connectivity, name resolution, identity and target service health. Keep a timeline of the deployment operation and any simultaneous configuration changes.
For an emergency rollback, decide whether swapping back is safe given stateful changes. If the new version has written data in a schema the old version cannot understand, the operational recovery may require a coordinated application and database plan. Stop adding random portal settings to the incident. A concise evidence-based diagnosis shortens downtime more effectively than an uncontrolled series of hotfixes.
Run an AZ-104 App Service deployment drill
Create a low-cost test plan and app, configure a test custom domain only if you control one, and create a staging slot where supported. Deploy a changed response, validate the staging endpoint, record slot-specific settings and execute a controlled swap. Confirm the version visible to users and which settings remained with each slot.
Then produce one deliberate failure: a wrong configuration value or an inaccessible downstream resource. Restore service through the appropriate configuration or release action and document each observation. The lab should prove you understand plan capacity, app configuration, slot isolation, TLS and operational rollback as separate systems that must work together.
A useful release drill deploys a simple app to a staging slot where supported, validates configuration and health independently, then swaps under controlled conditions. Run one expected failure: point a disposable setting at a nonexistent dependency and observe which logs and health indicators change. Restore it, re-test the endpoint and document the steps needed for a safe swap-back. Separately map a temporary test hostname and verify TLS binding, then remove the DNS record during cleanup. The proof is an application that remains reachable throughout planned changes, with measurable recovery when a configuration mistake occurs.