Module 04 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. Conditional routing should be driven by…
- A. Free-text model output parsed with regex
- B. Explicit, validated values in state
- C. The length of the response
- D. Random choice
2. Every conditional branch needs…
- A. A comment
- B. A defined default or fallback path for unexpected values
- C. A model call
- D. A retry
3. Retrying a failed node without a limit risks…
- A. Better results
- B. An infinite loop that burns budget and never terminates
- C. Faster completion
- D. Cleaner state
4. A transient tool failure and a genuine validation failure should…
- A. Be handled identically
- B. Take different paths - retry versus escalate or stop
- C. Both end the workflow
- D. Both be ignored
5. The clearest sign that routing logic belongs in code rather than a prompt is…
- A. It is short
- B. The decision has a correct answer that can be checked
- C. It involves text
- D. It is slow
---
Answer Key and Explanations
Check these only after attempting every question.
1. B - Explicit, validated values in state
Routing on unvalidated prose is how workflows take silent wrong turns.
2. B - A defined default or fallback path for unexpected values
Unhandled branch values either crash or fall through silently; both are avoidable by design.
3. B - An infinite loop that burns budget and never terminates
Retries need a cap and an escalation path, not unbounded optimism.
4. B - Take different paths - retry versus escalate or stop
Retrying a genuine rejection wastes time and can repeat a harmful action; escalating a blip is noisy.
5. B - The decision has a correct answer that can be checked
If correctness is checkable, encode it - do not ask a model to re-derive it each run.
Practical Check
Apply this module to your own work: complete the module activity for *Conditional Routing and Error Paths*, 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.