Free Practice Questions for Cisco 300-420 Exam

The scalable EIGRP hub-and-spoke design should make each spoke a stub router and summarize routes from the spokes toward the hubs. Cisco EIGRP documentation states that stub routing improves network stability, reduces resource utilization, and simplifies branch or edge router configuration. Stub spokes limit the routes they advertise and prevent the hub routers from sending unnecessary queries through remote sites. Summarizing spoke routes toward the hubs further reduces routing-table size and contains convergence events when a subnet fails behind a spoke. Exchanging all routes between every location would increase memory, CPU, and query scope, which is the opposite of good EIGRP scale design. Summarizing only between the hubs may be useful in a dual-data-center design, but it does not solve the spoke scaling requirement. Splitting the network into two autonomous systems is unnecessary when the requirement states that all locations belong to a single AS. Reference topics: EIGRP hub-and-spoke design, stub routing, route summarization, query scope reduction, branch scale.

Route summarization should be planned from the aggregation layer toward both the core and the access layer. In hierarchical campus routing, aggregation or distribution devices are natural summarization boundaries because they sit between more specific access-layer networks and the core. Summarizing from aggregation toward the core prevents access-layer subnet churn from forcing unnecessary recomputation and route table growth in the core. Summarizing from aggregation toward access can also provide a concise upstream route, often a default or summary route, so access devices do not need the entire network routing table. The goal is to contain failures, reduce routing state, and preserve fast convergence at hierarchy boundaries. Summarizing from the core toward aggregation may hide useful topology details in the wrong direction, while summarizing directly from access toward aggregation is not always possible or efficient when access devices are numerous and have limited resources. The answer that places summarization at aggregation in both directions best matches Cisco hierarchical design principles. Reference topics: hierarchical campus design, route summarization, aggregation layer, core route scale, convergence containment.

The correct IS-IS hierarchy places area 49.000 as Level 2 and areas 49.001, 49.002, and 49.003 as Level 1. In IS-IS, Level 2 forms the interarea backbone, while Level 1 areas contain local topology details. This design supports growth in the backbone because Level 2 routers exchange interarea reachability without carrying every local topology change from every access area. Areas 49.002 and 49.003 can perform summarization and route leaking at their Level 1/Level 2 boundaries, allowing routers such as A1 and A2 to avoid suboptimal routing by learning selected more-specific routes from the backbone when necessary. If the nonbackbone areas were made Level 2, the design would flatten the hierarchy and expose more of the network to topology changes. If the backbone were Level 1, interarea routing would be broken or badly constrained. The selected hierarchy preserves scaling, allows route control, and avoids unnecessary propagation of local link flaps. Reference topics: IS-IS hierarchy, Level 1 areas, Level 2 backbone, route leaking, summarization, scaling.

The YANG module mapping follows the distinction between standards-based, vendor-neutral, and vendor-native data models. IETF YANG models are standards-driven and are appropriate when the design goal is protocol-level interoperability across vendors for common network functions. OpenConfig models are also vendor-neutral, but they are developed by the OpenConfig community and commonly use a structured separation between intended configuration and operational state. Cisco native models expose platform-specific Cisco IOS XE, IOS XR, or NX-OS capabilities and are often the most complete option when a feature is unique to a Cisco operating system. The selected drag-and-drop answer aligns each characteristic with the model family that owns that behavior. In a professional automation design, the engineer should not choose a model only because it is familiar. The correct choice depends on feature coverage, device support, platform release, schema stability, and whether the workflow must operate consistently across vendors. For multivendor intent, choose IETF or OpenConfig first; for Cisco-specific feature depth, use Cisco native models. Reference topics: YANG, IETF models, OpenConfig, Cisco native models, NETCONF and RESTCONF automation.

The border node is part of the Cisco SD-Access overlay architecture. In the SD-Access fabric, the overlay consists of fabric roles and services that provide endpoint connectivity, segmentation, policy, and external reachability over the routed underlay. Border nodes connect the fabric overlay to external Layer 3 networks, shared services, WAN, Internet, or other fabric/transit domains. They perform the fabric boundary function, including routing between virtual networks and external routing domains as designed. Spine and leaf are generic data center or fabric topology terms and are not the named SD-Access fabric overlay roles in this question. Cisco DNA Center, now Cisco Catalyst Center, is central to management, automation, assurance, and policy deployment, but it is not itself an overlay forwarding component. The forwarding overlay is built from roles such as edge, border, control-plane, and intermediate nodes. Therefore, the correct component from the options is the border node. The design should select border placement based on external connectivity, scale, route control, redundancy, and whether the border is internal, external, or anywhere border. Reference topics: SD-Access overlay, border node, fabric roles, external connectivity, virtual networks.

