What's changed: Added §3.3 "AI Services, Copilot, and Responsible AI" covering the AI area added to AZ-900 in the Jan 2026 update (Azure AI Foundry/OpenAI/AI services/AI Search/Content Safety, the Copilot family, and the six Responsible AI principles)
3.1Compute Services
Understand Azure compute options—virtual machines, containers (ACI/AKS), App Service, and Functions—and the trade-off between control (you manage) and convenience (managed for you).
Running an app needs compute. Azure offers several options, chosen by the same axis as the previous chapter service models—the trade-off between how much you control and how much you hand off (effort). They range from virtual machines where you control down to the OS, to Azure Functions where you never think about servers (serverless); you pick per requirement.
3.1.1Virtual machines (VMs)
Azure Virtual Machines are the core of IaaS and the most flexible compute, letting you manage the OS and above (middleware, app, data). You pick Windows/Linux, choose a size (CPU/memory), and install any software. In return, operations like OS patching and backups are your responsibility. VMs suit lift-and-shift of existing servers and special software stacks.
3.1.1.1Scaling and availability for VMs
- Virtual machine scale sets (VMSS): manage many identical VMs as a set and autoscale (add/remove instances) with load.
- Availability set: distributes VMs across fault domains (power/network units) and update domains (maintenance units) so hardware failures or planned updates do not take everything down at once (within a region).
- Availability zone: spreads VMs across physically separated datacenters within a region, surviving a datacenter-level failure (broader protection than an availability set).
- Azure Virtual Desktop (AVD): delivers Windows desktops/apps from the cloud for secure access anywhere (VDI).
A common confusion is the division between VMSS (scaling) and availability sets/zones (availability). VMSS is for "handle load by adding instances"; availability sets/zones are for "stay up even if one fails." Choose by whether you are protecting performance (throughput) or availability (uptime)—and you can combine them.
3.1.2Containers
Containers are lightweight execution units bundling an app with its dependencies; they start faster than VMs and are highly portable. Azure splits them by use: Azure Container Instances (ACI) runs containers simply and one-off without orchestration overhead, while Azure Kubernetes Service (AKS) is managed Kubernetes for operating many containers in production (auto-placement, self-healing, scaling). Rule of thumb: "small and simple → ACI, large-scale production → AKS."
3.1.3App Service and serverless
Azure App Service hosts web apps and APIs quickly on PaaS. The provider manages the OS and patches, so you focus on deploying code, with easy scaling and custom domains/TLS.
Azure Functions is the flagship of serverless (FaaS): it runs a function only when an event arrives (HTTP request, queue message, etc.) and bills only for execution. With near-zero idle cost, it suits intermittent processing, automation, and notifications. If App Service "hosts an app continuously," Functions is "small logic that runs only on events."
| Service | Model | You manage | Typical use |
|---|---|---|---|
| Virtual Machines | IaaS | OS and above | Lift-and-shift, special stacks |
| ACI | Containers (simple) | Container / app | One-off, lightweight containers |
| AKS | Containers (orchestration) | Containers / app config | Large-scale container production |
| App Service | PaaS | App and data | Web apps/APIs quickly |
| Functions | Serverless/FaaS | Just the code | Event-driven, automation |
Rules of thumb: want OS-level control → VM, containers simply → ACI / at scale → AKS, web apps quickly → App Service, just run code on events → Functions (serverless).
Scenario: composing a web service. Host the always-on web/API on App Service (PaaS) with autoscaling; split heavy, event-only work like thumbnail generation into Functions (serverless); keep just a legacy, OS-dependent helper batch on a VM. Even one system mixes multiple compute types where each fits best.
Watch the mix-ups: (1) VMSS (autoscale = performance) vs availability set/zone (redundancy = availability)—different goals. (2) ACI (one-off, simple) vs AKS (large-scale orchestration). (3) App Service (always hosting) vs Functions (only on events). Beware options that swap these roles.
Q. Availability set vs availability zone? An availability set spreads across racks (fault/update domains) within a datacenter, while an availability zone spreads across separate datacenters within a region—zones withstand a broader class of failures.
Common points: VM = IaaS/most control / VMSS = autoscaling set / availability set & zone = availability / AKS = managed Kubernetes / ACI = simple containers / App Service = web PaaS / Functions = serverless / AVD = cloud desktops.
3.1.4Section summary
- VM (most control, IaaS); scale with VMSS (autoscale), availability via availability sets/zones
- ACI (simple containers) / AKS (managed Kubernetes) / App Service (web PaaS)
- Functions = serverless (event-driven, pay per use); AVD = cloud desktops
- Choose along the control vs effort axis; even one system mixes several types where each fits
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which "serverless" service runs code on events with no server management?
Q2. Which service provides managed Kubernetes (container orchestration)?
Q3. Which compute option gives the most control, including the OS?
Q4. Which feature manages many identical VMs and autoscales their count with load?
Q5. Which service best runs a small, one-off container simply?
Q6. Which service delivers Windows desktops from the cloud for use anywhere?