System Design — Red Team Edition
Operation Cedar Lattice — architecture walkthroughs. This section presents five design problems that surface in senior and principal-level red team interviews. Each walkthrough follows the whiteboard format: requirements → constraints → high-level architecture → component deep-dive → tradeoffs → detection-forward wrap-up.
These are design discussions, not implementation blueprints. The goal is to demonstrate architectural thinking, tradeoff awareness, and the ability to reason about a system from both the attacker and defender perspective simultaneously.
Design Problems
| File | Problem | Interview context |
|---|---|---|
| 01-c2-infrastructure.md | Design a scalable, resilient C2 infrastructure for a 90-day red team engagement | Phase 08 |
| 02-ad-attack-path-solver.md | Design an Active Directory attack path discovery and prioritization system | Phase 05 |
| 03-cloud-iam-audit.md | Design a cloud IAM privilege escalation audit system for multi-cloud environments | Phase 09 |
| 04-engagement-planning.md | Design an engagement planning and artifact management platform for a red team consulting firm | Phases 00–01 |
| 05-purple-team-platform.md | Design a purple team exercise tracking and detection-gap reporting platform | Phase 12 |
Whiteboard format
Each design document follows this structure:
- Problem statement and requirements — functional requirements (what must the system do) and non-functional requirements (latency, scale, availability, OPSEC constraints)
- Constraints and assumptions — what is in scope, what is explicitly out of scope
- High-level architecture — ASCII diagram + component list
- Component deep-dives — one section per major component; data model, API, key decisions
- Tradeoffs — what was chosen and why; what was sacrificed
- Detection-forward perspective — how would a defender detect each architectural component; what does the design do to reduce detection surface; what is the residual detection opportunity
How to practice
- Read the problem statement only. Close the rest of the document. Spend 5 minutes sketching your architecture on paper.
- Compare. Open the document and compare your design choices to the walkthrough. Note differences — not to judge which is correct, but to understand the tradeoffs.
- Narrate out loud. The interview is oral + whiteboard. Practice saying your design choices aloud: "I would choose X because Y, and the tradeoff is Z."
- Time yourself. A system design interview is 45–60 minutes. You should reach the deep-dive section within 10–15 minutes of starting.
- Ask clarifying questions. In the real interview, ask the interviewers the same clarifying questions the document poses in the Constraints section — this signals maturity.