The selected design is correct because the requirement describes a resilient campus architecture that must support the same VXLAN at any access-layer switch while maintaining fast convergence and high availability. In Cisco campus and data-center-style fabric designs, VXLAN provides network virtualization by carrying Layer 2 adjacency over a routed or resilient transport. The correct design must avoid a fragile single spanning-tree domain and must provide redundant forwarding paths so that an access switch or uplink failure does not isolate the VLAN or VXLAN segment. The selected option represents the design that meets those conditions by allowing the overlay segment to be extended consistently across access switches while keeping the underlay resilient. Designs that rely on a traditional Layer 2 tree, a single aggregation point, or blocked redundant links would not meet the high availability and fast convergence objectives. The important design principle is that VXLAN should ride on a stable, redundant transport and should not depend on large Layer 2 failure domains. Reference topics: VXLAN campus design, overlay networking, fast convergence, access-layer resiliency, high availability.

An SD-Access intermediate node routes and transports IP traffic between fabric nodes. It is part of the underlay transport path, comparable to a routed distribution or core device that provides IP reachability between edge, border, and control-plane nodes. Intermediate nodes do not perform endpoint registration, VXLAN encapsulation for attached users, virtual-network mapping, or anycast gateway services. Those functions belong primarily to fabric edge nodes. They also do not act as LISP proxy tunnel routers, which is a border-node function used for communication between the fabric and external networks. The intermediate node’s role is deliberately simple: maintain underlay routing, provide resilient transport, and forward encapsulated traffic across the fabric infrastructure. This separation of roles is what lets Cisco SD-Access scale by keeping endpoint intelligence at the edge and mapping intelligence in the control plane while the intermediate layer remains a stable IP transport network. Reference topics: SD-Access intermediate node, routed underlay, IP transport, fabric roles, edge and border node separation.

For in-band management over the production WAN, the proper marking is DSCP CS2 mapped into the management or operations class with a minimum bandwidth guarantee. Cisco enterprise QoS guidance separates network control traffic from network management traffic. Routing protocol and control-plane traffic should not be diluted by ordinary management flows. CS6 is typically reserved for routing and network-control traffic; EF is reserved for low-latency voice bearer traffic; CS1 is commonly used for scavenger or low-priority traffic. Network management flows such as SSH, SNMP, NTP, FTP-based maintenance, and syslog require reliable delivery, but they should not starve business traffic or real-time services. Therefore, marking with CS2 and mapping the traffic into Class2 is the correct design choice. The bandwidth adjustment should come from a lower-priority class, not from the routing/control or real-time class. Because this is in-band management, the architect must also ensure access control, source restrictions, AAA, logging, and management-plane protection. QoS classification alone does not secure management access; it only gives the traffic an appropriate forwarding treatment over the MPLS WAN. Reference topics: in-band management, DSCP CS2, enterprise QoS classes, management-plane traffic.

A distribute list is the correct method to filter routes exchanged between EIGRP neighbors within the same autonomous system. In Cisco EIGRP designs, distribute lists can be applied inbound or outbound under the EIGRP process to control which routes are accepted from or advertised to neighbors. The filter can reference an access list, prefix list, or route map depending on platform and configuration style. This allows the designer to limit route visibility without changing the forwarding behavior of packets that are already routed. Policy-based routing is a data-plane forwarding feature that changes next-hop selection for matching traffic; it does not filter EIGRP route advertisements between neighbors. Leak maps are used with route summarization to selectively advertise more specific routes through a summary, not as the general route-filtering method between EIGRP neighbors. Route tagging is valuable in redistribution designs to identify route origin and prevent feedback loops, but the tag alone does not filter routes unless a route map or distribute list uses it. Therefore, the correct route-filtering mechanism between EIGRP neighbors is a distribute list.

This YANG mapping is based on how IETF, OpenConfig, and Cisco native models differ in portability and schema organization. IETF models are produced through the standards process and are appropriate when the same management structure is expected across vendors for common protocols. OpenConfig models are also vendor-neutral, but they are built around a consistent operational model used heavily for streaming telemetry and multivendor automation. Cisco native models mirror Cisco platform configuration more closely and expose device-specific capabilities that may not exist in common models. The selected answers keep those boundaries clear. This matters because a NETCONF or RESTCONF payload is validated against the YANG schema; a payload written for one model family cannot be assumed to work against another. In design terms, the model family should be selected after confirming device software release support, feature coverage, operational-state requirements, and vendor diversity. Open models give portability; native models give feature completeness. Reference topics: IETF YANG, OpenConfig YANG, Cisco native YANG, schema validation, automation model selection.