AI-200 containerized solutions explained
Develop containerized solutions on Azure is worth 20–25% of AI-200. It covers two things: hosting a container (building and storing images in Azure Container Registry, then running them on App Service) and orchestrating containers (Azure Container Apps and Azure Kubernetes Service). The questions reward knowing which platform fits a scenario, and reading the configuration that makes it work.
Container application hosting
Azure Container Registry
The registry is where every other objective in this domain starts. Know how to:
- Push, tag and version images. Tags such as
v1.4orlatestcan be moved to point at a different image; a digest (@sha256:…) cannot. When a scenario demands that the exact same image runs in test and production, the answer uses the digest or an immutable tag. - Manage images: list repositories, delete untagged manifests, and lock an image against overwrite or deletion.
- Authenticate pulls without passwords. The pattern the exam prefers is a managed identity with the
AcrPullrole, not the registry admin account.
ACR Tasks
ACR Tasks build images inside Azure instead of on a developer’s machine or a build agent.
| Task type | Triggered by |
|---|---|
Quick task (az acr build) | You, once, from the CLI |
| Source code trigger | A commit or pull request in a Git repository |
| Base image trigger | An update to the base image your Dockerfile uses |
| Timer trigger | A schedule |
The base image trigger is the one to remember. A scenario about keeping images patched when the upstream Python image gets a security fix wants a task with a base image update trigger, not a nightly manual rebuild.
Containers on App Service
App Service runs a single container, or a small set of them, as a web app. Two configuration objectives stand out:
- App settings become environment variables inside the container. You set configuration there, not in the image.
- Secrets come from Key Vault references such as
@Microsoft.KeyVault(SecretUri=…)in an app setting, resolved through the app’s managed identity. The container sees an ordinary environment variable; the secret never enters the image or source control.
App Service is the right answer when the scenario describes a web app or API with steady traffic and no need for event-driven scaling or orchestration.
Container-orchestrated solutions
Azure Container Apps
Container Apps is the default choice for microservices and APIs that need to scale on demand without running a Kubernetes cluster.
- Environments group apps that share a virtual network and a Log Analytics workspace.
- Revisions are immutable snapshots of an app’s configuration. A change to the template — container image, environment variables, scale rules — creates a new revision; a change to application-wide settings such as secrets or ingress does not.
- Single revision mode replaces the old revision. Multiple revision mode keeps several active and splits traffic between them by percentage, which is how you run a blue-green or canary release.
KEDA scaling
Container Apps scales with KEDA scale rules. The exam objective is event-driven scaling, so expect rules that watch something other than CPU.
| Rule | Scales on | Scale to zero? |
|---|---|---|
| HTTP | Concurrent requests | Yes |
| TCP | Concurrent connections | Yes |
| Custom (KEDA scaler) | Queue length, event count, and so on | Yes |
| CPU or memory | Resource utilisation | No |
A queue-driven worker that should cost nothing while idle wants a custom Service Bus scaler with minimum replicas set to zero. CPU and memory rules cannot bring an app back from zero, because an app with no replicas uses no CPU to measure.
Azure Kubernetes Service
AKS is the answer when the scenario needs full Kubernetes: existing manifests or Helm charts, fine control over networking and scheduling, or workloads that other platforms cannot host. The outline specifies deploying by using manifest files, so be able to read a Deployment (replicas, container image, environment variables, resource requests and limits) and a Service (which pods it selects, which port it exposes, and whether it is internal or a public load balancer).
Troubleshooting
The last objective covers both platforms: logs, events and end-to-end connectivity.
| Symptom | Where to look |
|---|---|
Pod status ImagePullBackOff | kubectl describe pod events; usually registry permissions or a wrong image name |
Pod status CrashLoopBackOff | kubectl logs --previous for the last crash’s output |
| Container App revision not ready | System logs and revision status in the Container Apps environment |
| App running but unreachable | Ingress configuration, target port and service selectors |
Sample questions
Question 1. Your Dockerfile uses a public Python base image. When that base image receives a security update, your application image must be rebuilt and pushed to Azure Container Registry automatically. What should you configure?
- A. A quick task run with az acr build
- B. An ACR task with a base image update trigger
- C. Geo-replication on the registry
- D. A retention policy for untagged manifests
Show answer
Answer: B
An ACR task with a base image update trigger detects changes to the base image and rebuilds the dependent image automatically. A quick task with az acr build runs only when you invoke it. Geo-replication copies images between regions and does not rebuild anything. A retention policy removes untagged manifests.
Want more questions like this? Full AI-200 practice tests →
Question 2. You are releasing a new version of an API in Azure Container Apps. Twenty percent of traffic must go to the new version while the rest stays on the current one, and you must be able to roll back instantly. What should you do?
- A. Deploy in single revision mode and monitor the new revision
- B. Create a second Container Apps environment for the new version
- C. Double the maximum replica count during the release
- D. Use multiple revision mode and split traffic 80/20 between the two revisions
Show answer
Answer: D
Multiple revision mode keeps both revisions active and lets you assign traffic weights, and rolling back is a matter of moving the weight back to the old revision. Single revision mode replaces the old revision entirely. A second Container Apps environment adds unnecessary infrastructure, and scaling the replica count does not direct traffic between versions.
Want more questions like this? Full AI-200 practice tests →
Question 3. A pod in AKS reports ImagePullBackOff after you deploy a manifest that references an image in your private Azure Container Registry. Other images from public registries run fine. What is the most likely fix?
- A. Attach the container registry to the AKS cluster so the cluster identity has AcrPull
- B. Increase the memory limit in the Deployment manifest
- C. Change the Service type from ClusterIP to LoadBalancer
- D. Increase the number of replicas in the Deployment
Show answer
Answer: A
An image pull failure specific to the private registry points to the cluster lacking permission to pull from it. Attaching the registry to the cluster grants the kubelet identity the AcrPull role. Increasing memory limits addresses crashes, not pulls. Changing the Service type affects networking after the pod runs. Adding replicas repeats the same failing pull.
Want more questions like this? Full AI-200 practice tests →
What to practise
Build one image with az acr build, run it on Container Apps with a Service Bus scale rule, and then deploy the same image to AKS with a hand-written manifest. Break the AKS deployment on purpose by removing the registry permission, and read the pod events until the cause is obvious. That single exercise covers most of this domain.