ENSLD 300-420 common mistakes
ENSLD 300-420 · Understand the traps and how to avoid them.
Treating the exam as a configuration-recall test and memorizing CLI syntax, port numbers, and feature commands instead of design trade-offs, so scenario questions about which architecture to choose are answered by pattern-matching a command rather than reasoning about requirements.
Most candidates arrive from CCNA/CCNP ENCOR study habits where the questions reward command knowledge; ENSLD is a design exam where the answer is usually a justification-driven choice between valid options, and command recall is not what is being tested.
What to do instead
Re-anchor study on design decisions: for each technology (VSS versus StackWise versus vPC, OSPF area design versus EIGRP stub, MPLS L3VPN versus DMVPN versus SD-WAN), write a one-page comparison of when each is chosen, what constraints drive it, and what it costs in complexity and convergence. Practice explaining the choice aloud before looking at options.
Choosing the most feature-rich or most modern option in every scenario, for example recommending SD-WAN or a full fabric everywhere, without first extracting the stated constraints such as budget, existing skill set, legacy application requirements, or a small single-site deployment.
Candidates equate 'best practice' with 'newest technology' and skip the requirement-gathering step that the question stem deliberately encodes; exam scenarios frequently reward the simpler, sufficient design.
What to do instead
Before evaluating answers, list the stated constraints from the stem (scale, budget, existing investment, regulatory, operational maturity, traffic patterns) and eliminate any option that violates one. If two options are both technically valid, prefer the one that meets the stated requirement with the least added complexity.
Designing a campus hierarchy by drawing three tidy layers and assigning devices to core, distribution, and access without checking the actual requirements for spanning-tree domain size, gateway redundancy, Layer 2 versus Layer 3 boundary placement, and PoE or port-density needs at the access layer.
The textbook three-tier diagram is easy to reproduce, so candidates stop there and never decide where routing begins, how many users share a failure domain, or whether a collapsed-core or routed-access design fits the site size.
What to do instead
For every campus scenario, explicitly state the Layer 2/Layer 3 boundary, the size of each spanning-tree domain, the first-hop redundancy mechanism and its failure behaviour, and the uplink bandwidth and oversubscription ratio. Practice sizing a distribution block from a given user count and port profile, and justify routed access versus traditional access with a concrete reason.
Ignoring high-availability and convergence detail in campus designs, answering 'use HSRP' or 'use redundant links' without specifying preemption, tracking, timer tuning, or what happens to traffic during a distribution switch failure, and without distinguishing SSO from non-SSO failover behaviour.
Redundancy questions feel satisfied by naming a protocol, and the subtle behaviour (sub-second versus multi-second convergence, active/active versus active/standby forwarding, traffic blackholing during failover) is exactly what separates a working design from a resilient one.
What to do instead
For each redundancy mechanism you plan to use, write the failure timeline: what detects the failure, what reconverges, how long user traffic is impacted, and whether state is preserved. Compare HSRP, VRRP, and GLBP plus stack or VSS-based multichassis etherchannel on convergence and forwarding behaviour, and be able to state where a routing protocol converges faster than first-hop redundancy.
Mixing Layer 2 and Layer 3 segmentation concepts loosely, proposing VLANs for segmentation without addressing inter-VLAN routing policy, or proposing VRFs and firewalls without explaining where policy is enforced and how traffic between segments is inspected.
Segmentation questions invite a buzzword answer ('use VLANs', 'use VRFs'), but the design question is about the enforcement point, the path traffic takes between segments, and whether the segmentation survives a link failure.
What to do instead
For any segmentation scenario, draw the traffic path from source segment to destination segment and mark where policy is applied (SVI ACL, firewall, VRF leaking, service insertion). State whether segmentation is for broadcast containment, security policy, or overlapping addressing, since each drives a different design.
Treating WAN design as a single-technology choice and failing to design the underlay and overlay separately, for example recommending SD-WAN without describing how the transport underlay (MPLS, internet, LTE/5G) is provisioned, how paths are measured, and how application-aware routing policies are expressed.
SD-WAN marketing language encourages a box-level answer; the exam tests whether the candidate understands that the overlay's behaviour depends entirely on the underlay's characteristics and on correctly defined SLA and policy.
What to do instead
For each WAN scenario, produce two layers: the transport mix and its characteristics (latency, jitter, loss, bandwidth guarantees, cost), and the overlay policy (topology, path selection criteria, thresholds, fallback). Be able to explain how the design behaves when the preferred path degrades rather than fails outright.
Skipping route summarization and scalability arithmetic in WAN and branch designs, proposing a routing protocol without stating area or domain boundaries, summarization points, or the resulting table size and convergence behaviour at the hub.
Candidates focus on which protocol to run rather than how it scales; hub-and-spoke designs fail in practice because the hub carries full detail and reconverges on every spoke flap, and exam scenarios test exactly this.
What to do instead
For every multi-site routing design, state the summarization boundary, the number of routes the hub will hold, and the mechanism that limits spoke failure propagation (stub areas, EIGRP stub, route filtering, prefix limits). Work through a numeric example with a given number of sites and prefixes and show the table size at each tier.
Designing branch connectivity without a documented failure and fallback model, so the answer covers the primary path but never states what happens when it fails, how the secondary path is selected, how voice or business-critical traffic is prioritized, or how NAT and addressing behave across the switchover.
Primary-path design is the visible part of the problem; fallback behaviour requires holding the whole topology in mind, and candidates run out of time or confidence before writing it down.
What to do instead
Make a failure matrix part of every branch answer: for each link and each device, state the detection mechanism, the alternate path, the expected interruption, and any stateful requirement (session continuity, IP preservation, NAT translation). Include at least one scenario where the primary path degrades rather than fails.
Treating automation as a product selection question, naming a controller or orchestration platform without describing the data model, the source of truth, the change workflow, or how the design handles drift and rollback.
Automation questions look like tooling questions, but the design content is about intent, idempotency, validation, and the boundary between automated and manual change; candidates who answer with product names miss the design reasoning being tested.
What to do instead
For each automation scenario, describe the source of truth, the rendered configuration model, the validation and test step, the deployment mechanism, and the rollback path. Be able to explain how the design detects and corrects configuration drift and how it prevents an automated change from exceeding a defined blast radius.
Confusing assurance with monitoring and answering with a list of telemetry sources (SNMP, syslog, NetFlow, streaming telemetry) without stating what is measured, what the baseline or threshold is, how anomalies are detected, and what action the design takes in response.
The vocabulary of assurance overlaps with monitoring, so candidates list collection methods and consider the question answered, while the design question is about closed-loop behaviour and measurable service objectives.
What to do instead
For each assurance scenario, define the service-level objective, the measurement point, the collection method and cadence, the detection logic, and the response (alert, reroute, ticket, automated remediation). Distinguish clearly between data collection, analytics, and the action taken, and be able to say which layer of the design owns each.