JNCIA-Design common mistakes
JNCIA-Design · Understand the traps and how to avoid them.
Treating a design brief as a device-configuration exercise: answering 'which CLI command enables this feature' instead of 'which design choice meets the requirement', and picking the option that is technically valid on one box but does not satisfy the stated business or scaling requirement.
Candidates arrive from configuration-heavy tracks (JNCIS/JNCIP style labs) where the reflex is to look for the command that makes something work. JNCIA-Design questions instead present a scenario with constraints (user counts, growth, redundancy, budget) and expect the architect's answer, so the 'it works on one device' option is a distractor.
What to do instead
Before answering, restate the requirement in one sentence: what must the design achieve, at what scale, with what redundancy and budget. Then eliminate any option that only solves a single device or a single point in time. Practise by taking a familiar feature (e.g., a routing protocol choice) and writing the design justification rather than the config.
Confusing the three-tier hierarchical model with the collapsed-core (two-tier) model and applying the wrong one to a given scale: choosing a full core/aggregation/access build for a small single-building site, or a collapsed core for a large multi-building campus with high east-west traffic.
The tier names are memorised, but the decision criteria (port count, geographic distribution, Layer 2 vs Layer 3 boundary, fault-domain size, cost) are not. Exam scenarios deliberately give a size and topology that make one model clearly preferable.
What to do instead
Build a one-page comparison: access = user attachment and PoE; aggregation/distribution = policy, routing boundary, summarisation; core = high-speed resilient transit only. Then map typical triggers: single building under a few hundred users and one wiring closet pair -> collapsed core; multiple buildings or a need to summarise routes between areas -> three-tier. Read each scenario for building count and user count first.
Designing Layer 2 domains that are too large: stretching a single VLAN across an entire campus, or assuming Spanning Tree will provide adequate resilience and convergence for a large flat network, instead of pushing the Layer 3 boundary toward the access layer.
Spanning Tree is familiar and feels 'safe', so candidates keep large bridged domains and rely on STP for redundancy. This ignores blocked-link underutilisation, slow convergence, broadcast scope, and the failure domain created by a single large Layer 2 segment.
What to do instead
For each scenario, ask how many users share a broadcast domain and whether the traffic is north-south or east-west. Default to Layer 3 at the aggregation (or access) with routed links and summarisation; reserve large Layer 2 for cases that genuinely need it (e.g., mobility or legacy constraints) and state the trade-off explicitly. Know that STP is a loop-prevention mechanism, not a capacity or convergence design.
Mixing up WAN service characteristics when selecting a transport: treating MPLS Layer 3 VPN, point-to-point leased line, and internet-based overlay (IPsec/GRE or SD-WAN) as interchangeable, and failing to match the choice to the requirement for any-to-any reachability, SLA/guaranteed latency, encryption, and cost.
All three 'connect sites', so the differentiators (any-to-any vs hub-and-spoke, provider-managed vs self-managed routing, native privacy vs overlay encryption, per-Mbps cost, local internet breakout) blur under exam pressure.
What to do instead
Create a transport matrix with columns: topology supported, who runs routing, built-in confidentiality, typical SLA, relative cost, and best-fit use case. For each scenario, extract the deciding constraint first (e.g., 'must reach all 40 branches directly and carry voice with latency SLA' points to MPLS L3VPN or a managed SD-WAN with SLA-backed underlay; 'two sites, fixed bandwidth, lowest jitter' points to a leased line).
Ignoring underlay vs overlay separation in WAN design: assuming an SD-WAN overlay removes the need to design the underlying transport, or expecting the overlay to fix an underlay that cannot meet latency/loss requirements for real-time traffic.
SD-WAN marketing language ('any transport, application-aware') leads candidates to treat the overlay as a substitute for transport quality. In reality the overlay provides policy, encryption, and path selection, but cannot create bandwidth or reduce physical latency.
What to do instead
In every SD-WAN scenario, separate the two layers: underlay = circuits with measured latency, loss, jitter, and bandwidth; overlay = tunnels, policies, and application steering. Check whether the requirement is reachability/policy (overlay answers it) or hard real-time quality (underlay must answer it). State explicitly which traffic should use which path and why.
Applying classic three-tier enterprise LAN assumptions inside the data centre: designing around large Layer 2 domains and STP instead of a spine-leaf fabric with Layer 3 equal-cost multipathing, and treating oversubscription as an afterthought.
Campus habits carry over. Candidates also under-weight east-west traffic, which dominates in the data centre because server-to-server and storage flows dwarf client-to-server flows, making a scale-up chassis core and STP-based topology a poor fit.
What to do instead
Learn the spine-leaf model as a default: every leaf connects to every spine, routing (often BGP) at the leaf, ECMP for load sharing, predictable any-to-any latency. Be able to explain why this beats a three-tier design for east-west traffic and horizontal scale. Also be ready to compute or compare oversubscription ratios (access-to-uplink bandwidth) and to state the design implication of a 3:1 versus 1:1 ratio.
Confusing redundancy with high availability: proposing two of everything (dual supervisors, dual power, dual uplinks) without checking that the failure domains are actually independent and that the design avoids a shared fate (both links in one conduit, both power feeds on one PDU, both members of a cluster on one rack).
Component counting feels like availability engineering. Exam scenarios often hide a shared dependency, and the 'more hardware' option is the attractive distractor.
What to do instead
For any resilience question, draw the failure domains: device, link, power, rack, site, and control plane. Ask 'if this single element fails, does the service survive?' Verify that dual links terminate on different devices, dual power on different feeds, and that control-plane redundancy (e.g., graceful restart, dual routing engines) is considered separately from data-plane redundancy.
Designing security as a perimeter afterthought: placing a single firewall at the internet edge and assuming internal traffic is trusted, rather than segmenting by trust zone and applying policy between zones (including east-west inside the data centre and between user, guest, voice, and IoT segments).
The classic 'inside is trusted, outside is not' mental model persists, and candidates equate 'we have a firewall' with 'the design is secure'. Modern scenarios include lateral movement, guest isolation, and OT/IoT devices that must not reach corporate resources.
What to do instead
Design zones first: define each zone by trust level and function (internet, DMZ, corporate user, guest, voice, IoT/OT, data-centre application tiers), then place enforcement points between zones and state the default-deny posture. For each scenario, ask which zone pairs need to communicate and which must be blocked, and include guest-to-corporate and IoT-to-corporate isolation explicitly.
Choosing a security control without matching it to the threat and location: for example, relying on host antivirus for lateral-movement containment, putting an IPS where traffic is encrypted and cannot be inspected, or expecting a NAT device to provide security.
Control names are memorised as a list rather than as capabilities with placement constraints. Candidates pick the control with the most impressive name rather than the one that sees the relevant traffic.
What to do instead
For each control, record what it inspects, where it must sit to see that traffic, and what it cannot do. Key placements to know: stateful firewall at zone boundaries; IPS/UTM inline where traffic is decrypted or unencrypted; NAT for address conservation, never as a security control; segmentation for containment. When a scenario involves encrypted traffic, check whether decryption is part of the design before selecting an inspection control.
Answering capacity and growth questions with a point-in-time figure: sizing links, PoE budgets, or address space for today's user count only, and not accounting for stated growth, oversubscription, or summarisation-friendly addressing.
Scenarios often state a growth rate or a multi-year horizon in one clause, and candidates anchor on the current number. Address planning is also treated as bookkeeping rather than a design input for summarisation and scalability.
What to do instead
Extract every quantitative constraint (current users, growth rate, horizon, per-user bandwidth, PoE class per port, device count per closet) into a short list before evaluating options, then compute forward. For addressing, allocate contiguous blocks per site/zone sized for growth so summarisation works, and be prepared to justify the block size rather than just naming a subnet.