Deploy and scale application compute
Place in the route
Use this module after the runtime and security foundations. It connects a built application or container image to a managed Azure runtime, then makes deployment and capacity decisions explicit.
Outcomes
You should be able to distinguish an image from a running container, select App Service, Functions, Container Apps, or a VM from workload requirements, describe a deployment path, configure application settings and TLS at the right boundary, and explain autoscaling signals.
From artifact to runtime
A container image is an immutable package containing application code and its user-space dependencies. A registry stores versions of that image; a container runtime pulls the image and creates a running instance. The image is not the runtime: an image can be valid while a registry credential, network path, environment variable, or health probe prevents startup.
App Service hosts web code on a managed platform. Functions hosts trigger-driven code. Container Apps runs containerized workloads with managed ingress and revision-based deployment. A VM supplies OS control but leaves patching and more of the runtime to the team. ACI is useful for straightforward container execution without a broader application platform; AKS supplies Kubernetes control when that complexity is justified.
Configuration, TLS, and deployment
Application settings and connection references configure a deployed app without rebuilding its artifact. Secrets should come from a managed secret store or workload identity rather than source control. TLS terminates at the chosen ingress or application boundary; the certificate, hostname, and backend trust must agree. A deployment slot or revision lets a new version warm up and be tested before traffic changes. A build produces the artifact; deployment promotes that same artifact into a runtime.
Scaling and failure
Autoscale changes instance count or capacity in response to a rule and signal such as CPU, queue depth, or HTTP load. Scaling out adds instances; scaling up changes the instance size or plan. A scale rule cannot repair a failing image, bad configuration, or unavailable dependency. Health probes and logs must establish whether the new instance is actually ready before traffic is sent to it.
Worked scenario and checkpoint
For an HTTP API packaged as an image, explain the sequence registry → runtime → configuration → health probe → ingress → telemetry. Choose Container Apps when managed container revisions and ingress fit; choose App Service for ordinary web hosting; choose a VM only when OS control is a real requirement. Predict what happens when the image tag exists but the runtime identity cannot pull it, and when a scale rule adds instances whose secret configuration is missing.
Hands-on / what to try
Without creating Azure resources, read a sample container manifest and deployment declaration. Identify the image digest, registry reference, environment settings, secret references, probe, ingress, scaling rule, and expected logs. Mark which step would fail for an invalid image, denied registry access, missing secret, or unhealthy probe.
Sources and re-audit
- AZ-204 study guide, final skills measured 2026-01-14, checked 2026-08-31.
- Azure Container Apps overview, checked 2026-08-31.
- App Service overview, checked 2026-08-31.
AZ-204 is retired; this module preserves its application-development concepts. Re-audit when runtime, deployment, identity, or scaling behavior changes.