Microsoft AZ-104: Azure App Service and PaaS Compute — Study Guide

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Part of the Microsoft Azure Administrator Associate AZ-104 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure’s PaaS compute portfolio combines fully managed web/app hosting, serverless functions, workflow automation, on-demand containers, and orchestrated containers. As an administrator, success hinges on understanding the boundaries of each service, how they network and authenticate, and how to deploy and scale reliably. This section covers App Service (plans, deployment slots, networking, and built-in auth), Azure Functions and Logic Apps (plans, triggers, connectors), Azure Container Instances and AKS (scheduling, scaling, operational tooling), and the isolated App Service Environment.

App Service and Functions Compute Foundations

App Service Plans determine the compute resource pool for Web Apps, API Apps, and Function Apps running on the dedicated plan. Tiers have distinct capabilities and scaling models:

Free (F1) and Shared (D1) run on shared infrastructure with quotas and no SLA. They are suitable only for experiments. Features like deployment slots, VNet integration, and autoscale are not available.
Basic (B) allocates dedicated VMs at small scale with manual scale-out. It lacks autoscale and deployment slots.
Standard (S) introduces autoscale, multiple instances, daily backups, and deployment slots. It is the entry point for production workloads that need staging.
Premium (Pv2/Pv3) increases CPU/memory, I/O performance, and feature limits (more instances, more slots), and adds advanced networking such as Private Endpoint integration and zone redundancy.
Isolated/Isolated v2 run inside an App Service Environment with single-tenant, dedicated compute inside your virtual network for strict isolation and compliance.

Scaling divides into scale-up (change pricing tier/VM size) and scale-out (change instance count). Autoscale requires Standard and above and is driven by Azure Monitor rules (CPU, memory via App Service Metrics, or custom metrics). Scale operations are per App Service Plan and affect all apps within the plan.

Deployment slots provide live app instances in the same plan to stage changes. Slots exist in Standard and higher, with Standard supporting fewer and Premium/Isolated supporting more. Swap orchestrates a zero-downtime promotion by exchanging slot content and configuration while honoring slot settings (sticky app settings and connection strings that stay with the slot). Swap with preview warms the target slot and evaluates health before completing. Testing in production routes a percentage of production traffic to one or more slots; routing is sticky per client to maintain session affinity during a test ramp.

App Service networking offers controlled outbound and inbound connectivity:

Regional VNet Integration routes outbound traffic into a delegated subnet in a virtual network in the same region. It enables egress to private endpoints, on-premises via VPN/ExpressRoute, and service endpoints. It does not change public inbound behavior.
Private Endpoint publishes the app privately inside your VNet by mapping the app’s frontend to a private IP; combine with access restrictions to enforce private-only ingress outside of ASE.
Hybrid Connections provide outbound TCP connectivity from the app to specific host:port endpoints on-premises or in other networks via Azure Relay, without requiring inbound firewall changes. It is not a general-purpose VNet tunnel and does not support UDP.
Access Restrictions evaluate ordered allow/deny rules for client IPs, service tags, and virtual network traffic (via Private Endpoints or multi-tenant VNet rules). Lock down to specific ranges, VNets, or front-ends to meet compliance.

Built-in Authentication/Authorization (“Easy Auth”) front-ends your app with a hosted auth handler, offloading token validation without code changes. Supported providers include Microsoft Entra ID (Azure AD), Microsoft Account, Google, Facebook, Twitter, and generic OpenID Connect. You can enforce login for all requests or pass-through to the app, set allowed audiences, and restrict to specific tenants. The optional token store caches provider tokens and exposes claims via the /.auth/me endpoint and request headers. Combine with system-assigned managed identity to securely call downstream Azure services.

Azure Functions offers event-driven compute across three hosting models:

Consumption plan is serverless with per-execution, per-GB-second billing and automatic scale-out and scale-to-zero. It has cold starts and no VNet integration for some triggers historically; newer capabilities are broader but network-sensitive workloads should verify support.
Premium plan eliminates cold start with pre-warmed instances, supports VNet integration and Private Endpoints, and scales based on events with min/max instance controls.
Dedicated plan (App Service Plan) runs Functions on your App Service Plan capacity; cost is for reserved instances regardless of use, with optional autoscale at the plan level. Functions triggers include HTTP, Timer, Storage (Queue/Blob/Table), Service Bus, Event Hubs, Event Grid, Cosmos DB, and more, with input/output bindings to connect services declaratively. Durable Functions add stateful orchestration in a code-first model using orchestrator and activity functions, enabling patterns like fan-out/fan-in, async HTTP, human interaction, and sagas. State is persisted in a storage provider (Azure Storage is common), ensuring resilient, replayable workflows.

