Common design traps
Warning: These are tempting wrong answers
Each trap below looks reasonable and is often the offered option a candidate reaches for first. The CCDE-correct move is in the fix. These patterns are distilled from worked practice scenarios and generalised (and AI-updated) - they are answer-selection discipline, not new technology.
The traps
- Rip-and-replace when the core cannot absorb it. Proposing SD-WAN or a new transport without checking the chokepoint - the supplied utilization may show the DC uplink/core is already near saturation. Fix: check capacity and headroom first (SD-WAN design, Bandwidth and capacity planning).
- An L2/VPLS stretch that silently breaks routing. Migrating an L3 MPLS service to VPLS/L2 removes the routing the provider used to supply (default gateways, store-to-store policy) and stretches L2 across the WAN. Fix: re-provide routing and remember L2 does not scale (MPLS L3VPN and L2VPN, Generic routing and addressing - PBR, NAT, RIB-FIB).
- Treating a transport swap as a no-op. "Same equipment, scripted overnight" still changes reachability, forwarding, and policy. Fix: map exactly what the old service provided before swapping it.
- Gold-plating resilience beyond the stated tolerance - adding DR/redundancy a site does not need (it tolerates a six-hour outage), or the inverse, missing a genuine single-DC business-continuity gap. Fix: size to the RPO/RTO and tolerance (Transport resiliency, diversity, and migration, Network Design).
- Choosing the strongest technology over the least-disruptive adequate one. The newest/most-capable option is not the answer if a smaller change meets the requirement and the customer resists change (Business Strategy Design).
- Inline inspection on a lossless / RDMA fabric (AI). Inserting a firewall or DPI into the GPU back-end breaks losslessness and latency. Fix: isolate, enforce at the edges, and encrypt links (Securing the high-performance fabric).
- Ignoring the supplied data. Deciding without reading the utilization graphs/telemetry that are in the brief specifically to constrain the answer (Network management - traditional vs model-driven).
- Acting on a stakeholder's framing uncritically. An email proposing option X is a prompt to evaluate, not an instruction - the optimal answer may be none of the offered options.
- Recommending change the customer explicitly rejected, without justification. If the brief says "minimize changes," any sweeping-change answer must clear a high bar (Business Strategy Design).
- Over-segmenting / over-engineering for its own sake. Complexity the requirement does not justify is a cost, not a virtue (Security design fundamentals - CIA and defense in depth).
- Making assumptions instead of confirming. Designing to an unstated assumption rather than verifying the requirement - confirm availability, security, and manageability expectations explicitly.
- Applying "best practices" blindly. A best practice that does not fit the context is the wrong answer; justify the practice against this customer's requirements.
- Designing from preconceived notions. Pattern-matching your last design onto a new problem instead of designing from its actual requirements.
How to use this note
Before committing to an answer, scan this list: does your choice trip a trap? If so, either it is wrong, or you must be able to justify why it is right despite the trap (the exam gives partial credit for well-reasoned, defensible choices).
Spaced repetition
What is the most common "rip-and-replace" trap, and the fix?
Proposing SD-WAN/new transport without checking the chokepoint - the supplied utilization may show the core/DC uplink already saturated. Fix: check capacity/headroom first.
Why is migrating an L3 MPLS service to VPLS/L2 a trap?
It removes the routing the provider supplied (default gateways, policy) and stretches L2 across the WAN - you must re-provide routing and it does not scale.
How should you treat an email that proposes a specific solution?
As a prompt to evaluate, not an instruction - the optimal answer may be none of the offered options, and any sweeping change must clear the customer's stated reluctance.
A control or design choice that trips a trap can still be correct if [...] (the exam awards partial credit for defensible reasoning).
A control or design choice that trips a trap can still be correct if you can justify why it is right despite the trap (the exam awards partial credit for defensible reasoning).
Beyond overdesigning (which the Cert Guide equates with gold plating), name three design pitfalls.
Making assumptions instead of confirming requirements, applying best practices blindly without fit-to-context, and designing from preconceived notions (pattern-matching your last design).
Sources
- Patterns distilled from CCDE practice-scenario debriefs; generalised and AI-updated for v3.1.