Tripos Exam Strategy & Common Pitfalls

Paper Structure

Aspect	Detail
Format	Paper 2; multi-part questions (a)—(c), each part building on the last
Question style	Scenario-based: a fictional company/system is described, then several sub-questions applying course concepts to it
High-yield topics	Case studies & failure lessons; FR/NFR classification; Agile/Scrum mechanics; testing (pyramid, coverage, mutation, TDD); CI/CD & deployment strategies; SemVer & API evolution; SRE & observability
Also examinable	Security concepts (STRIDE, ACLs vs capabilities, password vs public-key authentication); AI-era engineering judgement questions

General Exam Technique

1. Read all parts before starting. Later parts often hint at what earlier parts expect. Marks are frequently split evenly across sub-parts — do not over-answer (a) and run out of time for (c).

2. Ground every abstract principle in a named case study or framework. “Never rely on a single sensor” is weaker than “Never rely on a single sensor — cf. Boeing 737 MAX, where MCAS relied on a single Angle-of-Attack sensor, a single point of failure that directly caused two fatal crashes.”

3. Answer scenario questions in the scenario’s own terms. If the question describes a decentralised social network, do not just define STRIDE generically — apply each relevant threat category to that system’s specific data flows: “A malicious server could spoof posts claiming to be from a user on another server, since cross-server trust is currently based on the sending server’s word alone.”

4. For “pros and cons” or “discuss trade-offs” questions, use a clearly labelled two-sided structure. A short table or explicit “Pro:” / “Con:” bullets are easier for an examiner to mark than a single blended paragraph.

5. Quantify wherever the scenario permits. Communication paths via $\binom{n}{2}$, error budgets as $100\% - \text{SLO}$, SemVer version bumps (MAJOR vs MINOR) — numeric, worked reasoning demonstrates precise understanding beyond prose.

6. For “is this approach appropriate?” questions, give both supporting and opposing arguments, then a clear, justified conclusion. Do not just pick a side. Examiners reward balanced analysis with a synthesised recommendation.

7. Do not forget the conclusion / recommendation. Many high-mark parts (e.g. 2025 Q5b, 14 marks) explicitly reward a final, justified synthesis, not just a laundry list of pros and cons.

8. Keep answers proportional to the marks available. A 6-mark part expects 4–6 distinct, justified points. A 14-mark part expects full structured coverage of every sub-clause in the question (as in the worked 2025 Q5 answer).

Top 10 Exam Traps

1. Confusing FR and NFR. An NFR is a quality/constraint, not an action. “The system shall calculate VAT” is an FR — calculating tax sounds like a “quality” but it is a specific action the system performs. “The system shall calculate VAT in under 10 ms” adds an NFR (performance constraint).
2. Treating Agile as “no planning / no docs.” Agile teams plan more frequently than Waterfall teams (every 2 weeks vs once upfront). Agile values working code over comprehensive documentation — it does not ban documentation.
3. Confusing A/B Testing (business/product: does a red button increase sales?) with Canary (technical: does the new version have higher error rates?).
4. Confusing Blue-Green (instant full-traffic switch, instant rollback) with Canary (gradual ramp-up monitored). Know which is appropriate for a high-risk migration.
5. Assuming 100% code coverage means correct code. Always mention the coverage $\neq$ correctness trap (the empty-list average([]) → ZeroDivisionError bug) when discussing testing quality.
6. Getting SemVer bumps wrong. A required new parameter or removed field is MAJOR, not MINOR — even if the change “adds” functionality. A new optional parameter with a default is MINOR.
7. Forgetting Hyrum’s Law when discussing legacy migration or breaking changes. Undocumented behaviour that consumers depend on is just as real as documented contracts.
8. Conflating Monitoring (known unknowns — “is the CPU high?”) with Observability (unknown unknowns — “why did the system slow down at 2:37 p.m. when no metric crossed a threshold?”).
9. Applying Brooks’s Law only qualitatively. For full marks on quantitative parts, show the $\frac{n(n-1)}{2}$ calculation with the specific team sizes from the scenario.
10. Discussing AI risk questions generically instead of naming the specific failure mode — hallucination, technical debt of ignorance, training-data bias, reasoning ceiling — that the scenario is actually illustrating.

Final Exam Checklist

Before submitting your answers, verify:

• Every abstract principle is grounded in a named case study or framework.
• Every sub-part of every question is answered, in proportion to its marks.
• Lookalike concept pairs are correctly distinguished: FR/NFR, Mock/Stub, Monitoring/Observability, Blue-Green/Canary, A/B Testing/Canary, MTBF/MTTR, Backward/Forward compatibility.
• Quantitative reasoning is used where the scenario allows it (communication paths, SemVer numbers, error budgets).
• “Discuss” or “evaluate” questions have a balanced pros/cons structure followed by a justified conclusion.
• Concepts are applied to the scenario’s specific details, not recited generically.
• Version-bump decisions are correct: breaking change → MAJOR; new feature (backwards-compatible) → MINOR; bug fix → PATCH. When in doubt, bump MAJOR.
• For security questions: confidentiality, integrity, and availability implications are covered as relevant; access control mechanisms (ACL vs capability) are correctly distinguished if asked.

---

This paper rewards concrete, well-grounded reasoning over generic definitions. The case studies — Therac-25, Mars Climate Orbiter, London Ambulance Service, Post Office Horizon, Boeing 737 MAX, Y2K, Netscape, Left-Pad, Log4Shell, Windows 95/SimCity — are not decoration. They are the evidence base examiners expect you to draw on to justify engineering principles. Learn the mechanism behind each one, not just the headline, and you will be able to construct a strong, specific answer to almost any scenario-based question on this paper.

Good luck in your Tripos.