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

Explanation

In a Remote-Triggered Black Hole (RTBH) filtering setup, Router 1 serves as the trigger router where the administrative team injects the destination prefix under attack and sets a specialized next-hop (such as an unroutable IP).

Why Option A Is Incorrect
Edge routers (Router 2) do not point a static route for the actual victim network directly to Null 0. Instead, they point a static route targeting the dummy next-hop address (provided by the trigger router) to Null 0.

Why Option C Is Incorrect

Unicast Reverse Path Forwarding (uRPF) is deployed on ingress edge interfaces facing customer networks to drop IP spoofing packets, not on the core trigger router.

Why Option D Is Incorrect
The configuration exhibits how the routing infrastructure drops traffic destined for an attack prefix, but it does not specify which router is directly receiving the incoming volumetric DDoS traffic.

Reference
Cisco Official Documentation: Implementing and Operating Cisco Service Provider Network Core Technologies (SPCOR 350-501) — Chapter: Service Provider Security, Remote-Triggered Black Hole (RTBH) Filtering Architecture.

Explanation

The configuration command mpls ldp graceful-restart enables the Label Distribution Protocol (LDP) Graceful Restart mechanism on the router.

Why Option A Is Correct
When LDP graceful restart is enabled, R1 can preserve its MPLS forwarding state and assist a neighboring peer configured with Nonstop Forwarding / Stateful Switchover (NSF/SSO) during a control plane restart or outage recovery, preventing traffic disruption.

Why Option B Is Incorrect
R1 can establish standard LDP sessions and interoperate with any compliant LDP peer, not only peers configured with LDP SSO/NSF.

Why Option C Is Incorrect
Failover behavior and graceful restart capabilities depend heavily on peer negotiations and capability advertisements. LDP graceful restart must be supported or negotiated between peers, rather than arbitrarily failing over to any peer.

Why Option D Is Incorrect
Graceful restart operations require mutual capability advertisement during the LDP initialization phase. If graceful restart is disabled on the peer, the peer will not advertise the graceful restart TLV, preventing the feature from functioning as intended with that neighbor.

Reference
Cisco Official Documentation: Implementing and Operating Cisco Service Provider Network Core Technologies (SPCOR 350-501) — MPLS LDP Graceful Restart and High Availability Configuration Guide.

Explanation
Bidirectional PIM (BIDIR-PIM) prevents loops by electing a single Designated Forwarder (DF) on each network segment for every RP. Only the DF is allowed to forward multicast traffic toward the RP, which guarantees a loop-free bidirectional tree. If the network is only partially upgraded to support BIDIR-PIM — meaning some routers run BIDIR-PIM while others do not — the DF election cannot complete consistently across all segments. As a result, more than one router may believe it is the DF, or no router takes the DF role, causing packets to be forwarded in a loop instead of being forwarded only by the elected DF. This makes option B the correct answer.

Why the other options are incorrect:

A. The network does not support BIDIR-PIM – If BIDIR-PIM were completely unsupported, the feature would simply fail to operate and traffic would be dropped, not looped. Loops specifically arise from inconsistent DF election, which happens in a partially upgraded network.

C. No interface for carrying traffic for multicast groups has been configured – If no interface were configured for the multicast group, traffic would be dropped rather than looped. The absence of an interface does not cause a forwarding loop.

D. The router has not been configured to advertise itself – Failing to advertise (for example, as a candidate RP) would prevent the RP from being learned, which would stop the shared tree from being built. It would not cause a packet loop.

Reference:
RFC 5015 – Bidirectional Protocol Independent Multicast (BIDIR-PIM); Cisco IOS XR Multicast Configuration Guide – Configuring BIDIR-PIM and DF Election; Cisco 350-501 SPCOR Official Cert Guide, Multicast chapter.

Explanation
In PIM Sparse Mode, multicast traffic initially flows over the shared tree (RPT) rooted at the Rendezvous Point (RP). By default, the last-hop router switches to the shortest-path tree (SPT) once the traffic rate exceeds the SPT threshold, which is normally 0 kbps, meaning the switch happens immediately upon receiving the first data packet. To keep traffic permanently on the shared tree, the SPT threshold must be set to infinity using the `ip pim spt-threshold infinity` command. This forces the router to never initiate the SPT switchover, so all traffic continues to flow through the RP-rooted shared tree. This makes option A the correct answer.

