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

Exam AZ-305: Designing Microsoft Azure Infrastructure Solutions Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Orientation

1.1 AZ-305 Current Exam Facts & Format 1.2 Candidate Profile, Prerequisites & the AZ-104 Requirement 1.3 Skills Outline, Domain Weights & How to Use This Guide

2 Chapter 2: Logging, Monitoring & Diagnostics Design

2.1 Logging Solution Design 2.2 Log Routing Design 2.3 Azure Monitor Metrics & Alerting Design 2.4 Application Insights & Diagnostic Monitoring Design

3 Chapter 3: Authentication & Authorization Design

3.1 Authentication Solution Design 3.2 Identity Management Design 3.3 Authorization for Azure Resources 3.4 Authorization for On-Premises Resources 3.5 Secrets, Certificates & Key Management Design

4 Chapter 4: Governance, Compliance & Identity Governance Design

4.1 Management Group & Subscription Hierarchy Design 4.2 Resource Group Organization & Tagging Strategy Design 4.3 Compliance Management Design 4.4 Identity Governance Design

5 Chapter 5: Relational Data Storage Design

5.1 Relational Data Storage Selection 5.2 Database Service & Compute Tier Design 5.3 Database Scalability Design 5.4 Relational Data Protection Design

6 Chapter 6: Semi-Structured & Unstructured Data Storage Design

6.1 Semi-Structured Data Storage Design 6.2 Unstructured Data Storage Design 6.3 Storage Tier & Cost-Performance Trade-off Design 6.4 Unstructured Data Protection & Durability Design

7 Chapter 7: Data Integration & Analytics Design

7.1 Data Integration Pipeline Design 7.2 Event-Based & Real-Time Data Integration Design 7.3 Data Analytics Platform Design

8 Chapter 8: Backup & Disaster Recovery Design

8.1 Recovery Objectives Design: Calculating and Meeting RTO/RPO 8.2 Azure Site Recovery Architecture for Hybrid Workloads 8.3 Compute Backup & Recovery Design 8.4 Database Backup & Recovery Design 8.5 Unstructured Data Backup & Recovery Design

9 Chapter 9: High Availability Design

9.1 Compute High Availability: Availability Sets & Availability Zones 9.2 Compute High Availability: Load Balancing & VM Scale Set Design 9.3 Relational Data High Availability Design 9.4 Semi-Structured & Unstructured Data High Availability Design

10 Chapter 10: Compute Solution Design

10.1 Compute Requirements Analysis & Virtual Machine-Based Solution Design 10.2 Container-Based Solution Design (AKS, Container Apps, Azure Container Instances) 10.3 Serverless-Based Solution Design (Azure Functions, Logic Apps) 10.4 Batch Processing Solution Design (Azure Batch, HPC Workloads)

11 Chapter 11: Application Architecture Design

11.1 Messaging Architecture Design (Service Bus, Queue Storage) 11.2 Event-Driven Architecture Design (Event Grid, Event Hub) 11.3 API Integration & Application Caching Design (API Management, Azure Cache for Redis, CDN) 11.4 Application Configuration Management & Automated Deployment Design (App Configuration, DevOps Pipelines, Deployment Slots)

12 Chapter 12: Migration Design

12.1 Migration Assessment: Cloud Adoption Framework & On-Premises Evaluation 12.2 IaaS & PaaS Workload Migration Design 12.3 Database Migration Design (Data Migration Service, Database Migration Assistant) 12.4 Unstructured Data Migration Design (AzCopy, Data Box, Storage Migration Service)

13 Chapter 13: Network Solution Design

13.1 Internet Connectivity Design 13.2 Hybrid Connectivity Design 13.3 Network Security Optimization Design 13.4 Network Performance Optimization & Load-Balancing/Routing Design

14 Chapter 14: Final Review, Exam Strategy & Career Path

14.1 Cross-Domain Scenario Practice: Combining Identity, Data, Continuity & Infrastructure Decisions 14.2 Common AZ-305 Decision Traps 14.3 Final Study Plan & Practice Assessment Strategy 14.4 After AZ-305: Retake Policy, Renewal & Career Path

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

Key Takeaways Explain This Topic AI

AZ-305 tests choosing among AKS, Azure Container Apps, and Azure Container Instances (ACI) based on control needs versus operational overhead tolerance.

AKS system node pools must always keep at least one node running; user node pools can scale to zero and support GPU/custom VM sizes.

Azure Container Apps is fully serverless (Kubernetes + KEDA + Dapr abstracted away), scales on event triggers including queue depth, and supports blue/green traffic-split revisions.

ACI runs container groups with no orchestrator: 4 vCPU/16 GB standard cap, up to 31 vCPU/240 GB with a Big Containers support request — no self-healing or service discovery.

Virtual nodes extend AKS burst capacity using ACI-backed pods without waiting for new VM nodes to provision.

Last updated: July 2026

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

Platform Orchestration Scaling model Operational overhead Typical use case

Azure Kubernetes Service (AKS) Full Kubernetes control plane (managed by Azure) Cluster autoscaler, horizontal pod autoscaler, virtual nodes for burst Highest — you manage node pools, upgrades, networking (CNI), custom controllers Enterprise microservices needing custom Kubernetes tooling, GPU node pools, multi-team platforms

Azure Container Apps Kubernetes + KEDA + Dapr under the hood, fully abstracted Event-driven autoscaling (HTTP, CPU, queue depth, custom KEDA scalers), scale to zero Low — no cluster, no node, no Kubernetes API to manage Event-driven microservices, background processing, APIs that need Kubernetes-style scaling without Kubernetes operations

Azure Container Instances (ACI) None — no orchestrator Manual; no automatic restart across container groups Lowest — fastest to start, but no self-healing Burst compute, CI/CD build agents, single batch jobs, sidecar-style container groups

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 .