Free Practice Questions for Cisco 300-420 Exam

The Cisco SD-Access control-plane node provides the host tracking database and map-server function. SD-Access uses LISP-based control-plane behavior to separate endpoint identity from endpoint location. Fabric edge nodes register endpoints with the control-plane node, and the control-plane node maintains the endpoint-to-location database. When a fabric node needs to forward traffic to an endpoint, it queries the control-plane node so the destination endpoint can be resolved to the correct fabric location. In LISP terminology, this maps to the map-server and map-resolver role, while the SD-Access design discussion often refers to the endpoint database or host tracking database. The control-plane node does not enforce policy mapping by itself; policy is integrated with Cisco ISE and applied through scalable group policy in the fabric. It also does not function as a proxy ETR in this option set. Endpoint registration is initiated by the edge nodes, which detect local endpoints and inform the control plane. Therefore, host tracking database and map server are the correct functions. Reference topics: SD-Access control plane, LISP map server, host tracking database, EID-to-RLOC mapping.

Multiple Spanning Tree is the correct technology for a large Layer 2 domain with hundreds of switches and VLANs when the goals are efficient link use, loop prevention, and low CPU and memory impact. MST maps multiple VLANs into a smaller number of spanning-tree instances, allowing the designer to load-balance groups of VLANs across alternate paths without running a separate STP instance for every VLAN. Cisco Rapid PVST+ improves convergence compared with classic STP, but it maintains a separate instance per VLAN, which becomes costly at scale. PVST+ has similar per-VLAN scaling concerns and slower convergence behavior than rapid variants. Plain RSTP improves convergence but does not provide the same VLAN-to-instance mapping flexibility for hundreds of VLANs. MST is standards-based and particularly useful in multivendor environments where VLAN grouping and predictable root placement are required. The design should define MST regions consistently, map VLANs deliberately to instances, place roots near the Layer 3 gateway, and keep the number of instances small enough to protect supervisor CPU and memory. Reference topics: MST, RSTP, Rapid PVST+, VLAN-to-instance mapping, Layer 2 scalability.

The strict-priority queue should be limited to approximately 33 Mbps on a 100 Mbps Internet connection. Cisco QoS design guidance warns that strict priority traffic must be bounded, because excessive priority traffic can starve other queues and cause poor application performance for non-real-time traffic. For voice and interactive video, priority queuing is appropriate, but the priority class should normally be constrained to about one-third of the link capacity in a converged enterprise design. That makes 33 Mbps the best choice for a 100 Mbps link. A 75 Mbps strict-priority allocation is far too high and would leave inadequate bandwidth for routing, signaling, business data, and default traffic. A 50 Mbps allocation still gives real-time media excessive control of the interface. A 25 Mbps allocation may work in some environments but is not the standard upper-limit design answer for strict priority in this Cisco context. The architect should also classify TelePresence accurately, mark traffic consistently, and police the priority queue to protect the WAN. Reference topics: LLQ, CBWFQ, strict priority limits, TelePresence QoS, WAN congestion management.

The VPN drag-and-drop answer distinguishes Layer 2 VPN, Layer 3 VPN, and encrypted overlay VPN behavior. VPWS provides a point-to-point Layer 2 service, while VPLS provides multipoint Layer 2 Ethernet service across a provider core. MPLS Layer 3 VPN provides routed private WAN connectivity with provider-managed VPN routing and forwarding separation. GRE and DMVPN are overlay technologies that can carry multicast and dynamic routing protocols; DMVPN adds NHRP and multipoint GRE to scale hub-and-spoke and spoke-to-spoke designs. IPsec provides encryption and integrity for traffic over untrusted transport, but native policy-based IPsec does not carry multicast without an additional overlay such as GRE. GET VPN encrypts traffic across a private routed WAN without building permanent point-to-point tunnels and is often used where multicast and dynamic routing should remain visible to the transport. The selected mapping aligns each VPN type with its forwarding model, scale characteristics, and encryption behavior. In design, the correct VPN choice depends on whether the requirement is Layer 2 extension, routed private connectivity, dynamic spoke-to-spoke tunnels, or private WAN encryption. Reference topics: VPN design, VPLS, VPWS, DMVPN, IPsec, GET VPN.

In multicast routing, a source tree is also called a shortest-path tree because it is rooted at the multicast source and follows the best unicast path from receivers back toward that source. Cisco PIM documentation describes source trees as shortest-path trees and contrasts them with shared trees, which are rooted at a rendezvous point. Because the tree is built directly toward the source, it provides an optimal forwarding path between source and receivers and generally gives the lowest latency path for multicast delivery. This is why statements A and B are correct. A shared tree, not a source tree, uses a single common root at a selected point in the network, normally the RP in PIM sparse mode. Shared trees can create suboptimal forwarding because traffic may travel through the RP before switching to the shortest-path tree. Source trees require per-source multicast state, so they may consume more control-plane resources, but they are the correct choice when optimal forwarding and minimum latency are the design priorities.

