AI-103 Practice Question 2: Throttling 429 Mitigation
Microsoft Azure AI Apps and Agents Developer Associate (AI-103) · Test 1 · question 2 of 10
Users of a customer-facing chat feature report that it occasionally returns an error during short traffic spikes, then works normally again a minute later. Application logs show the model endpoint returning HTTP 429 Too Many Requests during exactly those windows. Average usage sits well below the deployment's tokens-per-minute allocation.
What should the development team do first to make the feature ride out these spikes?
Show answer and explanation
Answer:
An HTTP 429 means the tokens-per-minute or requests-per-minute limit was momentarily exceeded. Microsoft's documented resolution is to implement retry logic with exponential backoff and use the `Retry-After` header value, and the general best-practice guidance for staying within rate limits leads with implementing retry logic in the application. Because the spikes are short and average usage is low, retrying a moment later succeeds, no architecture change or extra spend required.
- A is wrong because a 429 is an immediate rejection, not a slow response. The client timeout controls how long a request may run before the client gives up; it has no effect on a request the service already refused. - C is wrong because extra regions don't reliably add capacity. For models onboarded to subscription-level quota management, Global Standard deployments of the same model and version share a single quota pool across all regions in the subscription. - D is wrong because Batch deployments trade real-time responsiveness for cost savings; they carry no real-time SLA and target completion within 24 hours, which is unusable for an interactive chat feature.
Reference: Microsoft Foundry Models quotas and limits