Free Cisco 350-501 Practice Questions 2026 | Implementing and Operating Cisco Service Provider Network Core Technologies (350-501 SPCOR)

Explanation

Cisco Network Services Orchestrator (NSO) is a network automation platform that bridges automation systems and the physical network infrastructure. It uses model-driven interfaces (YANG, NETCONF, RESTCONF) to abstract multivendor devices and enables end-to-end service orchestration, configuration management, and lifecycle automation across physical and virtual network devices. Its role is to translate high-level service intent into device-specific configurations, acting as the bridge between automation tools and the actual network hardware. This makes option D the correct answer.

Why the other options are incorrect:

A. It is a GUI used to manage wireless devices in a campus infrastructure
NSO is not a wireless management GUI. Wireless management in a campus is handled by Cisco Catalyst Center (formerly DNA Center), not NSO.

B. It is a type of REST API used to configure an APIC
NSO is not a REST API, nor is it used specifically to configure APIC. It is an orchestration platform that can manage APIC among many other devices via its model-driven interfaces.

C. It is a tool that uses CLI only to configure virtual network devices
NSO does not rely on CLI only; it uses model-driven interfaces (NETCONF, RESTCONF, YANG) and can also use CLI-based NEDs (Network Element Drivers) for legacy devices. It manages both physical and virtual devices, not just virtual ones.

Reference:
Cisco NSO Documentation – Network Services Orchestrator Overview; Cisco 350-501 SPCOR Official Cert Guide, Automation and Assurance section.

Explanation

When RIP is used as the routing protocol between PEs and CEs in an MPLS L3VPN environment, the engineer must prevent routes from being advertised back to their source. This is achieved by defining the site of origin on each interface. The site of origin is a BGP extended community attribute that identifies the site from which a route originated. When the PE receives a route from a CE, it attaches the site of origin attribute. When advertising routes back to the CE, the PE checks the site of origin and suppresses routes that originated from the same site, preventing the route from being sent back to its source. This makes option B the correct answer.

Why the other options are incorrect:

A. Configure a different route distinguisher for each prefix
Route distinguishers (RDs) are used to make VPNv4 prefixes unique across the MPLS domain. They do not prevent routes from being advertised back to their source.

C. Define VRFs on each device to separate the traffic
VRFs separate customer routing tables, but they do not by themselves prevent routes from being advertised back to their source site. The site of origin mechanism is specifically designed for this purpose.

D. Enable bidirectional forwarding detection on each device
BFD is a fast failure detection mechanism and has no role in preventing route feedback or loop prevention in RIP.

Reference:
RFC 4364 – BGP/MPLS IP Virtual Private Networks (VPNs); Cisco IOS XR MPLS Configuration Guide – Implementing MPLS L3VPN: Site of Origin; Cisco 350-501 SPCOR Official Cert Guide, MPLS L3VPN chapter.

Explanation

The FEC (Forward Error Correction) field within the OTN (Optical Transport Network) signal structure allows the receiving device to detect and correct errors that occur during transmission without requiring retransmission. OTN uses Reed-Solomon FEC, which adds redundancy to the signal so that the receiver can correct bit errors introduced by the optical transport. This improves reliability and allows longer spans and higher capacities. This makes option C the correct answer.

Why the other options are incorrect:

A. It allows the sending devices to apply QoS within the OTN forwarding structure – FEC is an error correction mechanism, not a QoS mechanism. QoS is handled by other fields and mechanisms in the network.

B. It allows source nodes to discard payload errors before transmitting data on the network – FEC operates at the receiver to correct errors after transmission. It does not involve source nodes discarding payload errors before transmission.

D. It allows deep inspection of data payload fields – FEC does not inspect payload fields. It operates on the OTN frame structure and corrects transmission errors; it does not perform deep packet inspection.

Reference:
ITU-T G.709 – Interfaces for the Optical Transport Network (OTN); ITU-T G.975 – Forward Error Correction for Submarine Systems; Cisco 350-501 SPCOR Official Cert Guide, Architecture and Transport section.

Explanation

YANG (Yet Another Next Generation) is a data modeling language used primarily with NETCONF and RESTCONF. Its two main uses are to model the configuration data used by NETCONF operations and to model the state data of network elements. YANG defines the structure, syntax, and semantics of the data that can be configured and retrieved from a network device, including both configuration (intended state) and operational state (actual state) data. This makes options B and C the correct answers.

Why the other options are incorrect:

A. It is used to access a device by HTTP – YANG is a modeling language, not an access protocol. HTTP is a transport protocol, and RESTCONF (which uses YANG models) runs over HTTP, but YANG itself does not provide HTTP access.

D. It is used to replace RESTCONF as a mechanism to install and manipulate configuration – YANG does not replace RESTCONF; it is used by RESTCONF (and NETCONF) to define the data models. RESTCONF is the protocol, and YANG is the modeling language used with it.