Cost and scaling behavior differ materially between App Service Plan and Consumption models. App Service Plan charges for the size and count of always-on instances and scales per plan rules. The Functions Consumption model charges only for execution time and memory with automatic concurrency-based scale and scale-to-zero. Premium sits between these, combining reserved warm capacity with burst scaling.

Containers and Kubernetes

Azure Container Instances (ACI) provides on-demand, per-second-billed containers without managing VMs or orchestrators. The unit of deployment is a container group: one or more containers scheduled on the same host, sharing an IP, ports, volumes, and lifecycle. Define CPU/memory per container, expose ports, and mount volumes such as Azure Files, secrets, and emptyDir. Environment variables can be plain or secure (excluded from logs/metadata surfaces). Restart policies control lifecycle: Always (default for long-running services), OnFailure (for jobs that should retry on non-zero exit), and Never (for run-to-completion tasks where you want to inspect exit state without restarts). Networking supports public IPs, private IPs with VNet injection into a delegated subnet, and DNS name labels for public endpoints.

Azure Kubernetes Service (AKS) is a managed Kubernetes control plane with node pools provisioned as Virtual Machine Scale Sets. Node pools differentiate system workloads (kube-system components) from user workloads, support multiple VM sizes, and can run Linux and Windows (Windows requires at least one Linux system pool). Pools can be tainted to control scheduling. Upgrades are orchestrated per pool, and maxPods, availability zones, and ephemeral OS disks are configured at pool creation. The cluster autoscaler integrates with Kubernetes scheduling to modify node counts within min/max bounds when pending pods cannot be scheduled or nodes are underutilized; it respects Pod Disruption Budgets and only scales down when safe. Horizontal Pod Autoscaler complements this by scaling replicas within a Deployment based on metrics.

kubectl basics for cluster administration:

Connect with az aks get-credentials to merge kubeconfig and select context.
Inspect resources: kubectl get nodes/pods/deployments -o wide; kubectl describe for details and events.
Diagnose and interact: kubectl logs for stdout/stderr, kubectl exec -it for interactive troubleshooting.
Apply desired state: kubectl apply -f manifests.yml; use namespaces to scope resources; kubectl config set-context to switch namespaces.

Network plugins (Azure CNI or kubenet), identity (managed identity vs service principal), and RBAC/Entra ID integration determine pod IP allocation, cluster authentication, and authorization. Ensure cluster identity has permissions for load balancers, managed disks, and node resource groups.

Integration, Networking, and Security

Logic Apps provide a managed workflow engine with connectors to hundreds of SaaS and Azure services. A workflow comprises a trigger that starts the run and actions that perform steps. Triggers include HTTP requests, Recurrence, Service Bus messages, Event Grid events, Storage events, and many SaaS events (e.g., when a record is created in Dynamics 365). Actions include control constructs (conditions, loops, switch), data operations (compose, parse JSON, variables), and connector operations (send email, enqueue message, call API). Integration with Azure services is deep:

Service Bus and Event Grid provide reliable messaging and eventing for decoupled architectures.
Functions can be invoked for custom code steps (synchronous HTTP or async via queues).
Managed identity secures access to Key Vault, Storage, SQL, and other Azure resources without secrets. Logic Apps Consumption (multi-tenant) bills per-action execution and connector usage; Logic Apps Standard (single-tenant) runs on the Functions runtime in an App Service Plan or Premium plan, supports local development, VNet integration, private endpoints, and higher throughput. Integration Service Environment (ISE) in Consumption provides VNet isolation for managed connectors when needed.

App Service Environment (ASE) implements the Isolated tier for App Service. Deployed into your virtual network, ASE provides single-tenant, dedicated compute and storage stamps with network control. An external ASE exposes public ingress endpoints; an internal load balancer (ILB) ASE publishes only a private VIP for strictly private access. Apps in an ASE use the Isolated/Isolated v2 pricing tiers. You pay both a stamp fee for the environment and per-instance worker costs. ASE is chosen when compliance, network isolation, or scale requirements exceed multi-tenant App Service capabilities. With ASE v3, deployment and networking are simplified, but the core proposition remains: dedicated, privately addressable App Service with your VNet as the perimeter.

