Free Cisco 350-401 Practice Questions 2026 | Implementing Cisco Enterprise Network Core Technologies (350-401 ENCOR)

✅ Explanation|:

A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed, which is used to validate the authenticity of the client. JWTs are commonly used for authentication and authorization in web applications and are sent in HTTP requests, typically in the Authorization header using the Bearer scheme. The token itself is a JSON object that contains claims about the user or client, and its signature ensures its integrity and authenticity.

Why other options are incorrect:

A. SSH:
SSH (Secure Shell) is a cryptographic network protocol used for secure remote login and command execution. It is not used for client authentication in HTTP requests and does not operate with JSON objects.



B. TLS:
TLS (Transport Layer Security) is a cryptographic protocol that provides secure communication over a network. It encrypts the data in transit but does not itself validate the client's authenticity or act as a token sent in a request.

C. HTTPS:
HTTPS (Hypertext Transfer Protocol Secure) is the secure version of HTTP that uses TLS to encrypt data. It provides a secure channel but is not a token or mechanism for client authentication.

🔗 References

RFC 7519: Defines JWT as a compact, URL-safe means of representing claims to be transferred between two parties.

JWT.io: Explains that JWTs are used for authentication and are sent in HTTP headers as JSON objects.

✅ Explanation:

The exhibit shows a network with two core switches (CoreSW-1 and CoreSW-2) running HSRP (Hot Standby Router Protocol) for VLAN 10, as indicated by the standby 10 ip 192.168.1.254 command in the running configuration. PC-1's default gateway is the HSRP virtual IP address (192.168.1.254). The active router is the one that responds to ARP requests for this virtual IP and forwards traffic from PC-1 to the internet.

Why other options are incorrect:

A. CoreSW-1(config-if)# standby 10 priority 100:
This sets CoreSW-1's priority to 100, which is the default. It does not change the active router selection; CoreSW-1 would remain active (since it likely already has priority 100 or higher). Traffic would not use the link between the two switches.

C. CoreSW-2(config)# standby 10 priority 100:
This is a syntax error—the standby command must be configured under the interface, not global configuration mode. Even if corrected, setting CoreSW-2 to priority 100 would tie with CoreSW-1 (which also has default 100), and the router with the higher IP address would win. Without knowing the IP addresses, this is not a reliable way to force traffic through CoreSW-2.

D. CoreSW-1(config-if)# standby 10 priority 90:
This lowers CoreSW-1's priority below the default (100), making CoreSW-2 the active router by default. However, this would make CoreSW-2 active because its priority (100) is higher than CoreSW-1's 90. While this achieves the goal of making CoreSW-2 active, the question asks specifically which configuration causes the traffic to use the link—and the exhibit shows CoreSW-1 as the root bridge and likely the active router. The more straightforward and correct approach is to raise CoreSW-2's priority above CoreSW-1's, which is Option B.

🔗 References

Cisco HSRP Configuration Guide: HSRP active router election is based on the highest priority value (default 100). Preemption can be enabled to force a higher-priority router to take over.

Cisco IOS Interface Configuration: The standby command is configured under the interface, not globally.

✅ Explanation:

A 404 response code indicates that the client made a request for a resource that does not exist on the server. The 404 status code is part of the 4xx class of HTTP status codes, which specifically denote client errors, meaning the request cannot be fulfilled due to an apparent issue on the client's side.

In the context of the Cisco DNA Center REST API, receiving a 404 error when sending a POST request to /dna/intent/api/v1/template-programmer/project typically indicates that the URL endpoint is incorrect, the API path has changed, or the resource you are trying to interact with does not exist at that specific path.

Why other options are incorrect:

B. The server has not implemented the functionality that is needed to fulfill the request:
This is incorrect. A 501 (Not Implemented) status code indicates this scenario, where the server does not support the functionality required to fulfill the request. The 404 error specifically relates to a missing resource, not missing server functionality.

C. The request accepted for processing, but the processing was not completed:
This is incorrect. A 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed. The 404 error is a final response indicating the resource was not found.

D. The POST/PUT request was fulfilled and a new resource was created:
This is incorrect. A 201 (Created) status code indicates that the request was fulfilled and a new resource was created. The 404 error is a client error response, not a success response.

