Free Practice Questions for Cisco 300-420 Exam

Cisco SD-WAN is the correct solution when the design must use internet circuits at each site while providing failover, load sharing, and QoS. Basic IPsec tunnels can encrypt traffic, but they do not by themselves provide a complete WAN architecture for path measurement, dynamic traffic steering, centralized policy, application-aware routing, or scalable operational control. Cisco SD-WAN builds secure overlay tunnels across available transports and continuously measures path characteristics such as loss, latency, and jitter. It can then steer applications according to SLA policy, use multiple circuits for active/active forwarding, and fail traffic over when a path degrades or fails. QoS can be applied consistently through templates and policy across the WAN Edge routers. GET VPN is best suited to private MPLS-style networks and does not address internet-circuit overlay orchestration in the same way. Traditional DMVPN is a valid dynamic VPN technology, but SD-WAN is the more complete resilient internet-WAN design for these requirements. Reference topics: Cisco SD-WAN, internet transport, application-aware routing, failover, load sharing, QoS.

The control-plane node in Cisco SD-Access acts as the map system that manages endpoint-to-device relationships. Cisco SD-Access documentation describes control-plane nodes as maintaining the host database that maps endpoint identifiers to the fabric edge devices where those endpoints are attached. This mapping function is based on LISP control-plane behavior. When an endpoint appears on an edge node, the edge registers the endpoint information with the control plane. When another fabric device needs to send traffic to that endpoint, it queries the control-plane node to resolve the endpoint location. A fabric edge node is the device that connects wired endpoints to the fabric, so option A describes an edge role. Wireless endpoints may attach through fabric AP and fabric WLC integration, but that is not the control-plane node’s role. External Layer 3 networks are connected through border nodes, not through the control-plane node. Therefore, the correct role is endpoint-to-device mapping. Accurate control-plane design is essential for fabric scale, endpoint mobility, and fast location resolution.

In Cisco SD-Access, endpoints inside the fabric reach external resources through fabric border nodes. The fabric overlay uses virtual networks that map to VRFs, and the border node provides the boundary between the SD-Access fabric and external Layer 3 networks, shared services, WAN, data center, or Internet connectivity. When traffic sourced inside the fabric is destined outside the fabric, the border node de-encapsulates VXLAN traffic and forwards it into the appropriate external routing domain. The answer choice stating that fabric borders use VRFs to map VNs to VRFs best captures that design function. A fusion router can be used for inter-VN communication or shared services, but it is not how every endpoint exits the fabric. SD-Access transit links are used to connect fabric sites or carry encapsulated traffic between fabrics, not simply to reach ordinary external resources. A fabric edge encapsulates and de-encapsulates traffic for locally attached endpoints, but the fabric border is the role that connects the fabric to outside networks. Therefore, fabric border nodes are the correct design component for external resource access.

Dual-stack is the correct IPv6 migration strategy for this corporation. The requirements state that users need access to both IPv4 and IPv6 resources, content providers will migrate over the next two years, and users will move in phases. Dual-stack supports exactly that model because hosts, routers, and services can run IPv4 and IPv6 simultaneously. Applications can select IPv6 or IPv4 based on DNS responses and protocol availability, while the organization gradually enables IPv6 without breaking existing IPv4 connectivity. NAT64 is useful for IPv6-only clients reaching IPv4-only services, but it introduces translation state and does not provide native dual protocol operation. NAT46 is a specialized translation direction and not the broad migration strategy here. Tunneling can connect IPv6 islands across IPv4 infrastructure, but the customer already has IPv4 peering and needs a phased endpoint and application migration, not only island interconnection. Dual-stack is straightforward operationally and gives the longest coexistence window while providers and applications transition. Reference topics: IPv6 migration, dual-stack deployment, DNS-based protocol selection, IPv4 and IPv6 coexistence, phased migration.

The SD-Access underlay must run a routing protocol to establish IP connectivity between infrastructure devices. Cisco SD-Access uses a routed underlay to provide basic reachability among fabric edge nodes, border nodes, control-plane nodes, and intermediate nodes. Cisco design documentation states that all network elements in the fabric underlay must have IP connectivity through routing. Catalyst Center LAN Automation commonly deploys IS-IS for this purpose, although the underlay can be built manually with another supported routing design. The user endpoints and client subnets are not part of the underlay; they belong to the overlay, where fabric services, segmentation, and policy are applied. CEF should not be disabled, because efficient IP forwarding is necessary for the routed underlay. Two or more switches are not required merely to avoid spanning-tree loops; the SD-Access underlay is normally Layer 3 routed and avoids large Layer 2 loop domains. Reference topics: Cisco SD-Access underlay, routed access, LAN Automation, IS-IS, fabric node reachability.

