Free Practice Questions for Cisco 300-420 Exam

Stateful NAT64 is the correct translation solution when IPv6-only corporate hosts need Internet connectivity to IPv4 resources using a limited IPv4 address pool. NAT64 translates IPv6 client addresses to IPv4 addresses and maintains state for each session, allowing many IPv6 hosts to share a smaller set of IPv4 addresses through port multiplexing. The design is restricted to the 172.16.168.0/22 subnet, which provides an IPv4 pool that can be used for stateful translation. Stateless NAT64 requires algorithmic one-to-one address mapping and normally needs enough IPv4 address space to represent IPv6 hosts deterministically; it is not suitable when many clients must share a restricted IPv4 block. NAT66 translates IPv6 to IPv6 and does not provide access to IPv4 Internet resources. In a production design, stateful NAT64 is often paired with DNS64 so IPv6-only clients can resolve IPv4-only destinations through synthesized AAAA records. Reference topics: stateful NAT64, DNS64, IPv6-to-IPv4 translation, address conservation, Internet access migration.

Interdomain multicast designs commonly use MP-BGP and MSDP together. MP-BGP carries multicast routing information between domains so routers can perform RPF checks based on the correct multicast topology rather than relying only on unicast routing. MSDP is used between rendezvous points in different PIM sparse-mode domains to exchange information about active sources. Cisco multicast documentation describes MSDP as a mechanism that connects multiple PIM-SM domains and allows RPs to discover multicast sources in other domains. Together, MP-BGP provides the reachability information and MSDP provides source discovery between RPs. IGMPv2 is a host-to-router group membership protocol inside a local subnet, not an interdomain multicast routing protocol. MLD provides the IPv6 equivalent of host group membership signaling. BIDIR-PIM is a multicast forwarding mode optimized for many-to-many traffic inside a domain, but it is not the pair of protocols used for interdomain source and receiver communication in this question. Therefore, the correct protocols are MP-BGP and MSDP.

Secure segmentation is the Cisco SD-WAN Secure Direct Cloud Access function that separates user traffic into different zones and VPNs or VRFs. In Cisco SD-WAN, VPNs provide logical segmentation that is comparable to VRF separation in traditional routing. Secure Direct Cloud Access extends this segmentation model when users access internet and cloud applications directly from the branch. The design can keep corporate, guest, payment, voice, IoT, and other traffic classes isolated, with policy and security controls applied per segment or zone. Centralized data policy controls forwarding behavior, but the feature that divides traffic into separate zones and VPN or VRF contexts is secure segmentation. Perimeter control and application-aware routing are useful security and performance functions, but they do not describe the core segmentation mechanism. Segmentation is a fundamental SD-WAN design requirement because direct cloud access must not collapse trust boundaries simply because traffic no longer hairpins through a central data center. Reference topics: Cisco SD-WAN secure segmentation, VPNs, VRFs, direct cloud access, zone-based policy.

The branch router should advertise the local LAN with the EIGRP network command and make the LAN-facing interface passive. A passive interface allows the connected network to be included in EIGRP advertisements while suppressing EIGRP hello packets and neighbor formation on that interface. This is exactly what the engineer needs: remote EIGRP neighbors learn the LAN subnet, but unnecessary multicast EIGRP messages are not sent onto the user LAN where no EIGRP neighbors should exist. Replacing EIGRP with a static default route would not meet the requirement to advertise the local LAN through EIGRP. Redistributing connected routes can work, but it is less clean for a simple LAN interface and can introduce external-route behavior or policy complexity. Advertising the subnet as a stub network does not suppress multicast hellos on the LAN interface by itself. Cisco design best practice is to use passive interfaces on LAN-facing interfaces that should be advertised but should not form routing adjacencies. Reference topics: EIGRP passive interface, network statements, branch routing, unnecessary neighbor prevention, multicast control traffic.

