AI-103 Practice Question 82: Retry Jitter Design
Microsoft Azure AI Apps and Agents Developer Associate (AI-103) · Test 9 · question 2 of 10
A nightly batch pipeline runs forty parallel worker processes that all call the same Azure AI Foundry model deployment. Each worker already implements exponential backoff on 429 responses, computed from the same formula. Telemetry shows that retries from different workers keep landing in the same narrow time windows, and each of those windows produces a fresh burst of 429 responses as all the delayed requests arrive together.
What should the team add to the retry policy to fix this, without introducing a queueing system?
Show answer and explanation
Answer:
Microsoft's Well-Architected guidance defines jitter as a "random delay added to retry intervals to prevent multiple clients from retrying simultaneously," and names this exact failure mode: synchronized retry storms that overwhelm a recovering service. Because every worker here computes the same deterministic backoff from the same formula, they retry in lockstep; adding randomization to each worker's interval spreads those retries out so they stop re-triggering each other's throttling.
- A is wrong because a larger ceiling only changes how far the delay grows before it's capped; it doesn't change the fact that all forty workers still compute the *same* interval at the same time and arrive together. - C is wrong for the same structural reason, and it also fights the purpose of backoff: making retries happen sooner during an active throttling event increases load on a service that's already signaling it's overwhelmed. - D is wrong because the guidance is explicit that an operation should never get more than one immediate retry, and an undelayed retry against a service already returning 429 makes the synchronized burst worse, not better.