criticalProductionSymptom-first#aks#provisioning#cluster#failed#control-plane

AKS cluster stuck in Failed provisioning state

az aks show returns provisioningState = Failed

Likely source:availabilitydeployment

Focused incident mode — strips away everything but this runbook.

Symptoms

  • az aks show returns provisioningState = Failed
  • New AKS clusters fail to create after reaching a Failed state
  • Cluster cannot be accessed even though some resources were created

A Failed AKS cluster cannot be recovered without deletion and recreation in most cases. Export the cluster definition to Bicep/Terraform to ensure reproducibility.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Cluster provisioning error

    az aks show -g <RG> -n <AKS> --query provisioningState -o tsv

  • MC resource group health

    az resource list --resource-group MC_<RG>_<AKS>_<LOCATION> --query "[].{name:name,state:provisioningState}" -o table

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • MC_ resource group shows a networking resource in Failed state
  • Error references subnet delegation or VNet peering

Confirm before fixing

az resource list --resource-group MC_<RG>_<AKS>_<LOCATION> --query "[?provisioningState=='Failed'].{name:name,type:type}" -o table
READ

Find failed resources in the MC group

Fix

az aks delete -g <RG> -n <AKS> --yes --no-wait && az aks create -g <RG> -n <AKS> --node-count 2 --network-plugin kubenet
DESTRUCTIVE

Delete and recreate the cluster (if unrecoverable)

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
az aks show -g <RG> -n <AKS> --query provisioningState -o tsv
READ

Read the error detail

2
az resource list --resource-group MC_<RG>_<AKS>_<LOCATION> --query "[?provisioningState=='Failed']" -o table
READ

Identify failed underlying resources

3
az aks delete -g <RG> -n <AKS> --yes
DESTRUCTIVE

Delete the cluster if unrecoverable

4
az aks create -g <RG> -n <AKS> --node-count 2 --network-plugin kubenet --generate-ssh-keys
CHANGE

Recreate the cluster from scratch

Prevention

  • Define AKS clusters in Bicep/Terraform with all networking dependencies.
  • Pre-create VNet and subnets before AKS creation, do not let AKS create them.
  • Use managed identity instead of service principal for AKS clusters.
  • Test cluster creation in a staging environment before production.

Related runbooks

Same stack, same failure family — worth a skim.

AKS node pool NotReady — nodes failing health checkscritical

kubectl get nodes shows NotReady for nodes in a specific pool

AzureIntermediateUSE3 causes
Open runbook
AKS upgrade stuck — cluster not in Succeeded statehigh

az aks show returns provisioningState = Upgrading for more than 30 minutes

AzureAdvanced2 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.