AZ-204 — Runtime choices
Route position
This is the first AZ-204 path after the shared AZ-104 foundation. It turns a program into a deployable workload by separating packaging, hosting, ingress, configuration, scaling, and promotion decisions.
Core idea
Choose the smallest compute boundary that gives the application the control and operational responsibility it actually needs. A container image packages bytes; a registry stores them; a runtime executes them; a deployment process promotes a tested version; telemetry reveals whether the runtime works.
Map / Canvas
Ordered modules
- Container images, ACR, ACI, and Container Apps
- App Service, settings, TLS, slots, and autoscale
- Existing shared notes: Functions, triggers, and bindings.
Key comparisons
VMs provide OS control; App Service provides a managed web runtime; ACI runs an isolated container task; Container Apps manages container revisions and scaling; Functions starts code from events, schedules, or HTTP. A deployment slot is a runtime version boundary, while an environment is a broader delivery and configuration boundary.
Checkpoint
Given a bursty image-processing API and a long-running internal worker, choose a runtime for each, identify the image/artifact handoff, state how identity reaches the registry and data store, and predict what telemetry would distinguish a bad image from a blocked network.
Sources and re-audit
- AZ-204 study guide, compute objectives, skills measured 2026-01-14; checked 2026-08-31.
- Azure compute options, checked 2026-08-31.
Re-audit when supported hosting, image, ingress, or scaling behavior changes.