CNPA common mistakes
CNPA · Understand the traps and how to avoid them.
When asked to size a subnet, the candidate picks the prefix that yields exactly the required number of usable hosts, forgetting that two addresses per subnet (network and broadcast) are unusable, so a /27 is chosen for a 30-host requirement instead of a /26.
Textbook formulas are memorised as '2^n minus 2' but applied only to the host bits of the given prefix rather than recomputed for each candidate prefix. Under time pressure the candidate counts host bits, sees 32 - 27 = 5, computes 30 usable, and stops without checking whether the requirement is 'at least 30' versus 'more than 30'.
What to do instead
Before computing, write the requirement as an inequality: usable hosts >= N. Then test prefixes from /24 downward using the table 2^h - 2 until the inequality holds, and only then convert to dotted-decimal. Practise a fixed drill of ten requirements that sit exactly on a power-of-two boundary (14, 30, 62, 126 hosts) so the off-by-two trap becomes automatic.
The candidate reads a MAC address table output and concludes a frame will be flooded to all ports when the destination MAC is present in the table, or concludes it will be unicast when the destination is absent.
The candidate conflates 'learning' with 'forwarding' and does not trace the decision order: look up destination, if found forward out that port, if not found flood out all ports in the VLAN except the ingress port. The presence of a dynamically learned entry feels like proof of reachability, which it is not.
What to do instead
Recite the switch decision sequence aloud for every exhibit: ingress port VLAN membership, source MAC learning, destination lookup, then forward or flood. Practise with a table where the destination MAC appears on the same port as the ingress (frame is filtered) and where it appears on a different VLAN (frame is flooded within the ingress VLAN).
The candidate treats a routing table with multiple matching entries as a longest-prefix problem but then selects the route with the lowest administrative distance first, or selects the lowest metric across routes from different protocols.
Administrative distance and metric are both 'numbers that pick the winner', and study material often lists them together. The candidate forgets the strict ordering: longest prefix match first, then administrative distance among equal prefixes, then metric only within the same routing protocol.
What to do instead
Apply a three-pass method to every routing-table question: pass one, list only entries whose prefix contains the destination; pass two, keep the longest of those; pass three, if tied, compare AD, then metric. Build a five-row table with overlapping prefixes from static, OSPF, and EIGRP sources and work the passes explicitly until the order is reflexive.
The candidate answers a troubleshooting scenario by naming the OSI layer of the symptom rather than the layer where the fault must be verified, for example labelling 'cable unplugged' as a Layer 2 problem because it involves a switch port.
Layer names are learned as vocabulary attached to devices (hubs are Layer 1, switches Layer 2, routers Layer 3) rather than as abstractions attached to functions. A physical link failure observed on a switch port is therefore misfiled as switching.
What to do instead
Classify by the function that failed, not the device that reported it: no link light or no carrier is Layer 1 regardless of what reports it. Drill with twenty short symptom statements and force a one-line justification for each ('carrier absent, so Layer 1') before naming the layer.
The candidate configures or evaluates a wireless deployment using only signal strength and ignores channel width, overlap, and non-overlapping channel sets, recommending channels 1, 6, and 11 in the 5 GHz band or assuming 40 MHz channels are always better.
2.4 GHz channel planning is taught heavily because it is simple, and the candidate transfers the rule to 5 GHz where the channel set is far larger and bonding changes the overlap picture. Higher throughput numbers on wider channels create a bias toward 40 and 80 MHz without considering co-channel interference in dense areas.
What to do instead
State the band first, then the channel plan: 2.4 GHz uses 1/6/11 at 20 MHz; 5 GHz has many non-overlapping 20 MHz channels and bonding must be checked against neighbouring APs. For any design question, write the band, the channel width, and the resulting non-overlapping channel list before choosing.
The candidate reads a packet capture or protocol description and misidentifies which protocol handles a function, for example assigning port allocation to TCP when the application uses UDP-based DNS, or claiming DHCP uses TCP because it 'reliably delivers leases'.
Port numbers are memorised as a flat list without the transport protocol attached, and reliability is assumed to require TCP. The candidate also confuses the well-known port of a service with the ephemeral source port used by the client.
What to do instead
Memorise services as protocol-port pairs (DNS 53 UDP and TCP, DHCP 67/68 UDP, NTP 123 UDP, SNMP 161/162 UDP, HTTPS 443 TCP). For each, state in one sentence why that transport was chosen, and practise identifying client ephemeral ports versus server listening ports in described exchanges.
The candidate evaluates an access control list or firewall rule set by reading rules in isolation and concludes traffic is permitted, without checking rule order, implicit deny, and the direction of application relative to the interface.
Each rule looks correct on its own, and the candidate does not simulate the packet against the list from the top. Implicit deny at the end and the inbound/outbound perspective of the interface are easy to overlook because they are not written in the rule text.
What to do instead
Walk the packet through the list line by line, top to bottom, and stop at the first match. Always ask three questions: which interface and direction, does an earlier rule already match, and is there an implicit deny at the end. Practise with a ten-line ACL where a broad permit near the top shadows a specific deny below it.
The candidate answers a subnetting question in binary or by longhand division and runs out of time, leaving later questions unanswered or guessed.
The candidate learned the concept through binary conversion and never built a fast decimal shortcut, so each question costs two to three minutes instead of twenty seconds. Exam time pressure then compounds errors on the questions that follow.
What to do instead
Memorise the block-size table (mask value 128, 192, 224, 240, 248, 252, 254, 255 mapped to block sizes 128, 64, 32, 16, 8, 4, 2, 1) and the powers of two to 2^12. Compute subnet boundaries by subtracting the block size from 256 and counting in that increment. Time yourself on twenty questions with a two-minute cap.
The candidate describes a VLAN as a security boundary and assumes hosts in different VLANs cannot communicate without explaining that inter-VLAN traffic requires a Layer 3 device and a policy decision.
VLANs are taught alongside broadcast domain separation, and the candidate equates 'separate broadcast domain' with 'isolated'. The role of the router or Layer 3 switch, and of any ACL applied there, is omitted from the mental model.
What to do instead
For every VLAN question, state three things: broadcast domain boundary, Layer 2 boundary, and the Layer 3 path required for inter-VLAN traffic plus the policy that permits or denies it. Draw a two-VLAN topology with a router-on-a-stick and label the trunk, subinterfaces, and ACL attachment point.
The candidate selects a troubleshooting step that jumps to a conclusion, such as replacing a cable or reloading a device, before establishing whether the problem is isolated to one host, one segment, or the whole network.
Real-world instinct and anecdotal fixes dominate over a structured method. The candidate recognises a familiar symptom and recalls the fix that worked once, skipping the divide-and-conquer step that the question is actually testing.
What to do instead
Use a fixed sequence for every scenario: define the problem, gather symptoms from at least two points, determine scope (single host, subnet, or network), form a hypothesis, test it, then act. Practise by writing the scope question first for ten scenarios before considering any remedy, and reject any answer that changes hardware before scope is established.