🔗 References

Cisco DNA Center API Documentation: Confirms the endpoint structure for template programmer uses /dna/intent/api/v1/template-programmer/project.

HTTP Status Codes (RFC 7231): Defines 404 as "Not Found" indicating the server cannot find the requested resource.

✅ Explanation:

A defining characteristic of an AP operating in Mobility Express mode is that it requires an AP to act as a Wireless LAN Controller (WLC). The Cisco Mobility Express solution is designed to eliminate the need for a separate, dedicated hardware controller . Instead, the WLC functionality is built into the software of a supported 802.11ac Wave 2 or newer Cisco Aironet access point .

This primary AP, also called the master AP, runs the software-based controller and manages all other subordinate APs in the network, while simultaneously serving clients . This makes it a cost-effective and simplified solution specifically tailored for small to medium-sized deployments .

Why other options are incorrect:

A. It is recommended for large scale deployments.
Incorrect. Cisco explicitly designed Mobility Express for small to mid-sized environments, with a recommended limit of up to 25 access points per controller, though later versions support up to 100 . It is not intended for large-scale enterprise deployments.

B. It requires a centralized WLC.
Incorrect. The core value proposition of Mobility Express is that it does not require a centralized, dedicated WLC appliance, as the controller function is embedded in one of the APs .

C. At least three APs are needed for WLC redundancy.
Incorrect. While the solution does support high availability through an automatic failover process, only two master-capable APs are required for redundancy . The election process, based on VRRP, can designate a backup master AP when the primary one fails .

🔗 References

Cisco Mobility Express Overview: The solution comprises at least one access point with an in-built software-based wireless controller .

Mobility Express Solution Introduction: The solution is designed for small to mid-sized businesses and does not require a dedicated controller appliance .

Explanation:

The weighted load-balancing method is specifically designed to support environments where members of a GLBP group have different throughput capabilities, as it allows you to assign different weights to each router . The Active Virtual Gateway (AVG) uses these configured weight values to determine how much traffic to direct to each router , ensuring that higher-capacity routers handle a proportionally larger share of the load. For example, if one router has double the forwarding capacity of another, its weighting value should be configured to be double that of the other router .

Why other options are incorrect:

A. host dependent:
This method ensures that a particular host always uses the same virtual forwarder (router) for the duration of its session . It is useful for applications like stateful Network Address Translation (NAT) that require a consistent path , but it does not support unequal load balancing based on different capacities.

C. least connection:
This is a load-balancing algorithm commonly used by application load balancers (like NGINX or HAProxy) to distribute traffic based on the fewest active connections. It is not a supported load-balancing method in GLBP.

D. round robin:
This is the default GLBP method where the AVG cycles through the available routers, assigning a new virtual MAC address to each new ARP request in turn . It assumes equal capacity across all routers and does not account for different throughput capabilities .

🔗 References

Cisco GLBP Command Reference: The weighted method is explicitly for unequal load balancing when devices in the GLBP group have different forwarding capacities .

Cisco GLBP Load Balancing Options: Confirms that the Weighted method is used when there are disparities in gateway capabilities .

✅ Explanation:

The Reverse Path Forwarding (RPF) check is a fundamental mechanism in multicast routing used to prevent loops . When a router receives a multicast packet, it performs an RPF check on the packet's source IP address. The router looks up the path to that source in its routing table and verifies that the packet arrived on the interface that is on the optimal return path. If it did, the packet passes the RPF check and is forwarded; if not, the packet is dropped .

Implementing static mroutes (E):
A static mroute (multicast route) is a special static route that influences only the RPF check, not the unicast forwarding table . It tells the router, "For RPF purposes, consider this specific interface as the return path to that source" . This overrides the unicast routing table for the RPF check, allowing the packet to pass without changing how unicast traffic is routed.

Implementing MBGP (C):
Multiprotocol BGP (MBGP) is an extension of BGP that can carry separate routing information for unicast and multicast topologies . When MBGP is configured, it can populate a dedicated multicast RPF table with routes that may differ from the unicast routing table . The router then uses this separate table for RPF checks, ensuring the check passes without modifying the unicast routing table.