Route summarization and EIGRP stub routing are the two correct design techniques for a stable and scalable EIGRP deployment. Summarization reduces the number of prefixes advertised upstream, conserves bandwidth and memory, hides route flaps behind the summary boundary, and reduces the size of the EIGRP topology table. Stub routing prevents branch or access devices from being used as transit routers and limits the scope of EIGRP queries. This is critical because uncontrolled EIGRP query propagation can increase convergence time and processing load, especially in larger hierarchical networks. Prefix lists and distribute lists can filter routes, but filtering alone does not provide the same query-boundary and topology-hiding benefits as summarization and stubs. Static redistribution increases complexity and can create loop or policy risks if not controlled with tags and metrics. The question specifically asks to conserve bandwidth, memory, and CPU, prevent suboptimal routing, and avoid unnecessary queries; summarization and stub routing are the direct Cisco design answers. The architect should summarize at hierarchy boundaries and configure access or branch routers as EIGRP stubs where they should not provide transit. Reference topics: EIGRP summarization, EIGRP stub routing, query scope, hierarchical routing.

A full-mesh topology best satisfies the requirement that devices make informed forwarding decisions, backup paths always exist, and suboptimal paths are used only after a failure. In a full mesh, each site or WAN node has direct connectivity to every other relevant node. This gives the routing protocol complete path visibility and allows traffic to use direct optimal paths under normal conditions. If a direct link fails, alternate paths remain available through other nodes, so the network can reroute without depending on a single hub. A hub-and-spoke design is simpler and less expensive, but spoke-to-spoke traffic must traverse the hub, which is suboptimal even during normal operation. A partial mesh can reduce cost but may still force some traffic over indirect paths when no direct connection exists. Clos is a data center fabric topology concept and is not the typical WAN topology answer here. The full mesh is the most resource-intensive design, but it best matches the stated forwarding and backup requirements. Reference topics: WAN topology, full mesh, path optimality, backup paths, routing convergence.

A totally stubby OSPF area blocks Type 3, Type 4, and Type 5 LSAs while allowing a default summary route into the area. In OSPF, Type 3 LSAs are interarea summary LSAs, Type 4 LSAs describe reachability to ASBRs, and Type 5 LSAs carry external routes. A normal area accepts all of these LSA types. A standard stub area blocks Type 5 external LSAs and normally Type 4 ASBR summaries, but it still allows Type 3 interarea summaries. An NSSA blocks normal Type 5 external LSAs but allows Type 7 LSAs for locally redistributed external routes. A totally stubby area is more restrictive: the ABR suppresses interarea summaries and external routing detail, then injects a default route so routers inside the area still have reachability outside the area. This design reduces LSDB size, memory consumption, and SPF processing on low-end routers in remote areas. Therefore, the OSPF area type that blocks Type 3, 4, and 5 LSAs but allows a default summary route is a totally stubby area.

gRPC provides efficient integration by using protocol buffers to serialize and deserialize structured data over the network. In network programmability and telemetry designs, gRPC is commonly used as the transport framework for streaming model-driven telemetry or for remote procedure calls between collectors, controllers, and network devices. Protocol buffers define compact structured messages that are faster and less ambiguous than parsing text output. This makes gRPC suitable for high-volume telemetry and programmatic device interaction. LDAP is a directory and authentication-related protocol, not the integration mechanism provided by gRPC. XMPP is associated with messaging and presence systems, not gRPC data serialization. Graph API is not a gRPC feature. The operational value of gRPC is that it provides a modern RPC framework with efficient message encoding, service definitions, and support for secure transport through TLS when implemented by the platform. Reference topics: gRPC, protocol buffers, model-driven telemetry, network programmability, structured data serialization. It improves controller interoperability.

VRRPv3 improves protocol applicability by supporting both IPv4 and IPv6 address families. VRRPv2 is associated with IPv4 virtual router redundancy, while VRRPv3 extends the protocol so the same first-hop redundancy concept can be used for IPv6 default gateways as well. In campus and branch designs, this matters because IPv6 deployments should not require a separate redundancy design from IPv4 when a standards-based FHRP is preferred. Preemption is not a unique VRRPv3 advantage because VRRP has long supported priority-based master election and preemption behavior. Authentication is also not the correct differentiator in this comparison; VRRPv3 removed the simple protocol authentication field from the base protocol and expects security to be provided by the underlying network or IPsec where required. Stateful switchover is a platform high-availability capability, not a VRRPv3 protocol feature. Therefore, the key benefit of VRRPv3 over VRRPv2 for enterprise design is IPv4 and IPv6 support under the same redundancy protocol model.