E. It is used to replace the OSI model for troubleshooting – YANG has no relationship to the OSI model. The OSI model is a conceptual framework for network communication, while YANG is a data modeling language for network configuration and state.

Reference:
RFC 7950 – The YANG 1.1 Data Modeling Language; RFC 6241 – Network Configuration Protocol (NETCONF); RFC 8040 – RESTCONF Protocol; Cisco 350-501 SPCOR Official Cert Guide, Automation and Assurance section.

Explanation

PIM-SSM (Source-Specific Multicast) requires IGMP version 3 at the interface level so that receivers can specify the source address they want to join, which is the defining characteristic of SSM. It also requires PIM sparse mode to be enabled on the device, because SSM uses the PIM-SM protocol machinery to build source-specific shortest-path trees (SPTs) directly to the source. Without IGMPv3, the receiver cannot signal the source, and without PIM-SM, the multicast forwarding infrastructure is not in place. This makes options C and D the correct answers.

Why the other options are incorrect:

A. Configure at least one MSDP peer on the network – MSDP is used for inter-domain multicast with PIM-SM shared trees and RPs. SSM does not use an RP and does not require MSDP, because receivers join the source-specific tree directly.

B. Enable IGMP version 2 at the interface level – IGMPv2 does not support source-specific joins. It only allows a receiver to join a group, not a specific source. SSM requires IGMPv3.

E. Enable PIM dense mode on the device – PIM-DM is a flood-and-prune model that does not support SSM. SSM requires PIM-SM with IGMPv3.

Reference:
RFC 4607 – Source-Specific Multicast for IP; RFC 3376 – Internet Group Management Protocol, Version 3; Cisco IOS XR Multicast Configuration Guide – Configuring PIM-SSM; Cisco 350-501 SPCOR Official Cert Guide, Multicast chapter.

Explanation

CE1 is connected to two provider edge routers, PE1 and PE2, and needs to use PE1 as the primary path to the Internet. Since CE1 is the router making the outbound path selection decision for traffic leaving its site, the attribute that controls this decision on CE1 is weight. Weight is a Cisco-proprietary attribute that is locally significant to the router and is not advertised to BGP peers. By manipulating the weight on PE1's outbound routes advertised to CE1, CE1 will prefer the routes learned from PE1 over those learned from PE2. The higher weight value wins. This makes option A the correct answer.

Why the other options are incorrect:

B. The MED should be manipulated on CE1 on inbound routes from PE1 – MED is used to influence inbound traffic from an external AS, not outbound path selection on the local router. Additionally, MED is evaluated after weight and local preference, and manipulating MED on CE1 for inbound routes does not directly control which PE CE1 uses for outbound traffic.

C. The local preference attribute should be manipulated on PE2 on inbound routes advertised to CE1 – Local preference is used within an AS to influence outbound path selection, but it is not advertised to external peers such as CE1. PE2 advertising local preference to CE1 would not be effective because local preference is not propagated in eBGP updates.

D. The origin of all routes should be modified on each router on inbound and outbound routes advertised to CE1 – The origin attribute indicates whether a route was learned via IGP (i), EGP (e), or incomplete (?). Modifying the origin attribute is not a standard or effective way to influence path selection for this scenario.

Reference:
Cisco IOS XR Routing Configuration Guide – Implementing BGP: BGP Best Path Selection and Weight; RFC 4271 – A Border Gateway Protocol 4 (BGP-4); Cisco 350-501 SPCOR Official Cert Guide, BGP chapter.

Explanation

To implement LDP NSF on a network, the engineer must enable NSF for the link-state routing protocol in use (OSPF or IS-IS) and implement direct connections for LDP peers. LDP NSF relies on the IGP NSF to preserve the routing and forwarding state during a control-plane restart, so IGP NSF must be enabled. Additionally, LDP NSF requires that LDP peers be directly connected, as the NSF procedures depend on the LDP session being re-established quickly and label bindings being preserved between directly connected neighbors. This makes options C and D the correct answers.

Why the other options are incorrect:

A. Disable Cisco Express Forwarding – CEF must remain enabled for MPLS LDP forwarding. Disabling CEF would break MPLS forwarding and is not part of LDP NSF implementation.

B. Enable NSF for EIGRP – EIGRP is not a link-state protocol and is not used with LDP NSF in service provider MPLS networks. LDP NSF works with OSPF or IS-IS.

E. Enable NSF for BGP – BGP NSF is a separate feature for BGP graceful restart. While it can be used in the same network, it is not a requirement for LDP NSF.

Reference:
RFC 3478 – Graceful Restart Mechanism for Label Distribution Protocol (LDP); RFC 3623 – Graceful OSPF Restart; RFC 5306 – Restart Signaling for IS-IS; Cisco IOS XR MPLS Configuration Guide – Implementing LDP: Non-Stop Forwarding; Cisco 350-501 SPCOR Official Cert Guide, MPLS and Network Assurance sections.

