10.2 Container-Based Solution Design (AKS, Container Apps, Azure Container Instances)

Why Container Design Matters on AZ-305

The second compute-selection objective is "Recommend a container-based solution." Containers have become the default building block for cloud-native and microservices workloads, and AZ-305 expects you to choose correctly among Azure's three main container platforms based on how much orchestration control the team needs versus how much operational overhead it is willing to accept. Getting this wrong in practice means either over-engineering a simple job with a full Kubernetes cluster, or under-provisioning a production microservices platform with a tool that has no self-healing.

The Three Container Platforms at a Glance

AKS Node Pools in Design Terms

Every AKS cluster requires at least one system node pool, which runs the critical cluster components (CoreDNS, metrics-server, and other platform pods) and should be kept isolated from application workloads. User node pools run your application containers, can use different VM sizes per pool (including GPU-enabled sizes for ML workloads), and — unlike system pools — can scale to zero when idle. The cluster autoscaler adjusts node count between a configured --min-count and --max-count. For sudden burst demand beyond the cluster's own capacity, virtual nodes provision additional pod capacity backed by Azure Container Instances, without waiting for new VM nodes to boot.

Azure Container Apps Specifics

Container Apps is Azure's serverless container platform: you deploy a container image, and Azure handles the underlying Kubernetes cluster, KEDA-based event scaling, and networking entirely. Key design concepts:

• Scaling rules are KEDA-based — HTTP concurrency, CPU/memory thresholds, or a custom trigger like a Service Bus queue length. Apps can scale to zero when idle, billed only for actual usage.
• Dapr integration provides building blocks (service invocation, state management, pub/sub messaging) without writing that plumbing yourself.
• Revisions allow blue/green or canary release patterns, routing traffic percentages across app versions.
• A Container Apps Environment is the shared boundary (like a lightweight VNet + Log Analytics workspace pairing) that a set of related Container Apps deploy into.

Azure Container Instances Specifics

ACI runs one or more containers as a container group — containers that share a lifecycle, network namespace, and storage volumes, similar in concept to a single Kubernetes pod, but with no orchestrator behind it. A standard container group is capped at 4 vCPU and up to 16 GB memory; "Big Containers" support up to 31 vCPU and 240 GB memory for a standard group (180 GB for confidential container groups), but exceeding 4 vCPU/16 GB requires an Azure support quota request. ACI has no built-in restart-on-failure across the group and no service discovery — it is designed for short-lived or bursty single-purpose workloads, not for a resilient, always-on service tier. Confidential container groups add hardware-based encryption of data in use, which matters for regulated workloads (financial, healthcare) that need to prove data is protected even while a container is actively processing it — a detail worth flagging when a scenario mentions compliance requirements alongside a container-group design.

Container Apps Jobs vs. ACI for Run-to-Completion Work

Both Container Apps and ACI can run a container to completion and stop, but the reason to pick one over the other is the surrounding environment, not the run-to-completion behavior itself. Container Apps Jobs run inside an existing Container Apps Environment, so they automatically share that environment's networking, Dapr configuration, and Log Analytics integration with the rest of your microservices — the natural choice when the job needs to call other services already running in Container Apps. A standalone ACI container group has no such environment to join; it is the simpler, faster-starting choice when the task is fully self-contained, such as a CI/CD build agent that only needs to check out code, build an image, and exit.

Common Exam Traps

• Recommending AKS for a single, occasional batch container job — massive operational over-engineering when ACI or Container Apps Jobs would suffice.
• Recommending ACI for a workload that needs self-healing, rolling updates, or service discovery — ACI has none of that; it is not an orchestrator.
• Assuming Container Apps has no shared infrastructure at all — it still requires a Container Apps Environment, unlike fully isolated ACI container groups.
• Forgetting that AKS user node pools (not system pools) are the ones that can scale to zero — a system pool always needs at least one running node.

Scenario Walkthrough

Fabrikam needs a lightweight microservices API that scales automatically based on Service Bus queue depth, with a small platform team that has no desire to operate Kubernetes — Container Apps with a KEDA queue-length scaling rule is the fit. A separate dev team needs to run an occasional, short-lived image-resizing job triggered by a pipeline, with no persistent infrastructure required — ACI container group. An enterprise platform team needs custom Kubernetes operators, GPU node pools for a machine learning inference service, and full control of networking CNI plugins — AKS.