Design and Planning
Design starts with requirements, not diagrams
Questions in this domain test whether you can translate a business need into a defensible technical design. Learn to separate functional requirements (what the system must do) from non-functional requirements (availability, performance, scalability, cost, compliance). A design that ignores a stated constraint is wrong even if the technology is modern.
Know the standard topologies and when each fits. Star for access, hub-and-spoke for branch aggregation, partial mesh for resilient WAN cores, full mesh for small clusters only (it scales as n(n−1)/2 links), and spine-leaf for east-west data-center traffic. Know the three-tier hierarchical model - core, distribution, access - and why collapsing layers is a trade-off rather than an upgrade.
Redundancy is a budget question. Identify single points of failure by asking, of every component, "what fails if this one thing fails?" Then price the fix. Redundant links need redundant paths (routing convergence, spanning tree behavior) and redundant power, not just a second cable. High availability is not backup; they solve different failures.
Capacity and addressing. Plan IP ranges with growth headroom, keep a per-VLAN subnet plan, and reserve a management network with out-of-band access. For wireless, budget PoE against switch power and cable distance. Document the design - addressing plan, topology, cable schedule, and change log - because undocumented designs fail the operations domain later.
Rule of thumb
Design to peak measured load plus 20–30% headroom. If a proposed design has no headroom or no documented SPOF analysis, it is almost always the wrong answer.
Worked example
A branch needs 90% availability of a single WAN link. Two diverse ISP links with automatic failover cost less than the annual downtime cost, so redundancy is justified; a second cable on the same conduit is not diverse and answers "no."