```
az aks create -g [rg] -n [cluster] --enable-managed-identity --enable-oidc-issuer --enable-workload-identity --network-plugin azure --node-count 3 --generate-ssh-keys
```
Decisions to make before create (most cannot change later):
1. **Identity.** `--enable-managed-identity` (never service principal; SP secrets expire and break the cluster).
2. **Network plugin.** Azure CNI (now with overlay options) for VNet integration; kubenet only for tiny dev clusters. Plugin choice is immutable.
3. **Node pools.** System pool (taint CriticalAddonsOnly, small VMs) + user pool(s) for workloads. Separate pools let you scale/upgrade workloads without touching system pods.
4. **Workload identity + OIDC.** Enable at create; retrofitting works but enabling day one means every workload uses it from the start.
5. **Private cluster?** `--enable-private-cluster` hides the API server. Great for security, but then CI and admin kubectl need VNet access (VPN/ExpressRoute or a jump box). Decide before CI is built.
6. **Monitoring.** `--enable-addons monitoring` for Container Insights. Retrofitting is fine, but day-one metrics make the first incident debuggable.
7. **Upgrades.** Set `--auto-upgrade-channel patch` or `stable`; unpatched clusters age into unsupported versions and upgrades get painful.
Traps:
- Creating with the default kubenet then needing VNet features = rebuild.
- Forgetting `--enable-oidc-issuer` and discovering workload identity cannot be enabled later without it (it can be enabled later via update, but do it now).
- Cluster in the wrong subscription/VNet peering missing = nodes cannot reach private backends.
Verify: `kubectl get nodes` shows system + user pools, `az aks show` shows OIDC issuer URL, and a test workload with workload identity can reach its backend.