Error text: `429 Too Many Requests`, sometimes with `Retry-After` header, or `RequestThrottled`.
Rules:
- **Honor Retry-After.** If the response includes it, wait that long. The SDKs with retry policies do this automatically; hand-rolled REST loops usually do not.
- **Exponential backoff with jitter.** Base 1-2s, double, add random jitter, cap at ~60s. Without jitter, N parallel workers retry in lockstep and re-trigger the throttle.
- **ARM limits are per-principal per-subscription.** A provisioning script that fans out 50 parallel deployments will throttle. Serialize, or spread across subscriptions.
- **Data-plane limits are per-resource.** Storage: ~20k ops/sec per account; Cosmos DB: RU/s; Service Bus: messaging units. A 429 here means scale the resource or reduce the request rate, not just retry harder.
- **Reads throttle too.** `az resource list` in a tight loop across a big estate throttles ARM. Cache inventory; do not poll.
- **SDK retry config.** azure-core lets you set retry policy (total retries, backoff factor). Defaults are sane; raising max retries without backoff just delays the same failure.
Verify: after adding backoff, watch the 429 rate in metrics drop to zero over a few minutes. If 429s persist at low request rates, you are hitting a hard service limit and need a quota/raise or a bigger SKU, not more retries.