Free Cisco 300-420 Practice Exam with Questions & Answers | Set: 10

Dial-In: collector initiates a session to the device; supports gRPC only. Dial-Out: device initiates a session to the collector; supports TCP, UDP, and gRPC.

Model-driven telemetry can be deployed in dial-in or dial-out mode, and the difference is which side initiates the session and where the subscription is controlled. In dial-in mode, the collector initiates the session to the network device and requests the telemetry subscription. This makes the collector responsible for establishing the session and asking for the data stream. In the context of the provided options, dial-in is paired with support for gRPC only. In dial-out mode, the network device initiates the session toward the collector according to a configured subscription. This is useful when devices sit behind NAT or when the operational model requires devices to push telemetry to a known collector. In the provided choices, dial-out is paired with support for TCP, UDP, and gRPC. The mapping is not arbitrary; it follows Cisco telemetry terminology, where dial-in is collector-initiated and dial-out is device-initiated. This distinction is important in network automation designs because firewall policy, collector scaling, and subscription lifecycle management differ between the two modes.

The requirements point to a Layer 2 multipoint WAN service. VPLS provides an emulated Ethernet LAN across a provider network, allowing multiple sites to appear as if they are connected to the same Layer 2 domain. This supports full-mesh Layer 2 connectivity and preserves customer control over higher-layer services such as IPv6, multicast, routing protocols, and QoS markings. Because the provider delivers an Ethernet multipoint service, the enterprise can retain protocol independence rather than depending on the service provider to participate in IPv6 routing or multicast routing. CoS marking is also a Layer 2 QoS mechanism, so a Layer 2 VPN service is better aligned to the stated QoS requirement. VPWS is point-to-point rather than full-mesh multipoint, so it does not meet the topology requirement by itself. MPLS Layer 3 VPN is a provider-routed service and does not give the customer full Layer 2 mesh behavior. DMVPN is an overlay routed VPN and does not provide a native Layer 2 full-mesh service. Therefore, VPLS is the correct WAN connectivity option.

An MPLS Layer 3 VPN with separate VRFs for corporate and guest traffic is the correct WAN design. The customer has branch teams that must communicate with each other and access enterprise applications in the data center and cloud, while guest traffic must be isolated and allowed only to reach the Internet gateway in the data center. Cisco MPLS L3VPN designs use VRFs to create separate routing tables and isolate traffic over the shared provider backbone. A corporate VRF can carry interbranch and application traffic, while a guest VRF can be routed only toward the data-center Internet security stack. A separate service provider for guest users would increase cost and operational complexity without solving segmentation as cleanly. A firewall in the data center can enforce security, but it does not by itself provide routing separation across the WAN. A separate VRF for every branch would isolate branches from each other and would be unnecessary unless each branch required complete tenant separation. Reference topics: MPLS L3VPN, VRF segmentation, guest Internet access, enterprise WAN design, centralized Internet gateway.

In-band management is the correct design because the management plan must reach all IP-enabled interfaces, and not every device has a dedicated management port. In-band management uses the production IP network for administrative access, allowing management stations to reach loopbacks, SVIs, routed interfaces, or front-panel interfaces through normal routing. Cisco management guidance distinguishes in-band management from out-of-band designs that depend on a separate physical management network or console path. Because the question requires reachability to all IP-enabled interfaces, in-band is the only listed model that naturally supports that scope. Security must still be enforced with encrypted protocols where supported, such as SSH and HTTPS, plus ACLs, AAA, and management-plane protection where appropriate. A terminal server provides console access, not routed IP management to every interface. A KVM server is a server-management tool, not a network-device management architecture. Out-of-band management is preferred for isolation, but it does not fit devices without dedicated management access. Reference topics: in-band management, secure management protocols, SSH, HTTPS, network management design.

For model-driven telemetry with periodic updates, the architect must understand that each periodic update sends the subscribed data at the configured interval. Cisco telemetry guidance distinguishes periodic subscriptions from on-change subscriptions. A periodic subscription streams a full copy of the subscribed data element or table at each interval, even if the underlying state has not changed. That behavior is useful when the collector needs regular time-series samples, trending, or baseline monitoring, but it creates predictable bandwidth and collector-load requirements. On-change subscriptions are different: they publish updates when the subscribed state changes and are more efficient for state changes such as interface status, memory thresholds, or protocol adjacency m ovement. Empty subscription behavior and initial update timing may matter in specific implementations, but they are not the main design consideration in this question. Since the customer requires periodic updates, the design must size the transport, collector, retention system, and subscription intervals around repeated full data delivery. Reference topics: model-driven telemetry, periodic subscription, on-change subscription, YANG-modeled operational data, collector sizing.