Why the other options are incorrect:

B. The RP IP address is configured incorrectly – An incorrect RP address would prevent the shared tree from being built properly, likely causing multicast traffic to fail entirely rather than remain on the shared tree. It does not cause traffic to stay on the shared tree.

C. The RP announcements are being filtered – Filtering RP announcements would disrupt RP discovery and could prevent the shared tree from functioning. It does not cause traffic to permanently remain on the shared tree.

D. SSM range is being used – Source-Specific Multicast does not use an RP or a shared tree at all. Receivers join the source-specific tree directly using IGMPv3, so the concept of staying on the shared tree does not apply in SSM.

Reference:
RFC 7761 – Protocol Independent Multicast - Sparse Mode (PIM-SM); Cisco IOS XR Multicast Configuration Guide – Configuring PIM-SM: SPT Threshold; Cisco 350-501 SPCOR Official Cert Guide, Multicast chapter.

Explanation
Cisco Network Services Orchestrator (NSO) is an orchestration platform that provides full lifecycle management of network devices, including service design, provisioning, configuration management, and ongoing operations. It uses YANG models and NETCONF/RESTCONF to abstract device configurations and automate end-to-end service delivery across multivendor networks. This end-to-end lifecycle management — from service creation and provisioning to assurance and decommissioning — is the core role of NSO. This makes option C the correct answer.

Why the other options are incorrect:

A. It automates the deployment of access points with its built-in wireless LAN controller – NSO does not include a built-in wireless LAN controller. Wireless AP deployment is handled by Cisco DNA Center or Catalyst Center, not NSO.

B. It manages WAN infrastructure using a virtual switch – NSO is a software orchestration platform, not a virtual switch or WAN infrastructure manager. It manages devices through model-driven interfaces, not by acting as a virtual switch.

D. It resides on a hypervisor that runs the Windows OS – NSO typically runs on Linux-based systems or as a virtual appliance, not on a Windows OS. The platform requirement is not Windows.

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

Explanation

RESTCONF uses HTTP-based methods (GET, POST, PUT, PATCH, DELETE) to interact with network devices, and when secured with TLS it becomes HTTPS. TLS provides encryption, integrity, and authentication for RESTCONF sessions. On Cisco devices, TLS for RESTCONF is commonly implemented using NGINX acting as a proxy web server, which handles the HTTPS termination and forwards requests to the RESTCONF API. This is a standard deployment model on Cisco IOS XE and IOS XR platforms. This makes option B the correct answer.

Why the other options are incorrect:

A. It requires certificates for authentication – TLS can use certificates, but it does not strictly require them for authentication in all deployments. Client authentication via certificates is optional; TLS can operate with server-side certificates only. RESTCONF authentication is typically handled by AAA (username/password or token), while TLS provides transport security.

C. It is used for HTTP and HTTPS requests – TLS is specifically used for HTTPS, not plain HTTP. Plain HTTP requests are unencrypted and do not use TLS, so this statement is inaccurate.

D. It is not supported on Cisco devices – TLS is fully supported on Cisco devices for RESTCONF and other management interfaces. Cisco IOS XE, IOS XR, and NX-OS all support HTTPS/TLS for RESTCONF.

Reference:
RFC 8040 – RESTCONF Protocol; RFC 8446 – The Transport Layer Security (TLS) Protocol Version 1.3; Cisco IOS XE RESTCONF API Configuration Guide – HTTPS and TLS Support; Cisco 350-501 SPCOR Official Cert Guide, Automation and Assurance section.

Explanation
Area 10 must receive interarea routes and support mutual redistribution of external routes with the extranet. This means Area 10 cannot be a stub or totally stubby area, because those area types block external routes (Type 5 LSAs). The correct area type for supporting external route redistribution while still receiving interarea routes is NSSA (Not-So-Stubby Area), which allows Type 7 LSAs to carry external routes. Therefore, Area 10 must be configured as `nssa` on both R9 and XR32.

Area 11 must receive only the default route (`::/0`) from the ABR, must not support external route redistribution, and the ABR must not advertise any interarea routes. This describes a totally stubby area, which is configured with `stub no-summary` on the ABR and `stub` on the internal router. The `no-summary` keyword on the ABR blocks all interarea (Type 3) LSAs except the default route, satisfying all requirements for Area 11.