A totally stubby OSPF area is the best choice for a small remote site with low-end routers and no requirement to carry transit traffic. A standard stub area blocks Type 5 external LSAs, but it still receives interarea Type 3 summary LSAs. A totally stubby area goes further by blocking external routes and most interarea summary routes, while allowing a default route to be injected by the ABR. That greatly reduces LSDB size, SPF processing, memory use, and routing-table entries on the low-end routers. The remote site still has full connectivity to the rest of the OSPF domain through the default route. NSSA and totally NSSA designs are useful when the area must inject external routes from an ASBR inside the area, but the question does not state that the remote site needs redistribution. A regular stub area is acceptable but does not minimize resources as much as a totally stubby area. Because there is no demand for traffic to pass through this area, the most efficient Cisco design is totally stubby. Reference topics: OSPF stub areas, totally stubby area, default routing, LSDB reduction, branch OSPF design.

The most efficient campus design aligns the active first-hop gateway with the Layer 2 forwarding path. In a traditional access-distribution topology using STP and HSRP, traffic should not cross the distribution-to-distribution link simply because the HSRP active gateway is on the opposite distribution switch from the STP forwarding path. Cisco campus design guidance stresses aligning the STP root bridge with the active FHRP gateway so hosts forward northbound traffic directly to the distribution switch that owns the optimal Layer 2 path. Reconfiguring distribution switch A to become the HSRP active device fixes the asymmetric and inefficient traffic flow in the exhibit. Adding a link between access switches would extend the Layer 2 domain and increase loop-prevention complexity, not improve the northbound default-gateway path. Changing the distribution interconnect to a routed link may be valid in a routed-access redesign, but it is not the targeted correction for this Layer 2/FHRP misalignment. An EtherChannel between distribution switches only increases interswitch capacity; it does not remove the unnecessary hairpin path caused by the wrong active gateway.

Explicit QoS trust should be configured at the network boundary points where markings first enter the managed DiffServ domain and are known to be reliable. In a DiffServ design, traffic classification and marking are typically performed at the access edge or at a controlled ingress boundary, and downstream devices then honor DSCP or CoS markings based on the trust boundary. Cisco QoS design stresses that the trust boundary must be intentionally placed; endpoints or unmanaged devices should not be trusted by default because they can mark traffic incorrectly and steal priority treatment. The exhibit answer identifies B and E as the correct trust points, meaning those are the controlled ingress locations where markings should be accepted. Options that trust uncontrolled endpoint-facing points or internal transit locations would either create a security problem or add no practical value. Once traffic is trusted and marked at the correct boundary, queuing, policing, and shaping policies can use the DSCP values consistently across the campus or WAN. Reference topics: DiffServ, QoS trust boundary, DSCP marking, classification, enterprise QoS design.

Dual stack is the correct IPv6 migration strategy because the existing infrastructure already supports IPv6, the company wants low operational overhead, and applications should migrate naturally using DNS. Cisco describes dual stack as running IPv4 and IPv6 simultaneously on the same infrastructure, allowing hosts and applications to use either protocol during the migration period. It does not require additional tunneling equipment, avoids encapsulation overhead, supports native IPv6 multicast, and allows application preference to follow DNS responses. ISATAP and manual tunnels introduce overlay complexity and are primarily transition mechanisms for connecting IPv6 islands over IPv4 infrastructure. A service block model may be useful for specific service insertion, but it does not provide a whole-network migration strategy. Since every current infrastructure device supports IPv6, the cleanest and most operationally straightforward model is to enable IPv6 alongside IPv4 and migrate services gradually. Reference topics: IPv6 migration, dual-stack deployment, DNS-based protocol selection, native IPv6 multicast, transition strategy design.

The verifying get-config reply must reflect the same YANG model hierarchy and configured values that were pushed by the Postman request. In model-driven automation, a successful transport response is not enough; the engineer must confirm that the intended datastore contains the exact interface, routing, or protocol objects described by the model. Option D is the selected reply because it matches the expected YANG structure for the configuration operation shown in the exhibit. The key principle is that get-config returns configuration data from a specified datastore, such as running or candidate, using the schema-defined XML hierarchy. If the returned XML uses the wrong container, wrong namespace, incorrect key value, or an unexpected leaf, the model set was not designed or addressed correctly. Cisco NETCONF/YANG workflows rely on strict namespace and path accuracy, so even a small mismatch can result in configuration being placed in the wrong subtree or not applied. A clean validation checks the model namespace, parent containers, list keys, leaf names, and actual configured value. Reference topics: NETCONF get-config, YANG XML encoding, datastore validation, Postman automation workflow.