Semester Exam

Required Output Classification

Required output	Classification	Public/private guidance
Timed written answers, diagrams, code snippets, and design responses	Checkpoint evidence	Keep raw exam work private so it remains useful for assessment and retake calibration.
Post-exam review notes, missed-answer repairs, and Feynman explanations	Practice artifact	Use for spaced review; publish only rewritten explanations that no longer reveal exam solutions wholesale.
Capstone-defense or architecture-defense packets created from exam prompts	Portfolio candidate	Polish publicly only when they are original to your project, sanitized, and framed as engineering rationale rather than exam answers.

This exam checks whether you can reason across operating systems and networking as one connected layer of engineering, not as five separate note sets.

Target time: 3 hours total.

Policy:

• closed notes for Sections A and B
• notes allowed only for Section C after you complete your first independent attempt
• diagrams, traces, and short written justifications matter more than polished prose

---

Section A: Core Reasoning

Answer all questions. Keep answers concise but specific.

1. A workload has four jobs with burst times 2, 4, 6, 12. Compare FCFS and SJF on average turnaround time and explain why the difference appears.
2. Explain the difference between a context switch, a trap, an interrupt, and a system call.
3. Walk a virtual address through a multi-level page-table translation and name where the TLB participates.
4. Distinguish a TLB miss from a major page fault using both cause and expected cost.
5. Write the minimal interleaving that breaks a naive shared counter increment across two threads.
6. Explain why wait(cond, mutex) must release the mutex atomically and why the predicate must be checked again after wake-up.
7. Describe how journaling prevents certain filesystem corruption cases after a crash.
8. Explain why epoll scales better than select for a server with many mostly idle connections.
9. Compare TCP flow control and congestion control in one paragraph.
10. Explain what TLS adds on top of TCP and what problem it does not solve.

---

Section B: Design and Tradeoffs

Choose one answer for each prompt, then justify it in 5-8 sentences.

1. You need to handle 20,000 concurrent client connections on one machine. Would you choose one thread per connection, a fixed-size thread pool with blocking sockets, or an event-driven server? Defend the choice and name the failure mode of the alternatives.
2. A service shows rising latency and rising RSS after a deployment. Name the first measurements you would take to decide whether the problem is allocator behavior, page faults, lock contention, or network stalls.
3. Your application appends to a local log file and reports success to a client immediately after write(). Explain the durability risks and give one stronger design.
4. You have a CPU-bound workload in one container and an interactive service in another on the same host. Explain the scheduling and isolation controls you would investigate first.

---

Section C: Practical Trace

Complete one integrated practical exercise.

Prompt

Design and implement a small concurrent TCP service that:

• accepts multiple clients
• reads line-based requests
• logs requests to disk
• returns a simple status response

Then produce a short engineering note that includes:

1. your concurrency model and why you chose it
2. one packet-level or socket-state observation from tcpdump, Wireshark, ss, or equivalent
3. one note about durability or fsync policy for the log
4. one note about what would happen under contention for CPU, memory, or locks

You may use code you wrote during the semester as long as you can explain every part.

---

Grading Standard

You pass the semester exam when your work shows all of the following:

• correct mechanism-level reasoning in Sections A and B
• clear tradeoff thinking instead of generic best practices
• at least one working practical artifact or trace in Section C
• no major confusion between neighboring concepts such as TLB miss vs page fault, mutex vs semaphore, journaling vs write-back cache, or TCP vs TLS

If your answers are mostly vocabulary without mechanism, the exam is not passed.

---

Mastery Rubric

Level	Evidence
Beginner pass	Can answer direct questions and complete familiar exercises with light notes.
Solid pass	Can solve new variants, explain choices, and connect the work to Semester 4 Systems Programming.
Strong pass	Can defend tradeoffs, identify failure modes, and produce clean evidence in the portfolio artifact.
Not ready	Relies 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.

Quality	Example pattern
Weak	Names a concept but gives no example, constraint, or failure case.
Acceptable	Defines the concept and applies it to a familiar exercise.
Strong	Applies the concept to a new variant and explains why an alternative would fail.
Portfolio-ready	Connects the concept to Semester 4 Systems Programming, 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:

• Answer key and solution outlines
• Rubric, passing standard, strong traits, and weak patterns