This chapter covers Azure Kubernetes Service (AKS), a managed container orchestration platform that simplifies deploying and managing containerized applications at scale. For the AZ-900 exam, understanding AKS is part of Domain 2.2 (Azure Architecture Services), which carries approximately 15-20% of the total exam weight. You'll learn what AKS is, how it works, its key components, and why it's a cornerstone of modern cloud-native architectures. By the end, you'll be able to distinguish AKS from other compute options like Azure Container Instances and Virtual Machines, and answer exam questions confidently.
Jump to a section
Imagine you're producing a Broadway musical. You have dozens of performers (containers) — singers, dancers, musicians — each with a specific role. In a traditional setup, you'd assign each performer to a specific dressing room (virtual machine) and manage their schedules manually. But if a performer falls ill, you'd scramble to find a replacement, and if the show gets bigger, you'd need to build a whole new theater. Azure Kubernetes Service (AKS) is like hiring a world-class stage manager. This manager doesn't just assign rooms; they continuously monitor each performer's performance, automatically replace anyone who falters, and dynamically adjust the number of performers based on ticket sales (traffic). When the show needs to scale up, the manager instantly recruits more performers and assigns them to existing dressing rooms or opens new ones without interrupting the show. They also handle networking between performers — ensuring the lead singer can hear the orchestra — and manage load balancing so no single performer is overwhelmed. Crucially, the manager works with a script (Kubernetes manifest) that describes the ideal state of the show: how many performers, what roles, and how they should interact. If anything deviates, the manager corrects it immediately. You, the producer, focus on the creative vision (your application code) while the manager handles all the operational complexity. AKS is this manager, but for containerized applications — it automates deployment, scaling, and management of containers using Kubernetes, abstracting away the underlying infrastructure.
What is Azure Kubernetes Service (AKS)?
Azure Kubernetes Service (AKS) is a fully managed Kubernetes service provided by Microsoft Azure. Kubernetes is an open-source platform for automating the deployment, scaling, and management of containerized applications. Containers are lightweight, portable units that package an application and its dependencies together, ensuring consistent behavior across different environments. AKS simplifies the operational overhead of running Kubernetes by offloading much of the management responsibility to Azure, including health monitoring, upgrades, and scaling of the Kubernetes control plane.
The Business Problem AKS Solves
Before containers, applications were typically deployed on virtual machines (VMs). Each VM runs a full operating system, consuming significant resources. Scaling required provisioning new VMs, which was slow and costly. Containers solved the resource efficiency problem by sharing the host OS kernel, but managing hundreds or thousands of containers manually became a nightmare. Kubernetes emerged as the standard orchestrator, but running your own Kubernetes cluster requires expertise in cluster setup, network configuration, storage, security, and ongoing maintenance. AKS solves this by providing a managed Kubernetes service, reducing the operational burden and allowing developers to focus on application code.
How AKS Works — Step by Step
Cluster Creation: You create an AKS cluster via the Azure portal, CLI, or ARM template. Azure automatically provisions the control plane components (e.g., API server, etcd, scheduler) as managed services. You only pay for the worker nodes (VMs) that run your containers.
Node Pools: Worker nodes are grouped into node pools. Each node pool consists of identical VMs. You can have multiple node pools with different VM sizes (e.g., general-purpose, memory-optimized) or different scaling policies (manual or autoscaling).
Pod Scheduling: When you deploy an application, you define a deployment manifest (YAML) specifying the container image, replicas, and resource requests. The Kubernetes scheduler places pods (groups of one or more containers) onto appropriate nodes based on resource availability and constraints.
Service Discovery & Load Balancing: Kubernetes services expose pods internally or externally. AKS integrates with Azure Load Balancer to distribute traffic to pods across nodes. Ingress controllers can provide HTTP/HTTPS routing.
Scaling: Horizontal Pod Autoscaler (HPA) automatically adjusts the number of pod replicas based on CPU/memory usage or custom metrics. Cluster Autoscaler automatically adds or removes nodes to meet pod resource demands.
Upgrades: AKS supports rolling upgrades for both the Kubernetes version and node images. Azure manages control plane upgrades; node upgrades can be automated with surge upgrades to minimize downtime.
Monitoring: AKS integrates with Azure Monitor and Container Insights to collect metrics, logs, and performance data from containers and nodes.
Key Components of AKS
Control Plane: Managed by Azure, includes the Kubernetes API server, etcd (key-value store for cluster state), scheduler, and controller manager. You do not have direct access to the control plane nodes.
Worker Nodes: Azure VMs that run your containers. You manage the node pools, but Azure handles the underlying infrastructure health.
Pods: The smallest deployable units in Kubernetes, containing one or more containers that share storage and network.
Services: Abstractions that define a logical set of pods and a policy to access them. Types include ClusterIP (internal), NodePort (node-level port), and LoadBalancer (Azure load balancer).
Ingress: Manages external access to services, typically via HTTP/HTTPS, with routing rules.
Persistent Volumes: Storage abstractions that allow pods to persist data beyond their lifecycle. AKS supports Azure Disk, Azure Files, and Azure NetApp Files.
Secrets & ConfigMaps: Manage sensitive information (e.g., passwords) and configuration data separately from container images.
Pricing Model
AKS itself is free — you only pay for the underlying resources: worker node VMs, storage, and networking. Additional costs may apply for add-ons like Azure Policy, Azure Monitor Container Insights, or advanced networking features (e.g., Azure CNI). The control plane is provided at no extra cost.
Comparison to On-Premises Kubernetes
On-premises Kubernetes requires you to manage everything: hardware provisioning, network setup, storage, security, patching, and upgrades. AKS eliminates most of this by:
Automating control plane management (high availability, upgrades, patching).
Integrating with Azure Active Directory for authentication.
Providing built-in monitoring and logging.
Simplifying networking with Azure Virtual Network integration.
Offering automated node scaling and upgrades.
Azure Portal and CLI Touchpoints
- Portal: Navigate to "Kubernetes services" to create and manage AKS clusters. You can configure node pools, scaling, networking, and integrations like Azure Container Registry (ACR).
- CLI: Use az aks commands. For example:
az aks create --resource-group myRG --name myAKSCluster --node-count 3 --enable-addons monitoring --generate-ssh-keys
az aks get-credentials --resource-group myRG --name myAKSCluster
kubectl get nodesConcrete Business Scenario
Consider an e-commerce platform that experiences traffic spikes during holiday sales. The application is containerized into microservices (catalog, cart, checkout, payment). Using AKS, the team can:
Deploy each microservice as a deployment with multiple replicas.
Use Horizontal Pod Autoscaler to automatically scale replicas based on CPU usage.
Use Cluster Autoscaler to add more nodes when pods can't be scheduled due to resource constraints.
Perform rolling updates without downtime, ensuring the site remains available.
Monitor performance with Azure Monitor and set alerts for anomalies.
This approach reduces infrastructure costs because resources are only consumed when needed, and the team avoids the overhead of managing Kubernetes themselves.
Create an AKS Cluster
Start by creating an AKS cluster using the Azure portal, Azure CLI, or an ARM template. During creation, you specify the resource group, cluster name, region, Kubernetes version, node size (VM SKU), and initial node count. Azure provisions a managed control plane (API server, etcd, scheduler) and a node pool of VMs. The control plane is highly available by default across multiple availability zones if supported. You can also enable advanced networking (Azure CNI) or basic networking (kubenet). Behind the scenes, Azure sets up a virtual network, subnet, and network security groups. The entire process takes about 5-10 minutes. Once created, you can connect to the cluster using `az aks get-credentials` to download the kubeconfig file, then use `kubectl` to interact with the cluster.
Deploy a Containerized Application
After connecting to the cluster, you deploy your application using Kubernetes manifests (YAML files). A typical deployment manifest includes the container image (from Azure Container Registry or Docker Hub), the number of replicas, resource requests/limits, and environment variables. You apply the manifest with `kubectl apply -f deployment.yaml`. The Kubernetes scheduler places pods onto nodes with sufficient resources. If the image is private, you create a Kubernetes secret for authentication. AKS also supports Helm charts for complex deployments. Behind the scenes, the deployment controller ensures the desired number of replicas are running, and if a pod fails, it automatically replaces it. You can also expose the application via a LoadBalancer service, which provisions an Azure load balancer with a public IP.
Configure Autoscaling
To handle varying traffic, you enable Horizontal Pod Autoscaler (HPA) and Cluster Autoscaler. HPA automatically adjusts the number of pod replicas based on observed CPU/memory usage or custom metrics. You define the target average utilization (e.g., 50% CPU). If usage exceeds the target, HPA increases replicas; if usage drops, it decreases replicas. Cluster Autoscaler, when enabled, automatically scales the number of worker nodes up or down based on pending pod requests. If pods can't be scheduled due to insufficient node capacity, Cluster Autoscaler adds nodes; if nodes are underutilized and their pods can be rescheduled, it removes nodes. Both autoscalers work together to optimize resource usage and cost. You configure them via YAML manifests or Azure CLI. Note that Cluster Autoscaler has a scale-down delay to avoid flapping.
Perform a Rolling Update
When you update your application (e.g., new container image version), you modify the deployment manifest and apply it. Kubernetes performs a rolling update by gradually replacing old pods with new ones. You can control the update strategy: max surge (number of pods that can be created above desired) and max unavailable (number of pods that can be unavailable during update). By default, it updates one pod at a time. If the new pods fail health checks, Kubernetes rolls back automatically. AKS also supports blue-green and canary deployments using additional tools like Flagger or Argo Rollouts. Behind the scenes, the deployment controller creates a new ReplicaSet and scales it up while scaling down the old ReplicaSet. This ensures zero downtime if configured correctly. You can monitor the update status with `kubectl rollout status`.
Monitor and Troubleshoot
AKS integrates with Azure Monitor and Container Insights for observability. When you enable monitoring during cluster creation, Azure deploys a Log Analytics agent as a DaemonSet on each node. This agent collects container logs, performance metrics (CPU, memory, disk, network), and inventory data. You can view live data in the Azure portal under the cluster's Monitoring tab, create dashboards, and set alerts. For troubleshooting, you can use `kubectl logs` for pod logs, `kubectl exec` to run commands inside a container, and `kubectl describe` to inspect resources. Azure also provides diagnostic settings to stream logs to Event Hubs or archive to storage. Common issues include pod scheduling failures (resource constraints), image pull errors (authentication), and networking misconfigurations (network policies). The AKS diagnostics feature in the portal can automatically detect common problems.
Scenario 1: E-Commerce Platform with Seasonal Traffic
A large online retailer runs its e-commerce platform as a set of microservices on AKS. During Black Friday, traffic spikes 10x normal. The team uses Horizontal Pod Autoscaler to automatically scale each microservice based on CPU utilization (target 60%). Cluster Autoscaler adds more nodes as needed, up to a maximum of 50 nodes. Costs are optimized because during off-peak seasons, autoscaling reduces the cluster to 5 nodes. The team also uses Azure Front Door for global load balancing and Azure Redis Cache for session state. One common pitfall: if resource requests are set too high, pods may not schedule efficiently, leading to over-provisioning. Conversely, if limits are too low, pods get throttled or OOMKilled. The team uses Azure Monitor to track pod resource usage and adjusts requests/limits accordingly.
Scenario 2: Financial Services Application with Strict Compliance
A bank deploys its trading application on AKS with strict security and compliance requirements. They use Azure Policy (via Gatekeeper) to enforce pod security policies, such as preventing privileged containers and ensuring images come only from their Azure Container Registry. They integrate Azure Active Directory for Kubernetes RBAC, ensuring only authorized users can access the cluster. Networking is isolated using Azure Firewall and network policies to restrict east-west traffic. Persistent storage is provided by Azure Disk with encryption at rest. AKS ensures the control plane is automatically patched and backed up. A misconfiguration that could lead to a breach: exposing the Kubernetes API server to the internet without IP whitelisting. The team avoids this by using a private cluster (API server endpoint is private IP) and connecting via Azure Bastion or VPN.
Scenario 3: Media Streaming Service with Bursty Workloads
A video streaming platform uses AKS to run transcoding jobs. These jobs are CPU-intensive and bursty. They use Azure Spot VMs for node pools to reduce costs by up to 90%, accepting that nodes can be evicted when Azure needs capacity. They configure their transcoding pods to handle evictions gracefully by using pod disruption budgets and storing intermediate results in Azure Blob Storage. The Cluster Autoscaler is configured to prioritize Spot node pools. A challenge: if Spot capacity is low, jobs may be delayed. The team implements a fallback to regular (pay-as-you-go) nodes. They also use KEDA (Kubernetes Event-Driven Autoscaling) to scale pods based on the length of a queue in Azure Service Bus. Without proper monitoring, a spike in transcoding demand could overwhelm the cluster; they use Azure Monitor to set alerts on queue depth and pod pending status.
What AZ-900 Tests on AKS (Objective 2.2)
AZ-900 focuses on understanding what AKS is, its benefits (managed service, reduced operational overhead), and how it compares to other compute options like Azure Container Instances (ACI) and Virtual Machines. You do NOT need to know how to write Kubernetes YAML files or manage clusters. Key exam topics:
AKS is a managed Kubernetes service — Azure manages the control plane.
AKS is free; you pay only for worker nodes, storage, and networking.
AKS supports autoscaling (Horizontal Pod Autoscaler, Cluster Autoscaler).
AKS integrates with Azure Active Directory, Azure Policy, Azure Monitor, and Azure Container Registry.
AKS is ideal for microservices and containerized applications that need orchestration.
Common Wrong Answers and Why Candidates Choose Them
"AKS is a container runtime like Docker." — Wrong. Docker is a container runtime; AKS is an orchestrator that manages containers. Candidates confuse the layers.
"AKS runs only on Windows containers." — Wrong. AKS supports both Linux and Windows containers. Candidates may assume Windows-only because it's an Azure service.
"AKS requires you to manage the control plane." — Wrong. AKS is managed; Azure handles the control plane. Candidates think of self-managed Kubernetes.
"AKS is more expensive than running VMs directly." — Wrong. AKS control plane is free; you pay for VMs anyway. Candidates may think managed services always cost more.
Specific Terms and Values That Appear on the Exam
"Orchestration" — the key function of AKS.
"Pods" — smallest deployable unit in Kubernetes.
"Node pools" — groups of identical VMs.
"Horizontal Pod Autoscaler" — scales pods based on metrics.
"Cluster Autoscaler" — scales nodes based on pending pods.
"Azure Container Registry (ACR)" — stores container images; often paired with AKS.
"Azure CNI" — advanced networking plugin for AKS.
Edge Cases and Tricky Distinctions
AKS vs. ACI: ACI is for running a single container quickly without orchestration; AKS is for managing multiple containers at scale. The exam may ask which to use for a simple task vs. complex microservices.
AKS vs. Azure Service Fabric: Service Fabric is a different orchestrator (Microsoft's own) for stateful and stateless applications. AKS is for Kubernetes-native apps. The exam may compare them.
AKS with Azure Spot VMs: Candidates need to know Spot VMs are cheaper but can be evicted; not suitable for stateful workloads without resilience.
Memory Trick for Eliminating Wrong Answers
Use the acronym MOSS: - Managed (Azure manages control plane) → eliminates answers saying you manage it. - Orchestration (manages containers at scale) → eliminates answers about single containers (ACI). - Scaling (autoscaling pods and nodes) → eliminates answers that say it doesn't scale. - Services (microservices, integration with Azure services) → eliminates answers that say it's isolated.
If an answer contradicts MOSS, it's likely wrong. For example, "AKS requires manual scaling" violates S.
AKS is a fully managed Kubernetes service that reduces the operational complexity of running containerized applications.
The AKS control plane is free; you only pay for worker nodes, storage, and networking.
AKS supports both Linux and Windows containers through node pools.
Horizontal Pod Autoscaler (HPA) automatically adjusts pod replicas based on CPU/memory; Cluster Autoscaler adjusts the number of nodes.
AKS integrates with Azure Active Directory for authentication and Azure Policy for governance.
AKS uses Azure Container Registry (ACR) for storing and managing container images.
AKS is ideal for microservices architectures, CI/CD pipelines, and applications that require high availability and scalability.
For the AZ-900 exam, remember that AKS is about orchestration, not just running containers.
These come up on the exam all the time. Here's how to tell them apart.
Azure Kubernetes Service (AKS)
Managed Kubernetes orchestration for multi-container applications
Supports complex deployments with pods, services, and autoscaling
Free control plane; pay for worker node VMs, storage, networking
Ideal for microservices, CI/CD pipelines, and stateful applications
Integrates with Azure AD, Azure Policy, and Azure Monitor
Azure Container Instances (ACI)
Serverless single-container execution without orchestration
Quick startup; no cluster management needed
Pay-per-second for container runtime; no underlying VMs to manage
Best for simple tasks, batch jobs, or event-driven workloads
Limited integration; no built-in autoscaling or service discovery
Azure Kubernetes Service (AKS)
Automated orchestration, scaling, and self-healing
Managed control plane; no need to manage Kubernetes master nodes
Supports rolling updates, blue-green deployments
Built-in monitoring with Azure Monitor and Container Insights
Higher abstraction; less operational overhead
Azure Virtual Machines (VMs) with Docker
Manual orchestration using scripts or tools like Docker Compose
You manage all VMs, including the host OS and Docker engine
No built-in deployment strategies; manual update processes
Monitoring must be set up separately
Full control over the OS and Docker configuration
Mistake
AKS is a container runtime like Docker.
Correct
AKS is a managed Kubernetes orchestration service, not a container runtime. Docker is a runtime that runs containers; Kubernetes orchestrates them. AKS uses a container runtime (e.g., containerd) but the service itself is about management, not execution.
Mistake
AKS is only for Linux containers.
Correct
AKS supports both Linux and Windows containers. You can create node pools with Windows Server 2019 or 2022 nodes to run Windows-based applications. However, many features (e.g., Azure CNI, some monitoring) have limitations on Windows nodes.
Mistake
You must pay for the AKS control plane.
Correct
The AKS control plane is provided at no additional cost. You only pay for the worker node VMs, storage, and networking resources used by your cluster. This makes AKS cost-effective compared to self-managed Kubernetes where you pay for control plane VMs.
Mistake
AKS does not support autoscaling.
Correct
AKS fully supports both Horizontal Pod Autoscaler (HPA) and Cluster Autoscaler. HPA automatically adjusts the number of pod replicas based on metrics like CPU or memory. Cluster Autoscaler automatically adjusts the number of worker nodes to accommodate pod scheduling requests.
Mistake
AKS is the same as Azure Container Instances (ACI).
Correct
AKS and ACI are different services. ACI is a serverless container service for running individual containers quickly without orchestration. AKS is a full Kubernetes orchestration platform for managing complex, multi-container applications at scale. They can be used together (Virtual Kubelet) but are not interchangeable.
AKS is a managed Kubernetes service for orchestrating multiple containers at scale, ideal for microservices and complex deployments. ACI is a serverless service for running individual containers quickly without managing infrastructure. Use AKS when you need orchestration features like autoscaling, service discovery, and rolling updates. Use ACI for simple tasks, batch jobs, or event-driven workloads. On the exam, remember that AKS is for orchestration, ACI is for simple container execution.
No, AZ-900 does not require deep Kubernetes knowledge. You need to understand what AKS is, its benefits (managed service, reduced overhead), and how it compares to other compute options. You should know that AKS uses Kubernetes under the hood, but you don't need to write YAML files or manage clusters. Focus on the high-level concepts: orchestration, scaling, and integration with Azure services.
The AKS control plane is provided at no additional cost. You pay for the worker node VMs, storage (Azure Disk, Azure Files), and networking (load balancer, public IPs). Additional costs may apply for add-ons like Azure Monitor Container Insights or Azure Policy. Overall, AKS is cost-effective because you only pay for the underlying resources, and autoscaling helps optimize usage.
Yes, AKS supports both Linux and Windows containers. You can create node pools with Windows Server 2019 or 2022 nodes. However, some features like Azure CNI, certain monitoring capabilities, and some Kubernetes features have limitations on Windows nodes. Ensure your applications are compatible with Windows containers before planning a migration.
Horizontal Pod Autoscaler (HPA) scales the number of pod replicas based on metrics like CPU or memory usage. Cluster Autoscaler scales the number of worker nodes in the cluster based on pending pod requests. HPA works within the existing node capacity; if nodes are full, Cluster Autoscaler adds more nodes. Both work together to ensure your application has the resources it needs while optimizing cost.
AKS can integrate with Azure AD for authentication and authorization. You can configure Azure AD as the identity provider for the Kubernetes cluster, allowing users to authenticate using their Azure AD credentials. Kubernetes RBAC then controls access to resources based on Azure AD group membership. This provides a single sign-on experience and centralizes identity management.
Azure Container Registry (ACR) is a private registry for storing and managing container images. AKS can authenticate with ACR to pull images during pod deployment. Using ACR ensures images are stored securely and are available within Azure, reducing latency. AKS also supports image pull through managed identities, eliminating the need for credentials.
You've just covered Azure Kubernetes Service (AKS) — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?