Module 06 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. Checkpointing exists primarily so that a workflow can…
- A. Run faster
- B. Pause, survive a restart, and resume from a known state
- C. Use fewer tokens
- D. Skip nodes
2. A thread or conversation id matters because…
- A. It is cosmetic
- B. It scopes which saved state a run resumes from
- C. It sets the model
- D. It controls cost
3. Persisted state that contains personal data requires…
- A. Nothing extra
- B. Retention limits, access control, and a deletion path
- C. Compression
- D. Encryption of the graph
4. Resuming after a code change is risky when…
- A. Never
- B. The saved state no longer matches the current state schema
- C. The model changed
- D. The run is old
5. A good checkpoint boundary is…
- A. Every token
- B. Before and after consequential or long-running steps
- C. Only at the end
- D. Randomly
---
Answer Key and Explanations
Check these only after attempting every question.
1. B - Pause, survive a restart, and resume from a known state
Durable state is what makes long-running and human-in-the-loop workflows practical.
2. B - It scopes which saved state a run resumes from
Resuming against the wrong thread silently mixes one user's context into another's run.
3. B - Retention limits, access control, and a deletion path
A checkpoint store quietly becomes a database of user content and must be governed like one.
4. B - The saved state no longer matches the current state schema
Schema drift between saved and current state produces confusing partial failures on resume.
5. B - Before and after consequential or long-running steps
Checkpoint where resuming is genuinely useful and where a pause for review may be required.
Practical Check
Apply this module to your own work: complete the module activity for *Persistence and Checkpointing*, 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.