Skip to main content

Final Comprehensive Exam

Required Output Classification​

Required outputClassificationPublic/private guidance
Timed written answers, diagrams, code snippets, and design responsesCheckpoint evidenceKeep raw exam work private so it remains useful for assessment and retake calibration.
Post-exam review notes, missed-answer repairs, and Feynman explanationsPractice artifactUse for spaced review; publish only rewritten explanations that no longer reveal exam solutions wholesale.
Capstone-defense or architecture-defense packets created from exam promptsPortfolio candidatePolish publicly only when they are original to your project, sanitized, and framed as engineering rationale rather than exam answers.

The final exam is the written assessment of the whole degree. It mixes breadth recall across Semesters 0-10, two depth-of-design scenarios (one architectural, one operational), and a direct tie-in to your own capstone. It is graded against a rubric that rewards clear tradeoff reasoning over memorized detail. Treat it as the written half of the graduation artifact; the oral half is the capstone defense described in Capstone Project -- Demo & Defense Prep.

Instructions​

  • Duration: 4 hours, in two 2-hour blocks with a 30-minute break between. Parts 1-2 in block one; Parts 3-4 and the Feynman Challenge in block two.
  • Format: Open-notes (your own written notes, Feynman library, ADRs, design doc). Closed on LLMs, closed on search. One external reference URL is allowed per Part 3 and Part 4 question if you genuinely need it, but it must be cited.
  • Answer length: Aim for 200-400 words per Part 1 question, 600-1000 words per Part 2/3/4 question. Favor diagrams and tradeoff tables over prose where they carry more weight.
  • Tools: Pen and paper is fine for diagrams; transcribe them into the submission. A terminal for quick reference is allowed; executing code against your capstone is allowed in Part 4 only.
  • What you submit: One markdown file per part, plus the Feynman recording (or transcript). Total body under 8000 words. No introduction or conclusion sections -- answer the questions directly.
  • What passes: Correct core reasoning and at least one honest tradeoff per answer. Memorized definitions without applied reasoning do not pass.

Part 1: Breadth (Interleaved Across Degree)​

Each answer should be tight -- a paragraph, a small diagram, or a tradeoff table. This part tests that the degree's foundational concepts are still in your fingertips.

  1. Explain the difference between time complexity and space complexity using one concrete example from Semester 1 (e.g., a sorting or graph algorithm) and one from Semester 6 (e.g., an index lookup). Why does "big-O" alone sometimes mislead on real hardware?
  2. Define a race condition and describe one place it could appear in your capstone. What concurrency primitive from Semester 5 would you reach for, and what is the tradeoff vs the alternative?
  3. Pick any hash function you have used. Walk through why it is "good enough" for the purpose and what attack or failure mode would make it a bad choice. Reference Semester 2 or 5 material.
  4. Describe the CAP theorem in one paragraph without using the letters C, A, or P as labels. Then say which corner your capstone sits in and why, drawing on Semester 6 distributed-systems material.
  5. Walk through how an HTTP request from a browser ends up at a function in your capstone's primary service, naming at least four layers. Reference Semesters 3 (networking) and 4 (web).
  6. You are given an index on (user_id, created_at). Which of these queries uses it efficiently and which does not, and why: WHERE user_id = ? ORDER BY created_at DESC; WHERE created_at > ?; WHERE user_id = ? AND status = 'active'. (Semester 6.)
  7. Explain a bounded context from Semester 7 DDD in your own words. Name two bounded contexts in your capstone and the one integration pattern between them (shared kernel, customer/supplier, anti-corruption layer, etc.).
  8. Describe the difference between a unit test, an integration test, and an end-to-end test using one function from your capstone as the anchor. What would each test catch that the others cannot? (Semester 8 and cross-cutting Track A.)
  9. Your capstone's main environment variable leaks into a public log. Walk through the remediation in order of priority -- what do you rotate first, what do you patch, what do you postmortem? (Semester 9 and cross-cutting Track C.)
  10. Define an SLO vs an SLA vs an SLI. Give the SLO you drafted in Module 4 and explain why that specific number and not a stricter or looser one.