This makes options C and E the correct answers.

Why the other options are incorrect:

A. Configure area 11 as nssa no-summary on R7 and as nssa on XR31 – NSSA allows external route redistribution via Type 7 LSAs, which violates the requirement that external route redistribution is not supported in Area 11. The correct type for Area 11 is totally stubby, not NSSA.

B. Configure area 10 as stub on R9 and XR32 – A stub area blocks external routes (Type 5 LSAs), which violates the requirement that Area 10 must support mutual redistribution of external routes with the extranet.

D. Configure area 11 as nssa default-information-originate on R7 and as nssa on XR31 – NSSA allows external redistribution, which is prohibited in Area 11. Additionally, `default-information-originate` in NSSA generates a Type 7 default route, but the requirement calls for the totally stubby behavior where only the default route is received and no external redistribution is supported.

Reference:
RFC 3101 – The OSPF Not-So-Stubby Area (NSSA) Option; RFC 5340 – OSPF for IPv6 (OSPFv3); Cisco IOS XR Routing Configuration Guide – Implementing OSPFv3: Stub and NSSA Areas; Cisco 350-501 SPCOR Official Cert Guide, OSPF chapter.

Explanation

The exhibit shows a NetFlow configuration using `ip flow-export version 9` with `ip flow ingress` on the interface. NetFlow version 9 is a flexible, template-based export format that supports a wide range of fields, including those needed for traceback analysis. Traceback analysis is used to identify the source and path of attack traffic, and it requires detailed flow information such as source and destination IP addresses, source and destination ports, protocol, TCP flags, andsource interface. The `ip flow ingress` command captures flow data on the ingress direction of the interface, and NetFlow v9 includes the input interface (source interface) as one of its supported fields, which is essential for traceback analysis to determine where traffic entered the router. This makes option C the correct answer.

Why the other options are incorrect:

A. BGP version
– NetFlow does not report the BGP version as part of its flow records. BGP-related fields such as AS numbers can be included, but the BGP version itself is not a NetFlow field used for traceback analysis.

B. Packet size distribution
– NetFlow records include packet and byte counts, not packet size distribution histograms. Packet size distribution is not a standard NetFlow field for traceback.

D. IP sub flow cache
– The sub flow cache is an internal memory structure used by NetFlow to store flow entries before they are exported; it is not information provided for traceback analysis.

Reference:
Cisco IOS NetFlow Configuration Guide – NetFlow Version 9 Field Types and Traceback Analysis; RFC 3954 – Cisco Systems NetFlow Services Export Version 9; Cisco 350-501 SPCOR Official Cert Guide, Network Assurance section.

Explanation
The exhibit shows R1 configured with `ip ospf message-digest-key 1 md5 cisco` and `ip ospf authentication message-digest` on FastEthernet1/0. For two OSPF routers to establish an adjacency using MD5 authentication, both routers must be configured with matching authentication parameters. Specifically, the key ID, the key value (password), and the authentication type (MD5) must match on both sides. If the key ID or key value differs, the MD5 hash computed by each router will not match, and the OSPF hello packets will fail authentication, preventing the adjacency from forming. Therefore, the OSPF peer must use the same key ID and key value as configured on R1. This makes option A the correct answer.

Why the other options are incorrect:

B. The interface on the OSPF peer may have a different key ID, but it must use the same key value as the configured interface – The key ID is part of the authentication information included in the OSPF packet. If the key IDs differ, the receiving router will not be able to look up the correct key to validate the MD5 digest, and authentication will fail. Both the key ID and key value must match.

C. The OSPF peer must be configured as an OSPF stub router – The stub router designation is unrelated to authentication. It affects the router's behavior in the SPF calculation but does not influence whether an adjacency can be established with MD5 authentication.

D. The OSPF peer must use clear-text authentication – R1 is configured for MD5 authentication, not clear-text authentication. The authentication type must match on both sides, so the peer must also use MD5, not clear-text.

Reference:
RFC 2328 – OSPF Version 2 (Authentication); RFC 5709 – OSPFv2 HMAC-SHA Cryptographic Authentication; Cisco IOS XR Routing Configuration Guide – Implementing OSPF: Authentication; Cisco 350-501 SPCOR Official Cert Guide, OSPF chapter.