Module 03 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. Why request structured output rather than prose you parse yourself?
- A. It is cheaper
- B. A declared schema can be validated, so failures are caught rather than silently mis-parsed
- C. It is faster
- D. Models prefer it
2. When schema validation fails, the right response is…
- A. Ignore it and continue
- B. A defined path - repair, retry with feedback, or fail loudly
- C. Lower the temperature
- D. Log and proceed
3. A schema field described as 'the answer' is weaker than one described precisely because…
- A. It is shorter
- B. Field descriptions guide the model; vague ones produce inconsistent content
- C. It uses tokens
- D. Parsers ignore descriptions
4. Optional fields in a schema should be used when…
- A. Always, for safety
- B. The value genuinely may not exist - otherwise required fields catch omissions
- C. Never
- D. For numbers only
5. Structured output guarantees…
- A. Correct facts
- B. Correct shape only - the content inside can still be wrong
- C. Nothing
- D. Both shape and content
---
Answer Key and Explanations
Check these only after attempting every question.
1. B - A declared schema can be validated, so failures are caught rather than silently mis-parsed
Validation converts an ambiguous string into a pass/fail contract.
2. B - A defined path - repair, retry with feedback, or fail loudly
Continuing with unvalidated data pushes a known-bad value deeper into the system.
3. B - Field descriptions guide the model; vague ones produce inconsistent content
Descriptions are part of the prompt. Treat them as instruction, not documentation.
4. B - The value genuinely may not exist - otherwise required fields catch omissions
Making everything optional silently permits empty results to pass validation.
5. B - Correct shape only - the content inside can still be wrong
Schema conformance is not truth. Grounding and verification remain separate concerns.
Practical Check
Apply this module to your own work: complete the module activity for *Structured Output and Parsers*, 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.