Part 2: Depth -- Design & Tradeoffs​

Answer two of the three. Each answer is a design write-up: stated requirements, a diagram, at least three considered options with explicit tradeoffs, a chosen option with rationale, and two consequences you would accept.

  1. Architect a new system from scratch. You are handed this problem: a mid-size company wants a service that ingests 5-10 million event records per day from its point-of-sale terminals, provides near-real-time dashboards for store managers, and a monthly finance export that must tie out exactly to the transactional source. Design the system end-to-end. Address bounded contexts, the consistency boundary between real-time and finance paths, the storage choice(s), and the single hardest tradeoff you had to make. (Draws on Semesters 6, 7, 8.)
  2. Extend your capstone architecture. Take your capstone's current architecture and add one non-trivial new requirement: multi-tenant isolation for at least 50 tenants, with one tenant's load spike not degrading the others. Walk through the changes: data layer, deployment topology, noisy-neighbor mitigations, and what in your current ADR set now becomes wrong.
  3. Redesign for a different top characteristic. Pick one of your capstone's non-goal characteristics (e.g., if you optimized for operability, pick scalability; if you optimized for scalability, pick auditability). Redesign the two most affected subsystems. What would you now keep from the current design, what would you change, and what new ADR would you write?

Part 3: Depth -- Cloud, Security & Operations​

Answer two of the three. Each answer should show real artifacts (a pipeline snippet, an IAM policy fragment, a runbook step, a dashboard description), not just prose.

  1. Walk a bad deploy end-to-end. A merge to main triggers a deploy. Ten minutes later your error-rate dashboard spikes and the 99th-percentile latency doubles. Describe your exact response in the first 15 minutes, drawing on the pipeline and observability you built in Modules 3 and 4. Cover detection, rollback trigger, communication, and post-incident notes. How does this answer change if the bad deploy also included a database migration?
  2. Threat-model an extension of your capstone. You are adding a public API for third-party integrations. Produce a STRIDE (or similar) threat model with at least six threats, the mitigation for each, and the control that proves the mitigation (test, scan, IAM rule, log). What assumption in your current threat model changes because the audience is now external?
  3. Explain your IaC blast radius. Open your Terraform root. Identify the module whose destroy would take the longest to recover from, and describe the recovery: what is in state, what is in cloud, what would need to be re-created from source. How does your design in Module 3 bound the damage a bad apply can do?

Part 4: Capstone Integration​

All three are required. Answers should reference specific commits, ADRs, or artifacts in your capstone repo.

  1. Defend your single hardest design decision. Pick the ADR you are least confident about. Re-argue it in writing against the strongest alternative. What evidence from weeks 92-95 either supports or undermines the original call, and would you rewrite the ADR today?
  2. Walk the failure you planned for vs the one you actually hit. Name one failure scenario you designed for in Module 4 and one surprise that bit you during implementation. Compare the two. What does the gap tell you about your architectural assumptions, and what would change in a hypothetical v2?
  3. Connect three semesters to one capstone subsystem. Pick the single subsystem of your capstone that is hardest to get right (usually the core subdomain). Explain how material from three different semesters (name them) directly shaped how you built it. If a semester was not useful for this subsystem, say so and explain why.

Feynman Challenge​

Learning Technique

[TECHNIQUE 3] Choose one hard topic from the degree (e.g., a capstone subsystem, distributed concept, or security control). Teach it in plain language to a non-expert in 10 minutes (recorded or live). No slides dense with jargon -- analogies encouraged.

Prompt​

Pick five candidate topics from across the degree (ideally one from each of the phases: Foundations, Systems, Software, Architecture, Production). Write a one-line summary of how you would teach each. Then pick one and deliver the full 10-minute explanation, recorded.

