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

Explanation

In Cisco MPLS TE with Path Computation Element (PCE) delegation, the headend router delegates path computation to one or more PCE servers. The precedence of a PCE server determines its priority in the delegation list: a lower precedence value means higher priority. To influence which PCE server is used, the operator can either add a new PCE server with lower precedence than the primary PCE (making it the new preferred PCE) or change the precedence of any of the existing PCE servers (reordering the delegation priority). Both actions directly describe how ISP delegation to PCE servers is managed. This makes options A and B the correct answers.

Why the other options are incorrect:

C. Removing TE re-optimization timer timeouts
Re-optimization timers control how often TE tunnels attempt to re-optimize their paths. Removing these timers does not describe PCE server delegation and does not change which PCE server is used.

D. Entering the `mpls traffic-eng reoptimize` command
This command manually triggers TE tunnel re-optimization. It is not a delegation action to a PCE server and does not affect PCE precedence or selection.

E. Adding a new PCE server with higher precedence than the primary PCE
In Cisco IOS XR, a lower precedence value indicates higher priority. Adding a server with "higher precedence" in terms of priority would mean a lower numerical value, but the wording of this option is ambiguous and conflicts with the standard terminology. The two clear delegation actions are adding a PCE with lower precedence and changing the precedence of existing PCE servers.

Reference:
RFC 4655 – A Path Computation Element (PCE)-Based Architecture; RFC 5440 – Path Computation Element (PCE) Communication Protocol (PCEP); Cisco IOS XR MPLS Configuration Guide – Configuring MPLS TE with PCE; Cisco 350-501 SPCOR Official Cert Guide, MPLS Traffic Engineering chapter.

Explanation

The exhibit shows R2 with `interface Ethernet1/0` configured with `ip address 10.1.1.1 255.255.255.255`. To support MPLS LDP sessions, LDP must be enabled globally with `mpls label protocol ldp` (or `mpls ip`, which enables LDP by default) and then enabled on the interface with `mpls ip`. Option C provides exactly this: it configures `mpls ip` globally, `mpls label protocol ldp` globally, and then `mpls ip` on interface Ethernet1/0. This enables LDP on the interface so that it can form LDP sessions and exchange label bindings with R1. This makes option C the correct answer.

Why the other options are incorrect:

A. Option A
It enables `mpls label protocol ldp` globally and `mpls bgp forwarding` on the interface, but `mpls bgp forwarding` is used for BGP labeled unicast, not for LDP. It does not enable LDP on the interface.

B. Option B
It enables `mpls label protocol ldp` globally but then applies VRF forwarding and OSPF point-to-point on Ethernet1/1, which is not the interface shown in the exhibit and does not enable LDP on the correct interface.

D. Option D
It enables `mpls label protocol ldp` globally but then configures VRF forwarding and OSPF on the interface instead of enabling MPLS LDP with `mpls ip`. This does not enable LDP on the interface.

Reference:
Cisco IOS XR MPLS Configuration Guide – Implementing LDP: Enabling LDP on Interfaces; RFC 5036 – LDP Specification; Cisco 350-501 SPCOR Official Cert Guide, MPLS chapter.

Explanation

When an LDP router with graceful restart enabled sends an LDP Initialization message to a neighbor, it includes the Graceful Restart Capability TLV, which carries the Reconnect Timeout field and the Recovery Time field. The Graceful Restart Capability TLV is sent during session initialization to indicate that the router supports graceful restart and to specify the reconnect and recovery timers. The Learn from Neighbor (N) flag is part of the FT Reconnect TLV used during the recovery phase, not during the initial session establishment. The Learn from Network (L) flag is also not part of the initialization message. Type-9 LSA is an OSPF construct unrelated to LDP. This makes options A, C, and D the correct answers.

Why the other options are incorrect:

B. Learn from Neighbor (N) flag, set to 1
The N flag is part of the FT Reconnect TLV used during the recovery phase, not during the initial LDP session establishment. It indicates whether the restarting router should learn the FT state from the neighbor.

E. Learn from Network (L) flag, set to 1
The L flag is also part of the FT Reconnect TLV and is used during recovery, not during initialization.

F. Type-9 LSA
Type-9 LSA is an OSPFv3 link-local LSA and has no role in LDP graceful restart initialization.

Reference:
RFC 3478 – Graceful Restart Mechanism for Label Distribution Protocol (LDP); RFC 5036 – LDP Specification; Cisco IOS XR MPLS Configuration Guide – Implementing LDP: Graceful Restart; Cisco 350-501 SPCOR Official Cert Guide, MPLS chapter.

Explanation

To implement LDP NSF (Non-Stop Forwarding) on a network, the two required tasks are to enable NSF for the link-state routing protocol in use (OSPF or IS-IS) and to implement direct connections for LDP peers. LDP NSF depends on the IGP NSF to preserve the routing and forwarding state during a control-plane restart, so the IGP NSF must be enabled. Additionally, LDP NSF requires that LDP peers be directly connected, because the NSF procedures rely on the LDP session being re-established quickly and the label bindings being preserved between directly connected neighbors. This makes options B and D the correct answers.

Why the other options are incorrect:

A. 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.

C. 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.

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

To secure REST APIs on network devices, a network administrator must authenticate user sessions and assign the appropriate privilege level to each authenticated user. Authentication ensures that only legitimate users can access the API, and privilege levels enforce authorization by limiting what each user can read or write. This combination of authentication and authorization is the fundamental approach to securing REST API access. This makes option D the correct answer.

Why the other options are incorrect:

A. They can allow read and write privileges to all users
Granting read and write privileges to all users removes authorization controls and exposes the API to unauthorized changes. This is the opposite of securing the API.

B. They can ensure that user sessions are authenticated using TACACS+ only
TACACS+ is one valid authentication method, but requiring it exclusively is unnecessarily restrictive. Other methods such as local authentication, RADIUS, or certificate-based authentication can also be used. The key requirement is authentication plus proper privilege levels, not a specific protocol.

C. They can have a general administrator login for multiple users to access that has command entries logged
A shared administrator login eliminates accountability and does not provide proper authentication or authorization per user. Logging alone does not secure the API.

Reference:
RFC 8040 – RESTCONF Protocol; Cisco IOS XE RESTCONF API Configuration Guide – Authentication and Authorization; Cisco 350-501 SPCOR Official Cert Guide, Automation and Assurance section.

Explanation

The requirement is to drop traffic that matches the SUBNET prefix set, and for all other traffic, set the MED value to 400 and add community 4:400. Option A does exactly this: it uses `if destination in SUBNET then drop` to discard matching traffic, and in the `else` branch it applies `set med 400` and `set community (4:400) additive` to all non-matching traffic. The `additive` keyword ensures community 4:400 is appended rather than overwriting existing communities. This makes option A the correct answer.

Why the other options are incorrect:

B. Option B
It drops matching SUBNET traffic, then sets MED 400 for all remaining traffic, but it also sets local-preference 400 and MED 500 inside an additional `if community matches-any SUBNET` block. This adds unnecessary and incorrect actions that do not match the requirements.

C. Option C
It drops matching SUBNET traffic and sets MED 400, but then sets local-preference 400 and adds community 4:400 only if the community matches SUBNET. This applies the community only conditionally, whereas the requirement is to add community 4:400 to all non-matching traffic.

D. Option D
It uses `if destination in BGP then drop`, which would drop all BGP routes, not just the SUBNET prefix set. This does not satisfy the requirement.

Reference:
Cisco IOS XR Routing Configuration Guide – Implementing Routing Policy: Route-Policy Statements and Actions; RFC 4271 – A Border Gateway Protocol 4 (BGP-4); RFC 1997 – BGP Communities Attribute; Cisco 350-501 SPCOR Official Cert Guide, BGP and Routing Policy sections.

