Degree Cumulative Review (Semesters 0--10)

note

[TECHNIQUE 7: Interleaved Review] This is the final cumulative review of the whole degree. The sixty questions below are grouped as a per-semester re-test (Q1-10), cross-semester integration prompts (Q11-25), a top-defend concept sweep across the degree (Q26-50), phase-completion contract self-checks against Foundations / Systems / Software / Architecture / Production (Q51-55), and a capstone close-out (Q56-60). Attempt each block closed-book, then self-grade and push misses into Anki. Sixty questions.

---

Degree Map (Reference for the Review)

Semester	Mission	Main Deliverable
S0 -- Orientation & Foundation	Build algorithm intuition, CS mental model, clean coding habits	Working study system, baseline coding fluency, journal practice
S1 -- Mathematical & CS Foundations	Build mathematical maturity for later algorithms and systems	Proofs, discrete math exercises, problem-solving portfolio
S2 -- Algorithms & Data Structures	Reach algorithmic sophistication grounded in precise reasoning	Algorithm kata set with complexity analysis and correctness arguments
S3 -- Software Design & Patterns	Learn to reshape code safely under change	Refactor lab, pattern applications, design-review artifacts
S4 -- Systems Programming	Move from application code to machine-level reasoning	Low-level programs, memory-layout write-ups, toy allocator/runtime
S5 -- Operating Systems & Networking	Understand processes, memory, filesystems, concurrency, networks	OS lab work, concurrency exercises, networking capstone
S6 -- Databases & Distributed Systems	Learn persistence, replication, consistency, distributed tradeoffs	Query/storage exercises, distributed tradeoff matrix
S7 -- Software Architecture & Domain Design	Translate systems knowledge into architecture decisions and ADRs	Architecture review packet with ADRs, C4, context map
S8 -- System Design & Technical Leadership	Design production-grade systems end-to-end and communicate decisions	Full system-design write-up, stakeholder memo, design-review walkthrough
S9 -- Cloud Infrastructure & DevOps	Deploy, operate, secure real cloud systems with IaC and CI/CD	Deployed reference stack with IaC, pipeline, dashboards, threat model
S10 -- Capstone Integration	Prove production readiness on one project	One end-to-end capstone: repo, IaC, CI/CD, SLO, ADRs, defense

Use this table as the scaffold for the per-semester re-test block (Q1-10) and as the cross-semester linker for the integration block (Q11-25).

---

Instructions

Set a four-hour timer split across two sessions if needed. Attempt Q1-25 closed-book in session one; Q26-60 closed-book in session two. Grade with notes afterwards. Every question you miss becomes an Anki card; every question whose answer feels approximate becomes a Feynman note. If a semester scores below 60% on its re-test, re-run that semester's own cumulative-review.md before the graduation checkpoint.

---

Questions