Enabling EIGRP stub routing on the spokes decreases convergence time in a hub-and-spoke design by reducing unnecessary queries and preventing spokes from being treated as transit routers. EIGRP convergence can be delayed when a router loses a route and must query many neighbors to determine whether an alternate path exists. In remote-site or spoke designs, a spoke normally has no useful alternate path for networks beyond itself, so querying it wastes time and can contribute to stuck-in-active conditions. Cisco EIGRP stub routing allows the spoke to advertise only permitted route types and informs upstream routers not to query the spoke for routes outside its scope. This creates a cleaner query boundary and accelerates convergence after link or route failures. Subsecond timers can detect neighbor loss more quickly, but they do not address the broader EIGRP query behavior shown in the design. Increasing hold or dead timers would slow detection, not improve convergence. Therefore, in the displayed hub-and-spoke EIGRP design, enabling stub routing on the spokes is the correct solution to decrease convergence time.

Cisco weight is the Cisco-proprietary BGP path attribute used to influence outbound traffic selection on a local router. Weight is locally significant and is not advertised to BGP neighbors. A higher weight is preferred, and because weight is evaluated early in the Cisco BGP best-path algorithm, it is a direct way to make one exit path preferred over another on the router where the attribute is configured. Local preference also influences outbound traffic, but it is a well-known discretionary BGP attribute used inside an AS and is not Cisco proprietary. MED is primarily used to influence inbound path selection by suggesting to a neighboring AS which entry point should be preferred. AS-path prepending is also typically used for inbound traffic engineering by making a route appear less attractive to external peers. Communities can carry policy information, but they are not the Cisco-proprietary attribute in the list. Therefore, when the requirement specifically asks for the Cisco proprietary BGP path attribute that influences outbound traffic flow, the answer is weight.

A practical advantage of model-driven telemetry is that it sends structured data in machine-readable encodings, including JSON in supported implementations, making the data easier to consume with modern collectors and automation tools. Model-driven telemetry uses data models, commonly YANG, to define exactly which operational or configuration data is streamed. This is a major improvement over legacy monitoring approaches that repeatedly poll devices or parse human-oriented CLI output. The question option that points to structured JSON compatibility is the best available answer. Telemetry is not based on interrupt-driven polling; it is normally subscription based, either periodic or on-change. It also does not rely on MIB models as its primary structure in the way SNMP does. Parsing show command output is the older, brittle method that model-driven telemetry is intended to replace. The design benefit is cleaner, more predictable, and more programmable network state collection. Reference topics: model-driven telemetry, YANG data models, JSON encoding, subscription-based monitoring, network programmability.

VRRP object tracking allows the effective priority of a VRRP router to change when a tracked object changes state. Cisco documentation states that VRRP object tracking ensures the best VRRP router is master by altering VRRP priorities according to tracked objects such as interface or IP route states. This directly supports answer A. It also supports answer D, because VRRP can track interfaces and routes through the tracking process. The priority does not have to remain fixed; object tracking is specifically designed so a router can lower its priority when an uplink, route, or critical dependency fails. A VRRP group is not limited to one tracked object in modern Cisco implementations, so option C is too restrictive. VRRP does not support only interface tracking; route tracking is also a common use case, especially when the LAN interface is still up but upstream reachability has failed. In a resilient campus or branch gateway design, object tracking prevents a router from remaining master when it no longer has a valid upstream path, improving deterministic failover.

Incremental SPF is the correct solution because the problem specifically states that Type 1 or Type 2 LSAs force the OSPF process to recompute the entire shortest path tree. Cisco OSPF documentation states that when changes to a Type 1 or Type 2 LSA occur, the entire SPT is normally recomputed, and that incremental SPF allows the system to recompute only the affected part of the tree. This improves convergence and reduces CPU use because the router does not have to run a full Dijkstra calculation for every topology change. BFD detects failures quickly, but it does not change how OSPF recalculates the SPT after the LSA arrives. Standard SPF is the default full calculation behavior and therefore does not solve the optimization requirement. PRC is associated with partial route calculation behavior in some link-state contexts, but for this OSPF question the Cisco feature name is iSPF. Reference topics: OSPF incremental SPF, Type 1 LSA, Type 2 LSA, SPF optimization, campus OSPF scaling.