Sample phrasing: "Explain [eventual consistency / your capstone's deployment pipeline / how TLS actually protects an HTTP request / why your chosen database is OLTP-friendly / how a modern CI runner achieves isolation] to a smart high-school student with a laptop and curiosity, in 10 minutes, using at most one diagram and no acronyms you don't first define."

Target for the chosen topic: no acronym goes undefined, one concrete analogy carries the central idea, and the last two minutes of the talk answer the obvious "but why?" questions.

Rubric​

CriterionSelf-score (1--5)Notes
Simple languageEvery acronym defined on first use; no borrowed jargon standing in for understanding; a smart teenager could follow along
CorrectnessThe analogy does not lie; the edge case a real engineer would ask about is acknowledged, not hidden
Structure (beginning / middle / end)One sentence problem statement up front; core mechanism in the middle; closes by answering the single hardest "but why?"
Handles "why" questionsAt minute 8-10 you address at least two unscripted "why does it have to work that way?" questions without hand-waving

Reflection (after attempt)​

Write 200-400 words answering: where did your explanation stumble, which analogy broke first, what acronym did you reach for without defining, and which two topics from the original five now clearly need their own Feynman note. Add those two notes to your Feynman library before closing out the semester.

Self-Grading Key​

Grade holistically against the rubric below. Do not average scores across parts -- a weak answer in any one part is a weak exam, because the degree is about integration.

BandDescription
PassPart 1: at least 8 of 10 correct core reasoning. Parts 2-4: each answer names a real tradeoff, justifies the chosen option, and cites specific artifacts from your capstone. Feynman: rubric average 3+ with correctness at 4+. Translation: you can build, operate, and defend a production system.
Strong passPass criteria plus: at least one Part 2 or Part 3 answer proposes a design you did not use but could credibly argue for; the Feynman rubric averages 4+; Part 4 answers show you would now rewrite at least one ADR with a specific reason. Translation: you can lead a small system end-to-end and own the decisions.
DistinctionStrong-pass criteria plus: every part references at least two different semesters by name with precision; the Feynman recording is re-watchable without embarrassment; the Part 4 reflection on three-semester integration is specific enough that a reader unfamiliar with your capstone can still follow the reasoning. Translation: you can explain, defend, and teach the system -- not just operate it.

If you score below Pass on any part, use the remediation path in Final Checkpoint before treating the degree as complete.

Added Defense Prompts​

Use these prompts in the final oral or written defense:

  1. Show how one project option requirement became a tested vertical slice.
  2. Walk from UI or API request to datastore and back, naming the failure boundary, security boundary, and observability signal.
  3. Explain one legal, ethical, or professional responsibility created by your system and how the implementation addresses it.
  4. Defend one rejected architecture, datastore, or API alternative.
  5. Show the evidence package: tests, deployment, rollback, runbook, security review, and portfolio narrative.

Mastery Rubric​

LevelEvidence
Beginner passCan answer direct questions and complete familiar exercises with light notes.
Solid passCan solve new variants, explain choices, and connect the work to Semester 9 Cloud and DevOps.
Strong passCan defend tradeoffs, identify failure modes, and produce clean evidence in the portfolio artifact.
Not readyRelies on copied solutions, cannot explain mistakes, or lacks durable artifacts.

Retake and Repair Rule​

If a section is weak, do not only reread. Repair it by producing new evidence: a corrected solution, a fresh implementation, a rewritten proof, a benchmark, a diagram, a runbook, or a short teaching note.

Answer-Quality Examples​

Use these examples when grading written answers or spoken explanations.

QualityExample pattern
WeakNames a concept but gives no example, constraint, or failure case.
AcceptableDefines the concept and applies it to a familiar exercise.
StrongApplies the concept to a new variant and explains why an alternative would fail.
Portfolio-readyConnects the concept to Semester 9 Cloud and DevOps, current project evidence, and a future capstone decision.

Interleaving Prompt​

For any missed answer, add one sentence starting with: This depends on an earlier skill because...​

Calibration Materials​

Use these learner-visible calibration materials before self-grading or requesting review: