Module 09 Knowledge Check
5 questions. Pass mark 4 out of 5. Answer every question before checking the answer key below, then retry after reading the feedback.
1. Retrying a 400 Bad Request…
- A. often succeeds
- B. costs three times as much and delays the real error
- C. is required
- D. clears the rate limit
2. Jitter in backoff exists to…
- A. reduce latency
- B. stop every client retrying at the same instant
- C. improve accuracy
- D. reduce cost
3. A timeout should be treated as…
- A. a failure
- B. ambiguous - the call may have succeeded
- C. a rate limit
- D. a validation error
4. The degradation rung most systems skip is…
- A. serving a cached answer
- B. returning retrieved source text without a generated summary
- C. showing an error
- D. retrying
5. User-facing error messages should…
- A. include the exception for debugging
- B. be distinguishable and free of internals, with a request id
- C. be identical for simplicity
- D. include the model name
---
Answer Key and Explanations
Check these only after attempting every question.
1. B - costs three times as much and delays the real error
Nothing could plausibly differ next time - the payload is the problem.
2. B - stop every client retrying at the same instant
Without it, a thousand clients turn a brief rate limit into a sustained one they helped cause.
3. B - ambiguous - the call may have succeeded
You were charged, and only an idempotency key makes the unavoidable retry safe.
4. B - returning retrieved source text without a generated summary
Retrieval still works when the model provider does not, and source text with a citation answers most questions.
5. B - be distinguishable and free of internals, with a request id
'Something went wrong' for five different states wastes the user's time on whichever guess is wrong.
Practical Check
Apply this module to your own work: complete the module activity for *Error Handling, Retries, Rate Limits and Fallback Messages*, then write one sentence naming what your result shows and one naming what it does not.
Strong Answer Pattern
A strong answer names the task, the evidence used, the check performed, and the remaining limitation. It avoids "proved", "guaranteed", or "always" unless the evidence genuinely supports it.