Domain 1 · Develop containerized solutions on Azure
Before an AI workload can serve a single request, it has to be packaged and placed somewhere that can run it. This domain is about that journey: building an image, storing it privately, and choosing among Azure's four container hosts. The exam rarely asks you to recall a flag in isolation — it describes a situation and asks which service or setting fits it, so read every question here as "given these constraints, what is the right home for this container?"
Azure Container Registry (ACR)
ACR is a managed, private Docker/OCI registry — the place your images live between being built and being deployed. Most of what the exam asks about ACR concerns two things: how images get into it without a build machine, and how workloads authenticate to pull them out.
The build story is az acr build, which runs an ACR Task on Azure-managed compute and pushes the result, so no local Docker daemon is required. This matters in CI agents and locked-down environments where you cannot run a daemon at all. It is easy to confuse with az acr import, which copies an existing image from another registry — a transfer, not a build. If a question describes source code as the input, you want build; if it describes an image that already exists elsewhere, you want import.
ACR Tasks can fire on three kinds of trigger. A source-code commit rebuilds on push, as you would expect. A base image update rebuilds every dependent image automatically when the upstream base is patched — the answer whenever a scenario mentions inheriting OS-level security fixes without manual work. A scheduled (timer) trigger covers periodic rebuilds.
For authentication, prefer a managed identity granted the AcrPull RBAC role. The admin user is a single shared static credential: convenient for a quick test, discouraged in production precisely because it cannot be attributed to a workload or rotated per consumer. Beyond that, ACR offers geo-replication for multi-region pulls, content trust for image signing, and retention policies that clean up untagged manifests.
Hosting containers on Azure App Service
App Service is the simplest of the container hosts — a managed web app platform that happens to accept a container image. The exam's interest here is narrow and configuration-shaped.
Application settings are surfaced to the container as environment variables at runtime, which is the mechanism that lets you change configuration without rebuilding the image. If your container listens on something other than 80 or 8080 you must say so by setting WEBSITES_PORT (or PORT) — a missing value here is the classic cause of a container that starts cleanly but never serves traffic. Deployment slots round this out, giving you a staging target and a swap for staged releases.
Azure Container Apps
Container Apps is a serverless container platform built on Kubernetes, Dapr, and KEDA, with the cluster deliberately hidden from you. Reach for it when a scenario wants Kubernetes-grade scaling and traffic control but explicitly does not want to operate a cluster.
Its defining capability is event-driven autoscaling via KEDA: you scale on queue length (Service Bus, Storage queues), Event Hubs, CPU, or HTTP concurrency. The detail worth memorising is that queue-based rules can scale to zero — if a question pairs "no cost when idle" with "wakes on queue messages", Container Apps is very likely the answer.
Deployments are modelled as revisions, immutable snapshots of a configuration. Running in multiple-revision mode lets you split traffic by percentage across them, which is how canary and blue-green rollouts are expressed here. Environment variables and secrets are configured per container, and secrets can reference Key Vault rather than holding values inline.
KEDA (Kubernetes Event-driven Autoscaling)
KEDA deserves separate treatment because it appears both inside Container Apps and standalone on AKS. It layers event-source scalers — Service Bus, Event Hubs, Kafka, Redis, Cron and more — on top of the standard Horizontal Pod Autoscaler.
The distinction the exam tests is against that default HPA. Plain CPU/memory HPA cannot react to anything outside the cluster. KEDA can scale to zero and reacts to external event metrics such as queue depth. So a workload that sits idle for hours and then must drain a backlog is a KEDA scenario, not an HPA one.
Azure Kubernetes Service (AKS)
AKS is the option that hands you the cluster, and with it the responsibility. Workloads are deployed declaratively through manifest files, and the exam expects you to pick the right object for a described behaviour:
- Deployment — manages replica count and rolling updates for stateless pods.
- Service — a stable virtual IP / DNS name with load balancing in front of those pods.
- ConfigMap / Secret — configuration and sensitive values, kept out of the image.
- A bare Pod has no self-healing, a Job runs to completion, and a DaemonSet runs one pod per node.
That last line is the one to internalise: "the pod died and nothing brought it back" is a symptom of deploying a bare Pod where a Deployment was needed.
Troubleshooting commands
Diagnosis questions tend to hinge on knowing which command surfaces which evidence:
| Goal | Command |
|---|---|
| Watch a rollout finish | kubectl rollout status deployment/<name> |
| Logs from the crashed instance | kubectl logs <pod> --previous |
| Cluster events | kubectl get events --sort-by=.lastTimestamp |
| Inspect a pod's state | kubectl describe pod <pod> |
The --previous flag is the high-value one: in a crash loop the current container has only just started and its logs are empty, so the explanation lives in the terminated instance's logs. For anything longer-lived than a debugging session, enable Azure Monitor Container Insights to collect logs and metrics into Log Analytics, where you query them with KQL — the same language you meet again in Domain 4.
Quiz · Domain 1
You need to build a container image in the cloud without a local Docker daemon, pushing the result straight into your registry. Which command accomplishes this?