1. S0 re-test -- habit and study system. Name the three study habits from Semester 0 you actually kept, and the one you dropped. What concrete evidence from your journal shows each, and if the dropped habit was load-bearing, how did you compensate? Then redo one Anki review session honestly and note your retention rate against what Semester 0 promised.
2. S1 re-test -- mathematical reasoning. Pick one proof technique from Semester 1 (induction, pigeonhole, contradiction, construction) and apply it to a claim from your capstone: for example, prove that your pagination algorithm never skips a record, or that your retry policy cannot loop indefinitely. Where did the proof force you to clarify an implicit assumption?
3. S2 re-test -- algorithms and data structures. Re-solve one Semester 2 kata from memory (e.g., topological sort, LRU cache, shortest path). Write a tight complexity analysis and explain one data-structure choice you would defend under review. Then point to the place in your capstone where the same complexity reasoning shows up.
4. S3 re-test -- safe refactor under change. Take one 50-100 line module from your capstone that has gone slightly smelly. Apply two refactor moves from Semester 3 (extract function, introduce parameter object, replace conditional with polymorphism, etc.), behavior-preserving only. Write the before/after and the smell you were responding to.
5. S4 re-test -- machine-level reasoning. Redo one Semester 4 exercise (e.g., stack frame walk-through, a struct-padding problem, a toy allocator). Then explain which part of your capstone runtime -- language, allocator, GC, container, or VM -- now feels less like a black box, and which part you still handwave.
6. S5 re-test -- OS, concurrency, networking. Pick one: a concurrency race condition, a filesystem consistency question, or a network-layer question (e.g., "what does curl https://... do from DNS through TLS handshake through HTTP request?"). Answer from memory. Now connect it to a specific subsystem in your capstone: which OS or network mechanic would bite you first under load?
7. S6 re-test -- persistence and distribution. Rebuild the Semester 6 distributed tradeoff matrix for your capstone: at least three decisions with Option A, Option B, tradeoffs, chosen option, and rationale. Include at least one decision about consistency, one about indexing, and one about replication or durability.
8. S7 re-test -- architecture and DDD. Redraw your capstone's context map (bounded contexts and the integration patterns between them). Name the core subdomain and the one subdomain that became more important than you expected. Which Semester 7 pattern (shared kernel, conformist, anti-corruption layer, etc.) describes each boundary, and does the pattern match the code?
9. S8 re-test -- end-to-end system design. Take the Semester 8 system-design rubric and score your capstone against it as if you were reviewing someone else's work. Where does the capstone under-perform the Semester 8 standard, and is that a conscious tradeoff or an unacknowledged gap?
10. S9 re-test -- cloud, IaC, DevOps. Walk through your capstone's deploy from commit to running prod: every stage, every artifact, every IAM boundary. Identify one place where you took a Semester 9 shortcut (e.g., state backend, secret injection, IAM scope). Is it still acceptable, and what is the written rationale?
11. Integration -- consistency model end-to-end. Reason about your capstone's consistency model using Semester 6 (replication, isolation), Semester 5 (concurrency primitives), and Semester 7 (bounded-context integration). Where is the consistency boundary? What invariant crosses it? What is the worst-case user-visible anomaly, and who notices?
12. Integration -- performance budget. Pick one user-facing request in your capstone. Decompose its latency budget using Semester 2 (algorithmic cost), Semester 5 (kernel + network), Semester 6 (DB + indexes), and Semester 9 (cloud hops). Which segment dominates, and which segment is the first one you would optimize under pressure?
13. Integration -- failure propagation. Pick a dependency your capstone cannot control (payment, email, third-party API). Trace how its failure propagates using Semester 5 (timeouts, retries), Semester 6 (distributed thinking), Semester 7 (anti-corruption layer), and Semester 9 (observability). Where does the failure get absorbed, and where does it leak to the user?
14. Integration -- scope and architecture. Use Semester 3 (refactor), Semester 7 (boundaries), and Semester 10 Module 1 (scope-cut rules). One of your bounded contexts has grown a feature it should not own. Walk through the refactor: when would you act, what pattern would you use, and what ADR would you write?
15. Integration -- security across layers. Use Semester 5 (OS permissions), Semester 6 (data at rest / secrets), Semester 8 (threat modeling), and Semester 9 (IAM, OIDC, dependency scanning). Pick one attack that would matter for your capstone. Trace the defense across all four layers. Which layer is weakest today?
16. Integration -- tests in context. Use Semester 2 (complexity), Semester 3 (refactor safety), and the Track A testing thread. Explain why your capstone has (or lacks) a test at each level of the pyramid, which tests are actually valuable vs ceremonial, and which level you would strengthen first given one week.
17. Integration -- observability as architecture. Use Semester 7 (architecture characteristics), Semester 8 (SLOs), and Semester 9 (dashboards, alerts). Argue that observability is architectural by showing one place where a missing signal in your capstone would change which architecture choice is defensible.
18. Integration -- cost, reliability, and throughput. Use Semester 6 (storage tradeoffs), Semester 8 (scale), and Semester 9 (cloud budget). Your capstone's traffic doubles sustainably. What is the first thing that breaks? The first thing that gets expensive? And the first thing that gets slow?
19. Integration -- people and documentation. Use Semester 7 (ADRs, design reviews), Semester 8 (stakeholder comms), and Semester 10 Module 5 (portfolio voice). If you handed your capstone to a new engineer tomorrow, which document would they read first, which one is actually useful, and which one would they ignore? Fix the gap.
20. Integration -- deploy + migration together. Use Semester 6 (schema change), Semester 8 (release strategy), and Semester 9 (CI/CD). Describe an expand-contract migration end-to-end against your capstone schema: what goes out in release N, N+1, N+2, and how do you roll back at each step?
21. Integration -- domain language. Use Semester 3 (naming and design), Semester 7 (ubiquitous language), and Semester 10 Module 1 (solo-team language discipline). Find two places in your capstone code where the name does not match the glossary term. What would it cost to rename them, and would you do it before the defense?
22. Integration -- architecture vs implementation gap. Use Semester 7 (architecture characteristics), Semester 2 (complexity), and Semester 10 Module 2 (implementation). Pick one architectural claim in your design doc. Prove, by reading the code, that the implementation either honors or silently violates it. Which fitness function would catch a regression?
23. Integration -- on-call at day one. Use Semester 5 (systems reasoning), Semester 9 (operations), and Semester 10 Module 4 (runbooks). It is 3am, a single alert fires, and you have never seen it before. Walk through the first 10 minutes using only your capstone's artifacts -- dashboards, runbook, logs, recent deploy. Where would the trail go cold, and what would you add to the runbook tomorrow?
24. Integration -- data lifecycle. Use Semester 6 (storage), Semester 7 (context boundaries), and Semester 9 (security). Pick one entity in your capstone (a user, an order, an event). Trace its lifecycle from creation to deletion or archive. Where is it at rest, where is it in flight, who can read it at each stage, and what erases it for a compliance-style request?
25. Integration -- the honest tradeoff. Using any four semesters you want, describe the single tradeoff in your capstone you are least proud of. What constraint forced it, which knowledge told you it was acceptable, and what would you do with one more week?
26. Defend -- Big-O is necessary but insufficient. Give a one-paragraph explanation of why asymptotic complexity can mislead on real hardware, with one Semester 2 example and one concrete runtime behavior (cache, branch prediction, allocator).
27. Defend -- hash map vs balanced tree. In plain language, when do you reach for each, and what guarantee does the tree give you that the hash map cannot?
28. Defend -- memory hierarchy. Explain the CPU-cache, RAM, SSD, network-storage hierarchy with order-of-magnitude latencies and why it shapes algorithm design.
29. Defend -- virtual memory. Explain paging, page faults, and why the kernel can pretend each process owns all of RAM. What does this cost?
30. Defend -- process vs thread vs coroutine. In one diagram, explain what is shared, what is not, and pick which your capstone uses where and why.
31. Defend -- locks and lock-free. Explain a mutex, a read/write lock, and at least one lock-free primitive. Name a real bug each prevents or causes.
32. Defend -- TCP vs UDP vs QUIC. In plain language, what guarantees and what costs; which one is implicit in your capstone's network hops and which one is on purpose.
33. Defend -- TLS in three minutes. Handshake, certificate chain, what the symmetric key actually protects, and the thing most people get wrong.
34. Defend -- DNS and why it matters operationally. TTLs, caching, resolver paths, and the incident mode DNS fails in.
35. Defend -- ACID in your own words. Atomicity, consistency (the transactional sense), isolation, durability, each tied to a real mechanism in your capstone's datastore.
36. Defend -- isolation levels. Explain Read Committed, Repeatable Read, Serializable with one real anomaly each, and which your capstone runs in.
37. Defend -- B-tree vs LSM. Read cost, write cost, compaction cost, and which your capstone uses.
38. Defend -- CAP and PACELC. One sentence each, then locate your capstone on both.
39. Defend -- idempotency. Why it is the defensive operation of distributed systems, and where in your capstone it is enforced.
40. Defend -- eventual consistency. Where it is acceptable, where it is a bug, and the UX question it forces.
41. Defend -- DDD bounded contexts. What they buy beyond "modules", and how they change the shape of a codebase.
42. Defend -- aggregates and invariants. What an aggregate root protects and why the consistency boundary is drawn there.
43. Defend -- event-driven vs request/response. Where each fits, where each misleads, and which dominates in your capstone.
44. Defend -- ADRs. What an ADR does that a wiki page does not, and the one ADR you are most likely to be asked about.
45. Defend -- the test pyramid. What breaks if it inverts, and which level you trust most in your capstone.
46. Defend -- CI vs CD. The honest definitions, the one you do today, and the gap to the other one.
47. Defend -- IaC and state. Why state is the scariest file in your repo and how you protect it.
48. Defend -- OIDC vs long-lived keys in CI. Why it matters even for a solo project.
49. Defend -- SLO, SLI, SLA. What each is, who they are for, and the numeric SLO you would promise on your capstone.
50. Defend -- error budget. How it is computed, how it is spent, and how it changes what you ship tomorrow.
51. Phase -- Foundations contract. Can you explain fundamental CS concepts from first principles, analyze algorithms, and write clean code under review? Point to the Semester 0-3 artifacts that prove it. Where are you still weak? Give a concrete remediation you will run in the 12-month plan.
52. Phase -- Systems contract. Can you reason about what the machine, OS, and network are actually doing, and debug down to a layer you do not usually touch? Point to the Semester 4-6 artifacts. Which layer of the stack still feels fuzzy and what is your plan for it?
53. Phase -- Software contract. Can you reshape non-trivial code safely, evolve APIs without breaking consumers, and make design decisions you can defend in review? Point to the Semester 3, 7, and 8 artifacts. Which pattern have you used without understanding it, and how will you close that?
54. Phase -- Architecture contract. Can you take an ambiguous problem, choose characteristics, pick a style, document decisions, and draw a system another engineer could inspect? Point to the Semester 7, 8, and 10 Module 1 artifacts. Name one architecture style you did not use in the capstone and explain when you would.
55. Phase -- Production contract. Can you deploy, operate, secure, and defend a real system -- not a sandbox? Point to the Semester 9 and 10 Modules 3-4 artifacts. Name one operational scenario you have not yet walked through and the next step to close that.
56. Capstone close-out -- the ADR you would rewrite. Which ADR, with what new wording, and why only now?
57. Capstone close-out -- the subsystem you would redesign. Which one, with what new approach, and what would you keep?
58. Capstone close-out -- the decision you got right. Which one, what were the signals during weeks 92-95 that confirmed it, and what would have told you it was wrong?
59. Capstone close-out -- the knowledge you did not have. Name one topic you reached for during the capstone and realized you had to relearn. Which semester owned it, and what did you change in your Anki deck?
60. Capstone close-out -- the next six weeks. You have graduated. Describe the first concrete action in your 12-month specialization plan, the success criterion for the first three months, and the external signal (a written piece, a shipped feature, a talk) that will prove momentum.

---

Answer Key

Do not read this before attempting. Answers live outside this document -- for each question, the canonical answer is a combination of (a) your own capstone artifacts (repo, ADRs, design doc, runbook, dashboards), (b) the referenced prior-semester concept or exercise, and (c) your Feynman note library. For each question, after attempting closed-book: (1) score Green (confident + correct), Amber (correct but fuzzy), or Red (wrong or blank); (2) for every Amber, add or refresh a Feynman note; (3) for every Red, create or promote an Anki card and, if three or more Reds cluster in a single semester, re-run that semester's own cumulative-review.md before the final checkpoint. Record your per-block scores -- Q1-10 (semester re-test), Q11-25 (integration), Q26-50 (defend sweep), Q51-55 (phase contracts), Q56-60 (capstone close-out) -- in the semester journal under week 96. A pass on this review means every block is at least 70% Green with no single semester or phase dominating the Red column.