Why other options are incorrect:

A. disabling the interface of the router back to the multicast source:
This would remove the path to the source entirely, likely breaking connectivity and routing, which is not a valid or recommended solution to address an RPF check failure.

B. disabling BGP routing protocol:
Disabling BGP would affect both unicast and multicast routing, significantly altering the network's routing behavior. This is not a targeted solution for the RPF check and would change the unicast routing table.

D. implementing OSPF routing protocol:
OSPF is a unicast routing protocol that contributes to the unicast routing table. It is already part of the standard routing environment. While OSPF could be used to change the unicast routing table, this would violate the question's premise of not changing the unicast routing table. It does not provide a separate RPF table.

🔗 References

Cisco Learning Network Discussion: Explains that static mroutes are an acceptable method to override RPF check results without affecting unicast routing, while MBGP is a more advanced solution for Service Provider environments .

✅ Explanation:

The code snippet establishes an SSH connection to a Cisco Nexus device using the netmiko Python library. Here's a breakdown of each component:

manager.connect(): This is the netmiko method used to initiate a connection to a network device.
host=192.168.0.1, port=22: Specifies the device IP address and SSH port (default 22).
username='admin', password='password1': Provides the credentials for authentication.
hostkey_verify=True: Enables SSH host key verification for security.
device_params={'name':'nexus'}: Specifies the device type as Cisco Nexus, which tells netmiko which device driver to use.

with manager.connect(...) as m: This is a context manager. It ensures that the SSH connection is automatically closed when the code block exits, even if an exception occurs.

This code does not retrieve an API token or open a tunnel; it simply creates a direct SSH session using standard username/password authentication. The host key verification is enabled (hostkey_verify=True), so it will verify the host key against the known_hosts file; it does not use an SSH key for authentication.

Why other options are incorrect:

A. It creates a temporary connection to a Cisco Nexus device and retrieves a token to be used for API calls:
Incorrect. Netmiko is used for SSH CLI-based management, not for retrieving API tokens. Token-based authentication is typically used with REST APIs, not netmiko.

B. It opens a tunnel and encapsulates the login information, if the host key is correct:
Incorrect. While SSH does encrypt the session (providing a secure tunnel), the code specifically creates a standard SSH connection for CLI access. The hostkey_verify=True parameter verifies the host key, but this is not the primary function of the code.

D. It creates an SSH connection using the SSH key that is stored, and the password is ignored:
Incorrect. The code explicitly provides a password (password='password1') as the authentication method. It does not reference or use an SSH key.

🔗 References

Netmiko Documentation:
Netmiko is a multi-vendor Python library that simplifies SSH connections to network devices and is used for sending CLI commands.

Context Manager (with statement):
In Python, the with statement creates a context that ensures the connection is properly closed after use.

✅Explanation:

The correct answer is A. on the first-hop fabric edge switch.

The AP acts as a fabric endpoint; it encapsulates client traffic into a VXLAN tunnel, but the tunnel's termination point is the adjacent fabric edge switch . This is called an "access tunnel" and is a key enabler of distributed wireless forwarding in SD-Access .

The AP performs initial VXLAN encapsulation, and the first-hop edge node performs decapsulation and policy enforcement. This design enables consistent wired and wireless policy and improved scalability .

Why other options are incorrect:

B. on the WLC node:
The WLC handles management plane traffic (image, licensing, RRM) via CAPWAP, not the data plane. In "fabric mode," the AP uses CAPWAP only for control, not for data encapsulation .

C. on the fabric border node switch:
The border node handles traffic exiting the fabric, but the first-hop edge switch receives and processes the VXLAN traffic from the AP.

D. directly on the fabric APs:
The AP originates the VXLAN tunnel but does not terminate it. It encapsulates client traffic, not decapsulate.

🔗 References
Cisco Live: "Fabric APs ... encapsulate wireless user traffic into the VXLAN-based overlay to their adjacent fabric edge node where it is decapsulated" .

Cisco Support Docs: "An access-tunnel ... is a VXLAN tunnel established between fabric edge nodes and Access Points (APs)" .