Crisp answer: AKS (Azure Kubernetes Service) manages the Kubernetes control plane as a free managed service. You manage the agent node pools (the VMs that run your workloads). The key differences from self-managed are: no control plane access, Azure-native integrations (Entra ID, Key Vault, Monitor), and managed upgrades.
What Azure manages for free:
- Kubernetes API server (multi-zone HA available)
- etcd
- kube-scheduler, kube-controller-manager
- Control plane upgrades (you trigger, Azure executes)
- Control plane certificates (auto-rotated)
What you manage:
- Agent node pools (VM size, count, OS, labels, taints)
- Node OS patching (auto-upgrade channels available)
- Kubernetes version upgrades (control plane + node pools)
- Add-ons: Azure CNI, Cilium, Defender for Containers, Monitor
- Workloads, namespaces, RBAC, NetworkPolicies
Key AKS-specific features:
Entra ID integration:
Cluster access controlled via Entra ID groups
AKS-managed Entra ID: no need to manage kubeconfig manually
kubectl auth uses your Entra ID token automatically
az aks get-credentials --name my-cluster --resource-group my-rg
kubectl get pods # prompts for Entra ID login if token expired
Workload Identity (replaces Pod Identity):
AKS equivalent of AWS IRSA — pods assume Azure Managed Identities
via OIDC federation. No credentials in pods.
ServiceAccount annotated with:
azure.workload.identity/client-id: <managed-identity-client-id>
Key Vault Secrets Store CSI Driver:
Mount Key Vault secrets as volumes in pods
Secrets rotated automatically when they change in Key Vault
Azure CNI vs Kubenet:
Kubenet: pods get IPs from a private range, NAT to node IP
Azure CNI: pods get real VNet IPs (same as EKS VPC CNI)
Azure CNI Overlay: pods get private IPs, no VNet IP exhaustion
Cilium: eBPF-based CNI with NetworkPolicy enforcement and observability
Node pools:
System node pool: runs kube-system components
User node pools: run application workloads
Spot node pools: up to 90% cheaper for interruptible workloads
Upgrade process:
1. Upgrade control plane:
az aks upgrade --name my-cluster --resource-group my-rg \
--kubernetes-version 1.30
2. Upgrade node pools (triggers rolling node replacement):
az aks nodepool upgrade --cluster-name my-cluster \
--resource-group my-rg --name systempool \
--kubernetes-version 1.30
3. Check upgrade status:
az aks show --name my-cluster --resource-group my-rg \
--query agentPoolProfiles[].{name:name,version:orchestratorVersion}
What to say in the interview:
"AKS takes the control plane off my hands — the API server, etcd, and controllers are managed and free. I focus on the node pools and the workloads. The Entra ID integration is the biggest day-to-day difference from self-managed: cluster access is controlled by Entra ID groups, so onboarding and offboarding team members is just group membership, not editing kubeconfig files. For pod permissions to Azure services I use Workload Identity which is AKS's equivalent of IRSA — the pod's service account maps to a Managed Identity, giving it scoped Azure RBAC permissions without any credentials in the cluster."