Title: Quiz 14 — Documentation, Runbooks, and Reproducibility
Course: AIINFRA 303: Capstone Project > Section: Week 14 — Documentation, Runbooks, and Reproducibility

Q: What is the primary difference between a playbook and a runbook?
- A playbook is for junior engineers; a runbook is for senior engineers
- A playbook covers the strategic "what and why"; a runbook covers the tactical "how"
- A runbook is only used during onboarding
- There is no meaningful difference
A: A playbook covers the strategic "what and why"; a runbook covers the tactical "how"

Q: An overly long, highly detailed runbook is generally more effective during a real incident because it leaves nothing to interpretation.
- True
- False
A: False

Q: Why does the lecture recommend performing a recovery procedure manually before automating it?
- Automation is always slower than manual steps
- Free tools don't support automation
- Scripting a process you don't fully understand yet tends to produce broken automation that mishandles edge cases
- Manual steps are required by compliance
A: Scripting a process you don't fully understand yet tends to produce broken automation that mishandles edge cases

Q: Name the three components a good runbook step should always include so an operator can self-verify progress.
Feedback: Sample/expected answer: A specific, executable action paired with its expected output (and what an unhealthy/failing result looks like).

Q: Well-written, clean source code is generally sufficient on its own for a stranger to reproduce and evaluate a project, without a README.
- True
- False
A: False

Q: In the MLflow Tracking Quickstart workflow described this week, what backend/storage combination is used for the local tracking server?
- PostgreSQL backend with S3 artifact store
- SQLite backend with a local artifact store
- No backend; everything is in-memory
- MongoDB backend with Azure Blob storage
A: SQLite backend with a local artifact store

Q: What is the purpose of registering a model in the MLflow Model Registry rather than just saving the model file to disk?
Feedback: Sample/expected answer: It creates a named, versioned model that links back to the exact run (params, metrics, artifacts, code) that produced it, giving traceability/reproducibility.

Q: Which of the following belongs in a Hugging Face-style Model Card but NOT typically in an incident runbook?
- Rollback procedure
- Escalation contact
- Intended use, training data, and known limitations/bias considerations
- Expected command output during diagnosis
A: Intended use, training data, and known limitations/bias considerations