6.4 App Service Plan, Apps, and Runtime Configuration

App Service plan versus app

Azure App Service is a platform service for hosting web apps, APIs, and custom container workloads. The App Service plan is the compute container for one or more apps. It defines the region, OS type, pricing tier, worker size, and scale capacity. The app defines the hostname, runtime stack, code or container settings, app settings, authentication options, identity, custom domains, TLS bindings, deployment source, and logs.

A useful exam rule: if the question asks how much compute exists or which paid features are available, look at the plan. If it asks what code runs, what environment variable is set, what container image is used, or what identity the app uses, look at the app.

Portal creation path: Azure portal > App Services > Create > Web App. During creation, the portal asks for resource group, name, publish model, runtime stack or container, OS, region, and App Service plan. For custom containers, choose container publishing and provide the image source, registry, image, and tag.

CLI example for code-based app:

az appservice plan create \
  --resource-group rg-web \
  --name asp-prod-linux \
  --location eastus \
  --is-linux \
  --sku P1v3

az webapp create \
  --resource-group rg-web \
  --plan asp-prod-linux \
  --name exam-web-prod \
  --runtime "NODE:20-lts"

CLI example for container-based app:

az webapp create \
  --resource-group rg-web \
  --plan asp-prod-linux \
  --name exam-container-web \
  --deployment-container-image-name examacr104.azurecr.io/apps/web:v1

Plan tier decisions

Plan tier is one of the most tested App Service topics because many features depend on it. Free and Shared are useful for low-cost testing but are limited. Basic supports dedicated compute for simple production apps. Standard adds features commonly associated with production such as autoscale and deployment slots. Premium tiers provide stronger scale and advanced networking-related capabilities. Isolated tiers are associated with App Service Environment requirements.

Do not memorize only price names. Read the requirement. If the scenario asks for deployment slots, custom domain with TLS, scale out, or VNet integration, a very low tier is usually wrong. If the scenario says several apps are in one plan and one app consumes all CPU, the fix may be scaling the plan, moving the noisy app to a separate plan, or configuring autoscale depending on constraints.

Plan sharing is important. Multiple apps in the same App Service plan share the same worker resources. This can reduce cost for related apps, but it also means heavy apps can affect others. The exam may ask why two apps show degraded performance at the same time; if they share a plan, check plan CPU, memory, and instance count.

Runtime configuration

App settings are environment variables exposed to the application. Connection strings are stored separately in the App Service configuration surface. Both can be changed without rebuilding the application package. For slot-based deployments, some settings can be marked as slot settings so they remain with the slot during swaps. This is critical for values like database connection strings, feature flags, and external service endpoints.

Portal path: App Service > Configuration > Application settings for app settings and connection strings. App Service > Identity enables system-assigned or user-assigned managed identity. App Service > Deployment Center configures deployment source. App Service > Log stream and App Service logs help troubleshoot startup and runtime failures.

CLI examples:

az webapp config appsettings set \
  --resource-group rg-web \
  --name exam-web-prod \
  --settings ENVIRONMENT=prod API_BASE_URL=https://api.contoso.com

az webapp identity assign \
  --resource-group rg-web \
  --name exam-web-prod

For custom containers, the container must listen on the expected port. If the app starts but App Service cannot reach it, configure the port setting expected by the platform, commonly through app settings such as WEBSITES_PORT for Linux custom containers when needed. Always inspect container logs before changing DNS or certificates.

Portal and CLI choice

Use the portal for one-off setup, certificate binding, identity confirmation, log streaming, and visual scale configuration. Use CLI, ARM, or Bicep for repeatable plan creation, app settings, and deployment automation. AZ-104 includes interpretation tasks, so you should understand what commands change.

Example interpretation: az webapp config appsettings set does not scale the app. It updates environment variables. az appservice plan update --sku P1v3 changes the plan tier. az webapp deployment slot swap swaps slots. az webapp config container set changes container settings.

Troubleshooting runtime failures

Use this sequence:

1. Confirm the App Service plan is running and not exhausted.
2. Confirm the app runtime stack or container image matches the application.
3. Confirm app settings and connection strings are present.
4. Confirm managed identity has required permissions to dependencies.
5. Confirm the app listens on the expected port.
6. Use logs before making infrastructure changes.

If a web app cannot access Key Vault, changing the App Service plan size is rarely the first fix. Check managed identity, Key Vault access model, RBAC or access policy, firewall, and private endpoint/DNS if used. If a web app returns 502 after a custom container deployment, check startup logs, image pull success, exposed port, and health behavior.

Exam traps

Do not confuse App Service plan region with app code location. Apps in a plan run where the plan is located. Do not create a Windows plan for a Linux container app or assume you can mix Windows and Linux apps freely in the same plan. OS type is a plan-level decision.

Do not assume every App Service feature exists in Free or Shared tiers. Do not place unrelated high-traffic production apps into the same plan without considering resource contention. Do not store secrets in source code because App Service offers configuration, managed identities, and integration with secret stores.

The most reliable mental model is: plan equals workers and tier; app equals runtime and behavior; slot equals alternate deployment surface for the same app; deployment source equals how code or images arrive.