Access governance across these services relies on Azure RBAC for resource actions, managed identities for service-to-service auth, and Conditional Access at the identity plane. For inbound control on App Service, combine Private Endpoints or ILB ASE with access restrictions and WAF-enabled front ends (e.g., Application Gateway or Azure Front Door) as needed. For outbound control, use VNet integration with NSGs, route tables, and private endpoints for data services.

Deployment and Scaling Operations

Reliable releases to App Service use deployment slots to validate health and warm caches before swapping. Mark configuration that differs per environment as “slot settings” so it does not move during swap (e.g., connection strings, feature flags). Use swap with preview to execute health probes or application-specific warm-up endpoints; if unhealthy, abort the swap. During canary, enable traffic routing to direct a small, sticky percentage to a staging slot and incrementally increase. Slot-specific app settings can toggle beta features safely.

Autoscale for App Service Plans is configured on the plan resource using profiles (time-based min/max/default) and rules (metric thresholds with scale step and cool-down). Combine CPU with custom metrics (e.g., queue length) for more accurate scaling. For Functions, Consumption automatically scales; monitor concurrency and configure host.json for per-trigger behaviors (e.g., batch sizes and prefetch for Service Bus). Premium plan scales pre-warmed instances and burst instances; align min instance counts with latency goals.

In containers, ACI restart policies should reflect intent: batch jobs get Never or OnFailure to avoid infinite loops; services use Always. Use environment variables for configuration and Azure Key Vault for secrets, injecting via Managed Identity and startup code or by mounting secrets as volumes where appropriate. In AKS, enable cluster autoscaler with sane min/max bounds per node pool and configure HPAs for critical Deployments. Budget for headroom and set Pod Disruption Budgets to guard availability during upgrades and scale-in. Validate upgrades in a canary node pool before rolling out cluster or pool upgrades broadly.

Practical Problem Scenario

Fabrikam, Inc. runs a customer portal and background processing services. They must modernize to PaaS, enforce private network access to data stores, support blue-green deployments, and run a nightly containerized ETL without managing VMs.

Host the portal on App Service Premium with deployment slots

Create an App Service Plan in Premium v3 for higher performance and more slots, and deploy the Web App with a staging slot.
Configure slot settings for environment-specific values and enable swap with preview and health checks.
Reason: Premium offers autoscale, more slots, Private Endpoint support, and SLA suited for production traffic. Slots provide safe blue-green releases and canary routing.

Enforce private ingress and controlled egress

Enable a Private Endpoint for the Web App and set access restrictions to deny public network.
Configure Regional VNet Integration to a delegated subnet for outbound access to private data stores and on-premises via ExpressRoute.
Reason: Private Endpoint plus restrictions guarantees private-only access; VNet Integration routes egress through the VNet perimeter for consistent firewall policy.

Implement background processing with Azure Functions Premium

Deploy a Function App on a Premium plan with a system-assigned managed identity, using Service Bus and Storage triggers for queue-driven workloads.
Set minimum pre-warmed instances to eliminate cold starts and integrate with the same VNet.
Reason: Premium Functions meets low-latency and VNet requirements while preserving serverless scaling for bursty workloads.

Orchestrate cross-service workflows with Logic Apps Standard

Build workflows to coordinate customer onboarding: trigger on a Service Bus message, call the Function App, write to Storage, and notify via Microsoft 365 connector.
Use managed identity for Key Vault and Storage access and deploy in the same App Service Plan to leverage VNet integration and private endpoints.
Reason: Logic Apps provides resilient, visual orchestration and native connectors; Standard offers VNet integration and single-tenant performance.

Run the nightly ETL in Azure Container Instances

Define a container group with the ETL container, mount an Azure Files share for intermediate data, set secure environment variables, and use restartPolicy: Never.
Attach the group to the VNet delegated subnet for private access to databases.
Reason: ACI delivers per-second, job-oriented compute without cluster overhead and integrates with VNet for data locality and security.

Prepare for containerized microservices with AKS

Create an AKS cluster with a small Linux system node pool and a user node pool sized for expected load, enable cluster autoscaler (min/max bounds), and integrate with Entra ID and Azure CNI for pod-level IPs.
Use kubectl to deploy a canary microservice and set an HPA based on CPU and custom metrics.
Reason: AKS provides enterprise-grade orchestration when services multiply; autoscaler and HPA align capacity with demand and kubectl offers standard operational control.

← Azure Storage · All domains · Azure Databases and Data Services →

Practice these questions → · Timed practice on ExamRoll.io →