Error text patterns: `Operation could not be completed as it results in exceeding approved ... quota`, `SubscriptionIsOverQuotaForSku`, `QuotaExceeded`.
Triage:
1. **Which quota, where.** The message names the resource type and region. `az vm list-usage -l [region]` shows current vs limit for compute. Many "quota" errors are per-region, and another region has headroom.
2. **Wrong subscription.** Quotas are per subscription per region. A fresh sub has tiny defaults. If you have quota elsewhere, move the workload or the subscription, do not wait for a raise.
3. **Request the increase.** Azure portal: Subscriptions > Usage + quotas > Request increase. Or `az support tickets create`. Standard vCPU raises are usually approved in hours; GPU and some SKUs take days. Request 2-3x what you need now.
4. **Burstable vs regular.** B-series has its own quota pool. "Quota exceeded" on a B VM while D-series has room is a B-quota problem.
5. **Cleanup first.** Disassociated public IPs, unattached disks, and stopped (not deallocated) VMs all count against quota. `az vm deallocate` actually frees the vCPU quota; `az vm stop` does not.
Prevention: a pre-flight quota check in provisioning scripts (`az vm list-usage`) with a clear error beats a failed 20-minute deployment. For event-driven scale (Functions premium, AKS node pools), set the max burst below your quota so scale-out degrades gracefully instead of erroring.