Explanation

The primary benefit of IPoATM (IP over ATM) or MPLS over ATM in service provider backbone networks is the use of fixed-length cells. ATM uses 53-byte fixed-length cells (5-byte header plus 48-byte payload), which allows for predictable, high-speed switching in hardware, low jitter, and efficient traffic engineering. This cell-based transport provides deterministic behavior and QoS guarantees that were particularly valuable for carrying IP and MPLS traffic over ATM backbones. This makes option D the correct answer.

Why the other options are incorrect:

A. Dedicated circuits
While ATM can provide virtual circuits, the primary benefit in the context of IPoATM and MPLS over ATM is not dedicated circuits but the fixed-length cell transport that enables predictable switching.

B. Variable-length packets
ATM does not use variable-length packets; it uses fixed-length cells. Variable-length packets are characteristic of Ethernet and IP, not ATM.

C. Isochronous system
Isochronous operation is associated with TDM and certain circuit-based technologies, not specifically with IPoATM or MPLS over ATM. While ATM can support constant bit rate (CBR) traffic, the defining benefit for carrying IP/MPLS is the fixed-length cell structure.

Reference:
RFC 2684 – Multiprotocol Encapsulation over ATM Adaptation Layer 5; ATM Forum UNI Specification – ATM Cell Structure; Cisco 350-501 SPCOR Official Cert Guide, Architecture and Transport section.

Explanation

The exhibit shows the command `ip pim ssm default` configured on router RA. This command enables PIM Source-Specific Multicast (SSM) using the default SSM range, which is **232.0.0.0/8**. In Cisco IOS, the `ip pim ssm default` command activates SSM for the default SSM group range of 232.0.0.0/8 (as defined in RFC 4607). When SSM is enabled, receivers use IGMPv3 to join specific source-group pairs within this range, and PIM builds source-specific shortest-path trees directly to the source without requiring an RP. This makes option C the correct answer.

Why the other options are incorrect:

A. 224.0.0.0/8
This is the entire multicast address space reserved for IPv4 multicast (Class D), not the SSM range. It includes link-local (224.0.0.0/24), globally scoped, and administratively scoped addresses.

B. 225.0.0.0/8
This is part of the general multicast address space but is not the default SSM range. SSM uses 232.0.0.0/8 by default.

D. 239.0.0.0/8
This is the administratively scoped multicast range (RFC 2365), used for private multicast domains. It is not the SSM range.

Reference:
RFC 4607 – Source-Specific Multicast for IP; Cisco IOS XR Multicast Configuration Guide – Configuring PIM-SSM and the SSM Range; Cisco 350-501 SPCOR Official Cert Guide, Multicast chapter.

Explanation

The exhibit shows `netconf-yang` and `netconf-yang feature candidate-datastore` configured on Router 1. The `candidate-datastore` feature enables the NETCONF candidate configuration datastore, which is a temporary data store where configuration changes can be staged, manipulated, and verified before being committed to the running configuration. This allows the administrator to make multiple changes, validate them, and then commit them atomically using the `commit` operation. This makes option D the correct answer.

Why the other options are incorrect:

A. Router 1 has its running configuration locked so changes can be made only when the administrator issues a kill session
The candidate datastore does not lock the running configuration in this way. It provides a separate staging area for changes, and the running configuration is not locked pending a kill session.

B. Router 1 can be remotely managed by the CLI using Telnet
The configuration enables NETCONF/YANG, which is a model-driven programmatic interface, not Telnet CLI access. The `netconf-yang` command does not enable Telnet.

C. Router 1 has a new data store to collect SNMP information, but configuration must still be done at the CLI only
The candidate datastore is for NETCONF configuration changes, not SNMP information collection. Additionally, the configuration can be done via NETCONF, not only at the CLI.

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