Explanation

The exhibit shows four routers configured with router isis and no is-type command. Since no is-type is configured, all four routers default to operating as Level 1-2 routers. This means each router runs both a Level 1 and a Level 2 process. On the shared broadcast segment (192.168.0.0/24), routers in the same area form both Level 1 and Level 2 adjacencies, while routers in different areas form only Level 2 adjacencies. R1 and R4 both use area 0011 in their NET addresses, and R1 and R2 are in different areas (R1 in 0011, R2 in 0022). Therefore, R1 and R4 form a Level 2 adjacency (and also a Level 1 adjacency since they are in the same area), and R1 and R2 form a Level 2 adjacency. This makes options C, D, and E all correct in isolation, but since the question asks for two, the most distinguishing topology changes are that all four routers are Level 1-2 routers (E) and that R1 and R4 are Level 2 neighbors (C) — or alternatively R1 and R2 are Level 2 neighbors (D). Based on the NET addresses, R1 and R4 share area 0011, while R1 and R2 are in different areas. The two correct answers are C and E: R1 and R4 are Level 2 neighbors, and all four routers are operating as Level 1-2 routers.

Why the other options are incorrect:

A. All four routers are operating as Level 1 routers only – This is incorrect because no is-type level-1 is configured. The default is Level 1-2, so all routers run both levels.

B. All four routers are operating as Level 2 routers only – This is incorrect because no is-type level-2-only is configured. The default is Level 1-2, so all routers also run Level 1.

D. R1 and R2 are Level 2 neighbors – While this is technically true (they are in different areas and form a Level 2 adjacency), the question asks for two topology changes, and the more significant changes are that all routers are Level 1-2 and that R1 and R4 (same area) are Level 2 neighbors. If forced to choose two, C and E are the best answers.

Reference:
ISO/IEC 10589 – IS-IS for Routing Information Exchange; Cisco IOS XR Routing Configuration Guide – Implementing IS-IS: Router Types and Adjacency Formation; Cisco 350-501 SPCOR Official Cert Guide, IS-IS chapter.

Explanation

The scenario describes IOS-XR platforms where i-BGP sessions work but e-BGP sessions do not exchange routes. In Cisco IOS XR, the default behavior for eBGP neighbors is to drop all routes if no explicit inbound or outbound route policy is applied. This differs from traditional Cisco IOS, where eBGP routes are accepted by default. On IOS XR, when an eBGP neighbor is configured without a route policy, the default policy is to drop all routes in both directions. This explains why the eBGP sessions do not exchange routes — the customer platforms' default policy is blocking route exchange until an explicit pass-all or other route policy is applied. This makes option C the correct answer.

Why the other options are incorrect:

A. A PASS ALL policy has not been implemented for the i-BGP neighbors – The question states that i-BGP sessions are working and exchanging prefixes, so a pass-all policy for i-BGP is not the issue.

B. The next-hop-self command is not implemented on both E-BGP neighbors – Next-hop-self is a common practice for i-BGP, not a requirement for eBGP route exchange. Its absence would not prevent eBGP from exchanging routes.

D. The i-BGP neighbors are mistyped and HELLO packets cannot be exchanged – BGP does not use HELLO packets (that is OSPF and IS-IS). BGP uses TCP port 179. Additionally, the i-BGP sessions are working, so they are not mistyped.

Reference:
Cisco IOS XR Routing Configuration Guide – Implementing BGP: Default Behavior for eBGP Neighbors Without Policies; RFC 4271 – A Border Gateway Protocol 4 (BGP-4); Cisco 350-501 SPCOR Official Cert Guide, BGP chapter.

Explanation

The requirement is to implement uRPF loose mode on the GigabitEthernet0/1 interface. In Cisco IOS, loose mode uRPF is configured using the ip verify unicast source reachable-via any command for IPv4 and ipv6 verify unicast source reachable-via any for IPv6. Loose mode checks whether the source address exists in the FIB (reachable via any interface) rather than requiring it to be reachable via the same ingress interface. Option A shows both IPv4 and IPv6 configured with reachable-via any, which is the correct syntax for loose mode on both address families. This makes option A the correct answer.

Why the other options are incorrect:

B. Option B – It uses reachable-via rx for IPv6, which is strict mode, not loose mode. Strict mode requires the source to be reachable via the same interface the packet arrived on, which is not the requirement.

C. Option C – It uses reachable-via rx for IPv4, which is strict mode for IPv4, not loose mode.

D. Option D – It uses reachable-via rx for both IPv4 and IPv6, which is strict mode for both address families, not loose mode.

Reference:
RFC 3704 – Ingress Filtering for Multihomed Networks; Cisco IOS XR Security Configuration Guide – Unicast Reverse Path Forwarding (uRPF) Loose and Strict Modes; Cisco 350-501 SPCOR Official Cert Guide, Security section.