CCDE common mistakes
CCDE · Understand the traps and how to avoid them.
Reading the scenario and immediately sketching a topology or picking a technology before extracting the stated business and technical requirements, so the design answer defends technology choices instead of requirement coverage.
CCDE scenarios are long and time-constrained; candidates default to the familiar engineering reflex of 'design first, justify later', and the business-alignment wording reads like background rather than the scoring criteria.
What to do instead
Before drawing anything, spend the first minutes writing a numbered requirements list: business drivers, constraints, existing environment, growth/scale figures, and explicit non-goals. Map each later design decision to a numbered requirement, and explicitly show where a requirement is traded off against another.
Treating the scenario's stated constraints (budget, legacy gear that cannot be replaced, regulatory separation, staffing skill level) as optional context and proposing a greenfield best-practice design that ignores them.
Candidates study ideal reference architectures and want to demonstrate breadth; constraints feel like noise that weakens the 'correct' answer, so they get minimized or silently dropped.
What to do instead
Maintain a separate constraint register and, for every proposed change, annotate whether it fits or violates a constraint. Where a constraint blocks the ideal design, state the compromise and the residual risk explicitly rather than omitting the constraint.
Designing a flat or purely Layer 2 campus with large VLANs stretched across buildings and no defined Layer 3 boundary, then defending it with 'simpler operations'.
Layer 2 is what most engineers operate daily, and stretching VLANs feels like it preserves mobility and simplifies addressing; the failure-domain and convergence implications are not felt until the scenario asks about blast radius or reconvergence.
What to do instead
Define an explicit Layer 3 boundary at the building or distribution block, size VLANs to a documented host count, and describe the failure domain for each layer. If a VLAN must span sites, state the specific application requirement that forces it and the mitigation (first-hop redundancy, loop prevention, storm control).
Choosing a single WAN transport or single provider for all sites without discussing per-application transport mapping, provider diversity, or the failure behaviour when the primary path degrades rather than fails.
Cost-driven and simplicity-driven thinking dominates, and 'diversity' is often reduced to 'two links' without checking whether they share conduit, provider, or PoP. Degradation (latency/jitter/loss) is also harder to reason about than hard down.
What to do instead
Build a transport-to-traffic matrix (which applications ride which transport and why), verify true path diversity at the physical and provider level, and describe behaviour under brownout conditions, not just link loss. State the SLA assumptions you are relying on.
Proposing a data center or cloud connectivity design without addressing address overlap, return-path asymmetry, or the failure semantics of the interconnection (for example what happens on a single cross-connect or tunnel endpoint failure).
Cloud connectivity is often learned as a menu of options (dedicated interconnect, site-to-site VPN, transit gateway) rather than as a set of failure and addressing problems; overlap and asymmetric return paths only surface during migration or failover.
What to do instead
Explicitly document the address plan and NAT/overlap strategy, trace the forward and return path for each traffic class across the hybrid boundary, and enumerate failure scenarios (single link, single device, single region) with the resulting behaviour and convergence expectation.
Applying routing policy by memorizing where a route-map or filter 'usually' goes, without stating the direction, the scope, and the intended effect on the specific route flow in the scenario.
Policy placement is learned as recipes; under exam pressure candidates reproduce a familiar configuration pattern instead of reasoning about which router sees which prefix in which direction.
What to do instead
For every policy, write a one-line intent statement: source of routes, direction (in/out), match criteria, action, and expected result on the RIB/FIB. Sanity-check by tracing a specific prefix hop by hop through the design before committing to the placement.
Treating security as a perimeter appliance bolted onto the design, with no trust model, no segmentation rationale, and no description of inspection placement relative to traffic flows.
Security is frequently a separate team's domain, so candidates add a firewall symbol and consider the requirement met; the scenario's compliance or insider-threat drivers are not connected to topology decisions.
What to do instead
State the trust zones and the data flows between them, then place enforcement points where those flows actually cross. For each control, name what it protects against and what it costs in latency, complexity, and operational burden, and identify where encryption terminates.
Adding QoS, multicast, or other network services as an afterthought with no classification model, no admission or boundary policy, and no statement of which traffic is treated differently and why.
These topics are studied as feature configuration rather than as end-to-end design problems; candidates can configure a policy-map but struggle to justify marking boundaries or rendezvous point placement.
What to do instead
Define the service model top-down: traffic classes derived from business applications, marking at the first trusted boundary, per-hop behaviour, and where congestion is expected to occur. For multicast, justify the distribution model, RP or anycast-RP placement, and the scope of each group range.
Proposing automation or a controller-based approach without describing the source of truth, the change workflow, rollback, or how the design behaves when the automation platform is unavailable.
Programmability is often framed as a tooling choice rather than a design element, so candidates name a platform and skip the operational model, which is exactly what the scenario is testing.
What to do instead
Describe the intended-state source, the pipeline from intent to device, pre-change validation, and post-change verification, plus the manual fallback path and the blast radius of a bad push. Tie each element to an operational requirement in the scenario.
Presenting a single design option with no alternatives, no trade-off analysis, and no explicit statement of what was rejected and why.
Candidates believe the exam wants the one right answer and fear that offering alternatives looks indecisive; in practice the scenario rewards justified decision-making under competing constraints.
What to do instead
For each major decision, present at least two viable options, compare them against the stated requirements and constraints, and state the chosen option with its accepted downsides and the trigger that would justify revisiting it.