CPDN common mistakes
CPDN · Understand the traps and how to avoid them.
Memorising acronym expansions (VLAN, VRF, MTU, QoS, SPAN, etc.) without being able to state which layer, plane, or scope each one operates at, then guessing whenever a stem asks 'at which layer/scope does this occur'.
Expansion lists are the easiest thing to drill, so candidates over-invest there and under-invest in the conceptual model that the exam actually tests against.
What to do instead
Build a one-page mapping grid: term -> OSI layer -> plane (data/control/management) -> local vs. end-to-end scope -> typical symptom when misconfigured. Re-derive the grid from memory before each study session until it is automatic.
Reading a scenario about traffic forwarding and answering in terms of configuration/management activity, or vice versa, because control-plane, data-plane, and management-plane traffic are treated as synonyms.
The three planes share vocabulary (both 'routing' and 'routed traffic' sound like data movement), and stems rarely name the plane explicitly.
What to do instead
Before answering any plane question, silently complete three sentences: 'Who makes the decision?', 'Who carries the packets?', 'Who administers the device?' Assign the stem's subject to exactly one, then eliminate options that belong to another plane.
Selecting the most redundant, highest-performance, or most feature-rich design option even when the stem states hard constraints such as budget ceiling, rack units, existing cabling, latency target, or a fixed change window.
Design questions reward constraint satisfaction, but candidates are trained by experience to equate 'better design' with 'more resilience', so they optimise the wrong variable.
What to do instead
Underline every quantitative or absolute constraint in the stem first. Cross out any option that violates even one hard constraint before comparing the survivors on quality; if two survive, prefer the one that satisfies the stated requirement with the least added complexity.
Sizing a design to the current port count, bandwidth figure, or site count given in the stem without calculating growth headroom, then choosing the option that fits today exactly.
The growth horizon is usually stated in a subordinate clause (for example, a three-year forecast or a per-year percentage), so it is easy to skim past while focusing on the concrete numbers.
What to do instead
Do the arithmetic explicitly: current figure times the stated growth factor, rounded up to the next supported tier. Treat any option whose capacity equals or barely exceeds the current figure as a distractor unless the stem explicitly says growth is out of scope.
Answering implementation questions with a correct-looking command or setting while ignoring prerequisite sequencing, so the chosen step would fail if performed in the order implied by the stem.
Candidates pattern-match on the configuration keyword in the stem and retrieve the associated command, without checking whether the underlying dependency (for example, the VLAN existing before the trunk permits it, or reachability before a policy is applied) has been satisfied.
What to do instead
For every implementation item, write the dependency chain in order (prerequisite -> action -> verification). If the stem's described state does not include the prerequisite, the correct answer is usually the prerequisite step, not the action the stem names.
Choosing the option with the most capabilities or the newest feature to satisfy a narrow requirement, instead of the minimum change that meets that requirement.
More features reads as 'more correct' under exam pressure, and vendors' feature-dense terminology reinforces that bias.
What to do instead
Apply a least-change rule: state the single requirement in one sentence, then reject any option that adds behaviour the requirement does not ask for, because extra scope means extra risk and extra failure surface.
Treating operational and management items (monitoring method, backup and restore validation, change workflow, log retention) as 'no real answer' and picking whichever option sounds administrative rather than technically precise.
These topics feel less concrete than configuration, so candidates study them last and answer from intuition; they then confuse what a tool measures with what it configures.
What to do instead
For each operational mechanism, memorise a one-line 'what it actually tells you' statement (for example, counters versus sampled flows versus event logs versus configuration archive). Answer by matching the stem's question ('what happened?', 'how much?', 'what changed?') to the mechanism that produces that evidence.
Answering a question about process (change control, escalation, incident handling, rollback authority) with a device-level technical fix, because the technical fix would also solve the underlying problem.
Stems in operations domains often describe a real fault, which pulls attention straight to the technical remedy and away from the subject of the question.
What to do instead
Classify the stem before reading options: is the question asking 'what should be done to the device' or 'what should be done by the organisation'? Match the option set to that subject, and discard technically correct options that answer the other question.
Using threat, vulnerability, risk, and control interchangeably, and selecting 'encrypt it' or 'add a firewall' whenever a security option appears, regardless of whether the stem asks about likelihood, impact, exposure, or a compliance obligation.
Everyday security language blurs these terms, and the strongest-sounding control always reads as the safest choice.
What to do instead
Label each noun in the stem with exactly one tag (asset, threat, vulnerability, likelihood, impact, control, requirement) before evaluating options. Then answer the tag the question actually asks about, and reject controls that address a different tag than the one requested.
In troubleshooting items, jumping to the remediation or to hardware replacement instead of the diagnostic step that best narrows the fault domain, and failing to distinguish 'most likely cause', 'next step', and 'how to verify the fix'.
Experienced candidates recognise the fault signature and go straight to the cure, but the question is usually asking which action most efficiently isolates the problem; also, the three question phrasings look nearly identical when skimmed.
What to do instead
Tag the question type explicitly (cause / next action / verification). For 'next action', choose the test that halves the remaining fault space (bottom-up from the physical layer, or the midpoint of the path), not the fix; for 'verification', choose the step that confirms the original symptom is gone without introducing a new dependency.