CNPLE common mistakes
CNPLE · Understand the traps and how to avoid them.
Treating every design question as a hunt for a single 'correct' technology instead of first extracting the stated requirements (scale, budget, availability target, existing constraints) and then eliminating options that violate one of them.
Candidates drilled on recall-style questions jump to the technology they know best, so they pick a plausible-sounding design that contradicts a hard constraint buried in the stem, such as a stated RTO or a legacy protocol that must be retained.
What to do instead
Before evaluating answers, write down the two or three explicit constraints from the scenario and score each option against them; discard any option that fails a stated requirement even if it is otherwise technically sound, then justify the survivor in one sentence.
Designing a hierarchical campus or WAN topology without sizing the aggregation and core layers for the stated traffic volume and redundancy requirement, producing a collapsed-core answer when the scenario calls for device or link redundancy.
The three-tier model is memorized as a diagram, so candidates reproduce layer names without connecting them to the scenario's device counts, port density, or failure-domain expectations, and miss that the stem rules out a single distribution switch.
What to do instead
For each topology question, map the scenario's device counts and availability language onto the layers explicitly, state how many distribution devices and uplinks are needed, and verify the chosen design still forwards traffic when any single link or device fails.
Applying a routing-protocol fact without checking the scenario's topology and metric context, for example assuming OSPF will always prefer the lowest-bandwidth path or that a floating static route works without a matching administrative distance comparison.
Protocol behaviours such as OSPF cost derivation, EIGRP feasibility conditions, and administrative distance tie-breaks are learned as isolated rules and then applied to stems where the relevant values or topology are different from the memorized example.
What to do instead
For every routing answer, restate the metric formula or tie-break rule being used, plug in the scenario's actual values (reference bandwidth, interface speeds, ADs), and show the resulting path selection before choosing an option.
Configuring or evaluating a trunk/STP scenario without tracing VLAN propagation end to end, so an answer leaves a VLAN pruned on a trunk, missing from the allowed list, or blocked by an STP topology change that the stem implies.
Switching questions mix Layer 2 concepts (native VLAN, allowed lists, root bridge election) and candidates validate only the feature named in the question rather than the full forwarding path for the VLAN in question.
What to do instead
Trace the specific VLAN from access port to access port: confirm it is allowed on every trunk, that the native VLAN matches on both ends, and that the intended root bridge wins the election by priority and MAC before accepting the answer.
Answering a security scenario with a control that does not match the threat layer described, such as proposing an ACL for a threat that requires authentication or proposing 802.1X for an east-west data-center segmentation requirement.
Security controls are memorized as a list of good practices, and candidates select the most familiar control rather than matching the control's enforcement point to where the scenario says the attack occurs.
What to do instead
Classify the threat first (identity, network path, data at rest, management plane), then choose the control whose enforcement point sits on that path, and state explicitly what the control inspects and where it is deployed.
Treating a troubleshooting stem as a configuration audit and listing every misconfiguration found, instead of isolating the single fault that explains all the reported symptoms and matches the first diverging step in the documented flow.
Stems often contain realistic but irrelevant detail, and candidates who verify each line item sequentially run out of time or select a fix that resolves a real but unrelated issue without restoring the reported service.
What to do instead
Work the layered path (physical, then Layer 2, then Layer 3, then services) and at each layer ask whether the symptom would still occur; stop at the first layer where observed behaviour diverges from expected and choose the fix that restores that layer.
Mixing up management-plane, control-plane, and data-plane symptoms when diagnosing an outage, for example attributing a forwarding failure to a routing protocol adjacency that is actually up, or blaming an ACL when the device is unreachable for management only.
Candidates conflate 'I cannot reach the device' with 'the network is down', so they chase a management-path problem as if it were a transit failure, or vice versa, and pick a remediation aimed at the wrong plane.
What to do instead
For each symptom, state which plane it exercises (can I log in, are adjacencies formed, does user traffic forward) and confirm the plane that actually fails; then verify the fix addresses that plane without assuming the others are healthy.
Choosing a service design (DHCP relay, NAT, DNS, QoS marking) without checking where the service boundary sits relative to the routed domain, so a relay agent is placed on the wrong side of a broadcast boundary or NAT is applied where return traffic cannot be translated.
Service features are learned as standalone configurations, and candidates do not map the broadcast domain, routing boundary, and translation point onto the scenario's diagram before selecting an option.
What to do instead
Sketch the broadcast domains and routed hops from the stem, mark where the client, server, and translation point sit, and confirm the chosen service configuration has a valid forward and return path across each boundary before answering.
Reading automation and programmability items as syntax quizzes and selecting an API, data model, or tool based on familiarity rather than on the scenario's stated idempotency, scale, or transport requirement.
Candidates memorize command names and payload formats but do not connect declarative versus imperative intent, REST versus NETCONF transport, or model-driven versus CLI scraping to the operational requirement the scenario describes.
What to do instead
Extract the operational requirement first (must be idempotent, must return structured data, must work over an existing HTTPS-only path), then map each candidate technology to that requirement and eliminate any that cannot satisfy it.
Answering governance and professional-practice items by instinct about 'best practice' without citing the specific policy, change-control step, or documentation obligation the scenario implies, and skipping the requirement to record and communicate a change.
These items look like soft-skills questions, so candidates answer quickly with a general principle and miss that the stem hinges on a defined process step such as approval before implementation or rollback criteria defined in advance.
What to do instead
For each governance item, identify the process stage the scenario is at (request, review, approval, implementation, verification, documentation) and choose the action that belongs to that stage, ensuring approval and rollback planning precede any configuration change.