Cisco ENCOR 350-401 common mistakes
Cisco ENCOR 350-401 · Understand the traps and how to avoid them.
Treating the 'virtualization' domain as VRF/VXLAN trivia only and never learning the hypervisor data plane (vSwitch, VM NIC, promiscuous mode, VMotion requirements), so scenario items about traffic flow between VMs on the same host are answered by instinct rather than by path analysis.
Candidates come from a switching/routing background and assume 'virtualization' means only overlay networking. The official blueprint also covers hypervisor constructs and cloud deployment models, which many study guides compress into a single paragraph, so candidates never build a mental model of the host-local switching path.
What to do instead
Draw the full packet path for two VMs on the same ESXi host, then for VMs on different hosts in the same VLAN, then across a VXLAN overlay. For each hop, label the vSwitch, port group, physical uplink, and any encapsulation. Rehearse the specific settings (promiscuous mode, MAC changes, forged transmits) and which traffic each affects, and state the VMotion requirements (shared storage or vMotion network, same L2, compatible CPU) from memory.
Configuring OSPF or BGP features without verifying that the underlying prerequisite is in place: for example expecting OSPFv3 to form an adjacency before IPv6 unicast routing is enabled, or expecting eBGP peering to come up when the peer address is unreachable or the update-source is wrong.
Candidates memorize standalone configuration snippets from practice labs but never see the failure state. Exam items present a partial configuration and a symptom, and the candidate cannot connect the symptom to the missing prerequisite because they never broke it themselves.
What to do instead
For each routing protocol, build a 'peering checklist' you can recite: OSPFv3 needs ipv6 unicast-routing, matching area, matching timers, and no passive interface on the link; BGP needs reachability to the neighbor, correct remote-as, correct update-source for loopback peering, and matching authentication. In the lab, deliberately remove each prerequisite one at a time and record the exact error or state change.
Reading a spanning-tree or EtherChannel show command and answering from the topology diagram in the candidate's head rather than from the command output, missing that the root bridge is not the expected switch or that a port is in a non-forwarding state because of a mismatch.
Candidates study STP and EtherChannel conceptually and practise configuration, but rarely practise diagnosis from output. Under time pressure they pattern-match the expected answer instead of reading the actual root ID, port roles, or channel flags in front of them.
What to do instead
Drill output interpretation: given 'show spanning-tree' output, identify the root bridge, the root port on each non-root switch, and any blocked port, then explain why. For EtherChannel, read the flags (SU, P, D, I, s) and map each to its cause (LACP mode mismatch, speed/duplex mismatch, VLAN mismatch, STP state). Do at least twenty of these drills until reading output is faster than recalling theory.
Confusing the roles of the control plane and data plane when answering assurance questions, for example attributing a forwarding problem to a routing-protocol timer when the actual cause is an FIB or hardware-forwarding issue, or expecting a NetFlow record to contain the packet payload.
The assurance domain mixes telemetry tools (NetFlow, SPAN, ERSPAN, SNMP, syslog, model-driven telemetry) with forwarding-plane concepts, and candidates learn the tools as a list of features rather than as answers to specific diagnostic questions. They therefore pick the tool that sounds most advanced instead of the one that observes the layer in question.
What to do instead
Build a table with columns: what it observes (control plane state, per-flow statistics, raw packet bytes, device health metrics, configuration changes), where it runs, and what question it answers. Populate it with show commands, NetFlow, SPAN/ERSPAN, SNMP polling versus traps, syslog, and streaming telemetry. Then answer practice items by first naming the layer and the question, and only then selecting the tool.
Answering SD-WAN and SD-Access items with campus-LAN logic, such as assuming OMP behaves like a routing protocol with adjacency over the transport, or assuming fabric edge nodes perform the same function as a traditional distribution switch including all policy enforcement.
The architecture domain introduces controller-based designs whose separation of control plane (controller), data plane (fabric nodes or WAN edges), and policy (fabric control plane or vSmart) does not map onto the three-tier campus model candidates know. Study material often lists components without explaining the division of responsibility.
What to do instead
For each architecture (SD-Access, SD-WAN, SD-Branch), write a one-page map of which component owns which function: identity and policy, path selection, encapsulation, edge termination. For SD-WAN specifically, distinguish OMP (overlay routing and policy between vSmart and edges) from BGP/OSPF at the LAN/WAN edge, and know which device makes the forwarding decision per packet. Test yourself by predicting where a given policy is configured and where it is enforced.
Treating 802.1X and AAA configuration as a single memorized block, so items about CoA, MAC authentication bypass, or the difference between authentication and authorization are answered by recalling the config rather than the message flow.
Security configuration is easy to copy and hard to reason about. Candidates learn the switch-side commands but never trace the RADIUS exchange, so they cannot say which party initiates reauthentication, what triggers a CoA-Request, or what happens when MAB succeeds after 802.1X times out.
What to do instead
Draw the 802.1X message sequence (EAPOL-Start, Identity, EAP exchange, RADIUS Access-Request/Accept, port authorization) and annotate where MAB, critical VLAN, and CoA fit. Then write out the RADIUS attributes that carry VLAN and ACL assignment and explain which side applies them. Practise predicting the port state after each failure mode: no supplicant, bad credentials, RADIUS unreachable.
Writing automation answers that assume a RESTCONF or NETCONF call succeeds against any device, ignoring that the YANG model must be supported, that the data encoding and media type must match, and that the request targets a specific datastore and path.
Candidates learn Python or Ansible syntax and the general shape of a REST call but not the model-driven programmability contract. Exam items show a URL, a payload, and an error, and the candidate cannot map the error to a model, encoding, or path problem.
What to do instead
Memorize the RESTCONF conventions: the resource path rooted at the data tree, the distinction between configuration and operational datastores, the media types for JSON and XML encoding, and the HTTP methods mapped to read, create, replace, merge, and delete. For NETCONF, know the operation framing and the candidate versus running datastore. Then practise reading a YANG module and constructing the exact path for one leaf.
Assuming a tunneling or overlay technology transports everything, for example expecting VXLAN to carry traffic that the underlay cannot route, or expecting GRE to encrypt payloads, or expecting a tunnel interface to come up without a reachable source and destination.
Overlay technologies are taught as features with configuration, not as layered encapsulations with prerequisites. Candidates conflate 'tunnel is configured' with 'tunnel forwards', and conflate encapsulation with encryption.
What to do instead
For each technology (GRE, IPsec, VXLAN, LISP, DMVPN), write the header stack it adds, what it does and does not protect, and the exact conditions for the tunnel to come up (reachable endpoints, matching parameters, MTU headroom). Then compute the MTU implications for a given underlay MTU and explain where fragmentation or drops would occur.
Answering high-availability items by naming a protocol (HSRP, VRRP, GLBP) without checking the specific parameters in the scenario: virtual IP versus virtual MAC, preemption default, priority and tracking, and which router actually forwards.
The three first-hop redundancy protocols look similar in configuration, and candidates memorize one template. Exam items exploit the differences in defaults and behaviour, and the candidate answers from the template rather than from the stated parameters.
What to do instead
Build a comparison table across HSRP, VRRP, and GLBP covering: standard versus proprietary, default priority, default preemption behaviour, virtual MAC format, load-sharing capability, and tracking options. Then work scenario items by extracting the stated priorities and tracking objects first, deciding which device is active, and only then choosing the answer.
Skipping hands-on repetition of the automation tooling and answering Ansible, Python, or JSON/YANG items from reading alone, so questions about idempotency, inventory structure, or parsing a nested JSON response become guesswork.
Automation is the domain candidates most often defer because it feels optional and unfamiliar. Reading documentation creates recognition but not the working knowledge needed to predict the output of a playbook task or a data-structure transformation.
What to do instead
Run a small lab: an Ansible inventory with two devices, a playbook that pushes a configuration idempotently (run it twice and observe no change on the second run), and a Python script that issues a RESTCONF GET and extracts one field from the JSON response. Then answer practice items only after you can predict the output before running the code.