NCoE Selection Test common mistakes
NCoE Selection Test · Understand the traps and how to avoid them.
Computing subnet boundaries, host counts, and usable ranges from memory in the exam instead of deriving them from the prefix length, then choosing an answer that is off by one address or by one subnet.
Candidates memorize a handful of common masks (for example /24, /25, /30) and then try to pattern-match unfamiliar prefixes such as /22 or /27 under time pressure, so they confuse the all-zeros network address with the all-ones broadcast address or forget that the usable host count is 2^n minus 2.
What to do instead
Before the exam, practice a fixed derivation routine: write the prefix as a binary mask, identify the block size as 256 minus the interesting octet value, enumerate the actual network and broadcast addresses, and count usable hosts as 2^(32-prefix) minus 2. Drill mixed prefixes (/21, /26, /28, /30) and point-to-point /31 and /127 cases until the routine takes under a minute per item.
Treating TCP and UDP behaviour, port numbers, and the three-way handshake as interchangeable, so questions about connection setup, retransmission, or which protocol a service uses are answered with the wrong transport.
Candidates learn a list of well-known ports and general protocol names but never connect them to observable behaviour, so they cannot distinguish a SYN-timeout symptom from a UDP packet-drop symptom or identify which protocol carries a given service such as DNS over TCP for large responses.
What to do instead
Build a transport-layer comparison table covering handshake sequence, reliability and retransmission, ordering, flow and congestion control, header fields, and typical failure symptoms. Attach each service you study (DNS, DHCP, NTP, SNMP, syslog, HTTPS, SSH) to its transport and port, and note the specific exception cases such as DNS falling back to TCP and DHCP using broadcast UDP.
Choosing a routing protocol or path based on administrative distance alone, or assuming the longest-prefix match always wins regardless of other attributes, when the scenario requires reasoning about metric, preference, and policy together.
Candidates memorize a distance table but do not internalize the order of operations: longest prefix match first, then administrative distance among sources for the same prefix, then protocol metric, then policy attributes. They also forget that a more specific route wins even when it comes from a less-preferred source.
What to do instead
Practice the decision sequence explicitly: match prefix length, then compare administrative distance for equal prefixes, then compare metric within the same protocol, then apply policy such as local preference or MED for BGP. Work through scenarios with overlapping static, OSPF, and BGP routes and write out which entry is installed and why before checking the answer.
Confusing spanning-tree port roles and states, or forgetting how root bridge election and path cost work, so questions about loop prevention and convergence produce the wrong blocked port or the wrong expected state.
Candidates memorize role names without understanding the election order (lowest bridge ID for root, then lowest cost to root, then lowest sender bridge ID, then lowest port ID) and mix up the legacy 802.1D state list with RSTP's simplified roles and states.
What to do instead
Rehearse the election algorithm step by step on small topologies with three to five switches, computing root path cost and tie-breaking explicitly. Separately list 802.1D states and timers versus RSTP roles and states, and note how features such as PortFast, BPDU Guard, and Root Guard change expected behaviour.
Answering access-control questions by evaluating only the first matching rule or only the most specific rule, without tracing the actual first-match, top-down evaluation order and implicit deny of the list being described.
Candidates read ACL or firewall entries as a set of independent permissions rather than an ordered program, so they miss that a broad permit above a specific deny makes the deny unreachable, or they forget that an implicit deny-all exists at the end of many list types.
What to do instead
For every ACL or policy question, rewrite the list in order and trace each test packet line by line, stopping at the first match. Check for shadowed and unreachable entries, confirm direction and interface binding, and state the implicit deny explicitly. Practice with wildcard masks and with stateful versus stateless behaviour so return traffic is handled correctly.
Mixing up authentication, authorization, and accounting, or assuming a given 802.1X component performs a function it does not, when answering identity and network access control questions.
The three A's are taught together and candidates collapse them into a single idea, so they cannot say which component makes the policy decision, which enforces it, and which merely records events. They also confuse the roles of supplicant, authenticator, and authentication server.
What to do instead
Map each function to its component explicitly: supplicant supplies credentials, the authenticator (switch or access point) relays and enforces, and the authentication server (RADIUS) validates and returns attributes. Then separate authentication (who you are), authorization (what you may do, often via dynamic VLAN or ACL assignment), and accounting (what you did, via logging). Test yourself by describing a failed-authentication flow end to end.
Assuming DHCP assigns addresses from a single flat pool, ignoring relay behaviour, option scoping, and the DORA sequence, so questions about clients on remote subnets or about address conflicts are answered incorrectly.
Candidates learn DORA as a slogan without the addressing details: discover is broadcast, relay agents forward to the server, the server selects a pool by the relay's source address, and options such as router, DNS, and lease time are scoped per subnet. They also forget conflict detection and lease renewal behaviour.
What to do instead
Walk through the full exchange for both local and relayed clients, noting source and destination addresses at each step and how the server chooses the correct scope. Memorize the common options and their scope, the renewal and rebinding timers as fractions of lease time, and the difference between a DHCP relay and a DHCP proxy. Practice diagnosing an address conflict and an exhausted pool.
Reading a monitoring graph or counter in isolation and declaring a cause, rather than correlating interface errors, latency, jitter, and loss with the layer where the fault actually sits.
Candidates jump from a single symptom such as high utilization to a conclusion such as bandwidth exhaustion, without checking whether the real signal is CRC errors, duplex mismatch, queue drops, or routing instability. They also misread counters that reset or that count in different units.
What to do instead
Adopt a layered triage order: physical and interface counters first (errors, discards, duplex, speed), then path and latency measurements, then application-level response time. For each metric, state what it proves and what it does not. Practice interpreting paired graphs, such as rising latency with flat throughput, and distinguish congestion from loss from misconfiguration.
Treating an automation script as correct because it produces the intended output on the happy path, without considering idempotency, error handling, and the blast radius of a partial failure.
Candidates focus on syntax and the successful run, so they miss that re-running the script duplicates configuration, that a mid-run failure leaves devices in inconsistent states, and that templated configuration applied broadly can push an error to every device at once.
What to do instead
For every automation scenario, check three properties: is the operation idempotent, does it fail safely and report clearly, and is the change scoped and reversible? Practice reading scripts for missing error checks, unguarded loops over inventory, and hard-coded credentials. Favor declarative modules with check and diff modes, and describe a rollback plan before applying a change.
Skipping the operational wrapper around a change: no documented baseline, no rollback step, no verification criteria, and no record of approval, so a technically correct configuration is still the wrong answer for a change-management question.
Candidates treat change management as paperwork and answer with the configuration command instead of the process, forgetting that exam scenarios often ask what should happen before or after the technical step rather than the step itself.
What to do instead
Memorize the standard change lifecycle: request and risk assessment, approval, scheduled window, pre-change backup and baseline capture, implementation, verification against explicit success criteria, and documented rollback trigger. When a question asks for the next action, locate it in that lifecycle. Practice writing a short change record with rollback and verification for a routing or ACL change.