Microsoft Azure AI Cloud Developer Associate (AI-200) Training Course

Azure gives you four places to run a container, and AI-200 expects you to choose between them rather than describe them. The exam rarely asks what Azure Container Apps is. It asks whether Container Apps or Azure Kubernetes Service is the right host for a specific workload described in a paragraph, and the paragraph always contains the two or three details that decide it.

The four hosts

Azure Container Registry (ACR) is not a host at all — it is where images live. Every other option pulls from it. Treat it as the first component in any container question, because image provenance, authentication, and rebuild automation are all registry concerns and they appear in questions that otherwise look like deployment questions.

Azure Container Apps is a serverless container platform built on Kubernetes and KEDA, with the Kubernetes surface hidden. You give it an image, a set of scale rules, and an ingress configuration. It gives you revisions, traffic splitting, scale-to-zero, and Dapr integration. You do not manage nodes, install a CNI plugin, or reason about pod scheduling. For a stateless inference API or a queue-driven embedding worker, this is usually the answer.

Azure Kubernetes Service (AKS) gives you the full Kubernetes API. You choose this when you need something Container Apps does not expose: GPU node pools with specific scheduling behavior, custom admission controllers, operators from the Kubernetes ecosystem, service meshes you configure yourself, or a workload that is already expressed as Kubernetes manifests your organization maintains. The cost is that you now own node pools, upgrades, and cluster networking.

Azure App Service runs a container as a web app. It is the right choice when the workload is a single long-running HTTP application, the team already uses App Service, and the container is mostly a packaging convenience rather than an orchestration requirement. Deployment slots, built-in authentication, and easy custom domains come along with it.

The details that decide it

When you read a scenario, look for these signals in order.

• GPU or specialized hardware. If the workload runs model inference on a GPU and the question mentions node sizing, taints, tolerations, or driver installation, it is an AKS question. Container Apps has added GPU capability over time, but any scenario that talks about scheduling onto particular hardware is pointing at Kubernetes.
• Scale to zero. If the workload is intermittent and the requirement is to pay nothing while idle, that is Container Apps with a KEDA scale rule and a minimum replica count of zero. AKS does not scale a cluster to zero without additional work.
• Event-driven scaling on a queue. KEDA scalers read queue depth from Service Bus, Event Hubs, Redis, and others. If the scenario says "scale based on the number of messages waiting," that is a KEDA scale rule, which means Container Apps or AKS with KEDA installed.
• Canary or blue/green traffic splitting. Container Apps does this natively with multiple active revisions and a traffic weight per revision. App Service does it with deployment slots and slot traffic percentages. AKS needs an ingress controller or a mesh to do it.
• Kubernetes-native tooling in the scenario. Mentions of Helm charts, custom resource definitions, service accounts, or existing manifests point at AKS.

Why AI workloads change the shape of the answer

An AI-integrated application usually decomposes into pieces with different runtime profiles, and that is what makes the hosting decision interesting. A typical retrieval-augmented application has an HTTP front end that must respond in a few hundred milliseconds, an embedding worker that processes documents in batches whenever they arrive, and a periodic job that reindexes a vector store.

Those three pieces have different scaling shapes. The front end wants a warm minimum replica count so no user waits on a cold start. The embedding worker wants scale-to-zero and a queue-length scale rule, because it does nothing between batches and then needs many replicas at once. The reindexing job wants a scheduled trigger and a generous timeout.

The mistake the exam tests is putting all three on one host with one scaling policy. A single AKS deployment with a fixed replica count wastes money on the worker and starves the front end during a burst. Splitting them across container apps in the same environment, each with its own scale rule, is the pattern the blueprint favors.

Environments and shared infrastructure

Container Apps groups applications into an environment, which is a secure boundary with a shared virtual network and a shared Log Analytics workspace. Apps in the same environment can call each other by name over the internal network without exposing public ingress. That property matters for AI applications, where the front end calls an internal embedding service that should never be reachable from the internet.

The equivalent in AKS is a namespace inside a cluster, and in App Service it is an App Service plan, though the isolation properties differ in each case. When a question describes several services that must talk to each other privately and be observed together, the environment concept is what it is testing.

Cost and operational posture

Do not reach for AKS by default. It is the most capable option and the most expensive to operate, and a scenario that gives you no Kubernetes-specific requirement is usually steering you away from it. Conversely, do not force a workload with genuine Kubernetes requirements into Container Apps just because it is simpler; a question that mentions a custom operator or a GPU scheduling constraint has already ruled the simpler option out.

Service capabilities and regional availability change, so confirm current limits — maximum replicas, supported GPU sizes, and networking options — in the Azure documentation rather than relying on a figure you memorized.