Cisco IS-IS supports Level 1, Level 2, and Level 1/Level 2 operation, and the design should restrict each link to the level it actually needs. Cisco documentation for the isis circuit-type command states that it “configures the type of adjacency that is required for neighbors on the specified interface.” In this case, the router is configured as L1/L2 and has both L1 and L2 neighbors, which causes unnecessary LSP flooding, SPF processing, and database maintenance on links that may not need both levels. Making the entire router only L1 or only L2 would be too blunt, because the router may legitimately need to participate in both domains on different interfaces. Making the router a DIS also does not solve the underlying issue; it only controls designated intermediate system behavior on broadcast networks. The best optimization is to configure each interface with the correct circuit type, such as level-1 for intra-area links and level-2-only for backbone links. This reduces control-plane load while preserving the intended two-level hierarchy.

NETCONF supports event notifications through a subscription model. The operation used to establish a notification subscription is create-subscription. When a client sends this operation, it can specify the stream and optional filters that determine which notifications are delivered to that NETCONF session. This is why create-subscription is the operation associated with session-specific notification filtering. The commit operation is used with the candidate configuration datastore to apply configuration changes to the running datastore; it does not create a telemetry or event subscription. The notification element is the message sent by the server after a subscription exists, not the operation used to create one. Logging is not a NETCONF operation in the protocol operation set. In Cisco model-driven management designs, NETCONF provides structured configuration and operational access using YANG data models, while notifications allow the management station to consume specific events without relying on repeated screen scraping or broad polling. Therefore, the correct operation for creating filtering specific to session notifications is create-subscription.

Redundancy for Cisco vBond Orchestrators is normally achieved by mapping the IP addresses of multiple vBond instances to a single DNS name. WAN Edge devices use the configured organization name and vBond DNS name during onboarding to resolve and contact an available orchestrator. This design allows several vBond nodes to be deployed across different locations or availability zones while giving the edge device a consistent bootstrap target. If one vBond is unavailable, DNS resolution can return another reachable vBond address, allowing control-connection orchestration to continue. Selecting only the closest vBond is not the redundancy mechanism described here, and deploying a single vBond creates an avoidable single point of failure. The answer that says WAN Edge routers are configured with all orchestrators by IP address and priority does not represent the common DNS-based design model. In production, the DNS record, certificates, firewall policy, NAT behavior, and controller reachability should all be validated so that WAN Edge devices can reach multiple vBond instances during onboarding and after failures. Reference topics: Cisco SD-WAN controller redundancy, vBond DNS, device onboarding, orchestration availability.

A single-homed WAN design is appropriate for two small branch offices when cost is the main concern, routing overload must be avoided, and occasional downtime is acceptable. Single-homed connectivity uses one WAN connection from the branch to the provider or headquarters. It is the simplest and least expensive model because it minimizes circuits, routers, routing adjacencies, and failover complexity. Dual-homed or multihomed designs improve availability, but they add cost and operational overhead through additional links, devices, routing policy, and monitoring. Dual multihomed designs are the most resilient but clearly exceed the requirement for a small cost-sensitive branch. A single multihomed design provides some provider or link diversity, but it is still more complex than necessary if the customer accepts some downtime. In Cisco WAN design, the correct topology must match the business availability requirement; not every site justifies redundant circuits. Reference topics: WAN topology selection, single-homed branch design, cost versus availability, routing simplicity, branch connectivity.

LFA FRR is the correct improvement because it gives OSPF a precomputed repair path instead of waiting for normal SPF reconvergence after a component failure. Cisco describes OSPF LFA Fast Reroute as using a precomputed alternate next hop to reduce failure reaction time when the primary next hop fails. The forwarding plane can move traffic to the alternate path while the control plane reconverges, which directly addresses the short outage described in the question. Incremental SPF reduces CPU impact by recomputing only the affected part of the SPF tree, but it still relies on the post-failure SPF process. BFD detects a failure quickly, but by itself it does not install a loop-free repair path. Aggressive timers also improve detection but increase control-plane sensitivity and do not provide local repair. In an enterprise OSPF design where the complaint is outage during recomputation, LFA FRR is the stronger availability mechanism. Reference topics: OSPF Loop-Free Alternate, IP Fast Reroute, SPF convergence, local repair paths, routed resiliency.