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

Explanation:

The scenario describes an Over-the-Top (OTT) wireless solution within an SD-Access Fabric wired network. In an OTT deployment, the wireless solution operates outside (over the top of) the SD-Access fabric—the fabric acts simply as an IP transport network for wireless traffic . The architect wants APs to register to the WLC and centrally switch traffic.

Local mode is the AP mode that meets this requirement. In local mode, the AP establishes a CAPWAP tunnel to the WLC, and all client data traffic is tunneled back to the controller for centralized processing . This is the standard mode for centralized switching in traditional Cisco wireless deployments and is the supported mode for OTT wireless within an SD-Access fabric . The AP registers to the WLC via CAPWAP, and traffic flows through the fabric to the WLC for switching .

Why other options are incorrect:

A. Bridge:
This is not a standard AP mode in Cisco wireless for this purpose. Bridge mode is used for mesh deployments, not for registering APs to a WLC for centralized switching.

B. Fabric:
Fabric mode is the native SD-Access wireless integration, where APs are part of the fabric overlay and wireless traffic is encapsulated in VXLAN and sent directly to the fabric edge node, bypassing the WLC for data traffic . This mode is used for fully integrated SD-Access wireless, not for OTT deployments .

C. FlexConnect:
FlexConnect mode enables local switching at the AP itself, where traffic is switched locally at the remote site rather than being tunneled back to the WLC . This is designed for branch deployments with WAN links, not for centralized switching in an OTT SD-Access scenario.

References:

Cisco Extended Enterprise Design Guide: "Centralized wireless deployment model can be used in SD-Access deployments; in this mode, the SD-Access fabric is simply a transport network for the wireless traffic. This is called Over the Top (OTT)"

Explanation:

For web authentication redirection, the pre-authentication ACL must be constructed with a specific logic: deny traffic destined for the external web server so the controller can intercept and redirect it, but permit traffic to the DNS server and the HTTP/HTTPS ports (80 and 443) the client needs for the initial redirection process. The ACL is applied before authentication, restricting the client's access to only the ISE servers and other necessary services until they log in.

Why other options are incorrect:

Option B:
Contains a deny udp any any eq domain statement for DNS. This would block DNS resolution, preventing the client from resolving ISE's hostname or performing captive portal detection, breaking the authentication process.

Option C: Uses permit statements for the ISE servers instead of deny. This would allow the client to bypass the web authentication redirect entirely, as traffic to the servers would never be intercepted, directly violating the requirement.

Option D: Missing explicit deny ip any any at the end. Cisco Extended ACLs have an implicit deny all, but in web redirect scenarios, the controller interprets permit statements as allowed traffic and deny statements as redirect triggers. While the implicit deny may provide a fallback, the absence of explicit deny entries for the ISE servers means this ACL would allow all traffic to the ISE servers and block necessary redirection traffic for port 80/443, breaking the redirect flow.

References:

Cisco 9800 Configuration Guide: Pre-authentication ACL must deny traffic to the ISE server and permit HTTP/HTTPS for redirect to function correctly.

Cisco Community Documentation: "The ACL for redirect uses deny" – Example ACL shows deny ip any host and permit tcp any any eq 80.

Explanation:

Cisco Hyperlocation is an ultra-precise location solution designed to track wireless clients with significantly improved accuracy compared to traditional RSSI-based methods . The core method used by this solution is Angle of Arrival (AoA) .

AoA technology calculates the direction from which a radio-frequency signal arrives by measuring the time difference of arrival (TDOA) at each element of a specialized antenna array . In a Cisco Hyperlocation deployment, the APs receive Wi-Fi signals from client devices, analyze the phase differences of the incoming signals, and use these measurements to triangulate the device's precise location. The Cisco Hyperlocation module, specifically the WSM2 variant with its 32-antenna configuration, is designed to achieve accuracy of up to one meter .

The location engine uses AoA-phase measurements to triangulate the position of a device, achieving high precision when the device is within the convex hull of the participating access points . In scenarios where the device is outside this optimal zone, the system can fall back to a "Fusion" mode, which combines AoA data with standard RSSI calculations to estimate the most likely location .

Why other options are incorrect:

B. location patterning: This refers to Wi-Fi fingerprinting, which uses stored signal strength profiles to determine location, not the phase-difference measurements used by Hyperlocation .

C. TTL:
Time-to-Live is a field in IP packets used to prevent routing loops, not a method for determining physical location .

D. line of sight:
While line of sight can improve signal strength, Hyperlocation calculates AoA even in Non-Line-of-Sight (NLOS) conditions by analyzing phase differences, making this an inaccurate characterization of its primary technology .

References:

Cisco Hyperlocation Configuration Guide:
"The solution uses the Angle-of-Arrival (AoA) of Wi-Fi signals to determine the location of connected mobile devices"

Cisco 9800 Configuration Guide:
"The Cisco Hyperlocation radio module provides... 32-antenna angle of arrival (AoA)"

Explanation:

Bidirectional Forwarding Detection (BFD) is a lightweight protocol designed to provide rapid detection of forwarding path failures between network devices. Its primary purpose is to decouple failure detection from routing protocols, enabling sub-second detection regardless of the underlying media or protocol.

BFD provides two key benefits for campus network design:

Speeds up routing convergence time (A):
Traditional routing protocols like OSPF and EIGRP rely on hello timers and dead intervals (typically 10–40 seconds) to detect neighbor failures. When BFD is integrated with these protocols, it triggers a notification to the routing process immediately upon detecting a failure. This eliminates the wait for hold-down timers, allowing the routing protocol to recalculate alternate paths and converge much faster—often within milliseconds. This significantly improves network reliability and reduces traffic loss during failures.

Provides path failure detection in less than a second (B):
BFD achieves sub-second failure detection by sending rapid control packets at intervals as low as 50 milliseconds, with a multiplier of 3, enabling detection within 150 milliseconds. This is far faster than the default behavior of most routing protocols, which require several seconds. BFD's ability to detect failures in milliseconds makes it essential for high-availability campus networks where rapid failover is critical, such as for voice, video, and real-time applications.

Why other options are incorrect:

C. BFD provides fault tolerance by enabling multiple routers to appear as a single virtual router:
This describes the function of First Hop Redundancy Protocols (FHRP) like HSRP, VRRP, or GLBP. BFD does not provide virtual router functionality; it only detects failures between directly connected neighbors. While BFD can be used with FHRP to accelerate failover, it is not responsible for the virtual router abstraction.

D. BFD is an efficient way to reduce memory and CPU usage:
BFD was designed for fast detection, not resource conservation. While the BFD Echo function can reduce CPU overhead by offloading processing, BFD sessions still consume resources to maintain rapid packet exchanges. The protocol's primary benefit is speed, not efficiency.

E. BFD enables network peers to continue forwarding packets in the event of a restart:
This describes Non-Stop Forwarding (NSF) or Graceful Restart mechanisms. BFD detects failures and triggers routing protocol recalculation, but it does not enable peers to continue forwarding through a restarting device.

References:

RFC 5880 - BFD Specification: "BFD provides a lightweight mechanism for detecting path failures in less than a second" Cisco BFD Configuration Guide: "BFD provides sub-second failure detection and triggers faster routing convergence"

Explanation:

EIRP (Effective Isotropic Radiated Power) is the specific calculation used to measure the total radiated power of a signal after it has passed through the entire transmission chain—from the radio transmitter, through the antenna cable (accounting for loss), to the antenna (accounting for gain). EIRP represents the theoretical power that would need to be emitted by an ideal isotropic antenna (which radiates equally in all directions) to produce the same maximum signal strength in the direction of the antenna's main lobe.

The calculation is: EIRP = Transmitter Power (dBm) - Cable Loss (dB) + Antenna Gain (dBi). This formula accounts for all components in the RF path. EIRP is a critical measurement because it determines the actual coverage area of a wireless signal and must comply with regulatory limits (e.g., FCC, ETSI) for legal operation. It is expressed in dBm (decibels relative to 1 milliwatt) but represents the aggregate system power after all gains and losses.

Why other options are incorrect:

B. mW (milliwatt):
This is a basic unit of absolute power, like watts or kilowatts. It does not account for antenna gain or cable loss, which are essential factors in determining the final radiated power. mW is simply a unit of measurement, not a calculation that includes the entire RF chain.

C. dBm:
This is a logarithmic measure of absolute power relative to 1 milliwatt (0 dBm = 1 mW). While dBm is used to express the transmitter's output power and the final EIRP result, it does not, by itself, represent the final radiated power after accounting for cable loss and antenna gain.

D. dBi: This is the unit used to express the gain of an antenna relative to an isotropic radiator. It measures how effectively the antenna focuses energy in a specific direction. Gain is a key component of the EIRP calculation, but it is not the calculation itself.

References:

Cisco Wireless Design Guide: "EIRP is the actual radiated power from the antenna and is calculated as transmit power minus cable loss plus antenna gain"

FCC Regulations: "EIRP is the standard measurement for radiated power in wireless systems"

Explanation:

In the Cisco Catalyst SD-WAN architecture, vSmart serves as the centralized control plane controller for the overlay network . Its primary role is to manage and distribute critical information that keeps the fabric operational.

One of its key functions is the distribution of IPsec keys, which are essential for securing the data plane tunnels between WAN Edge routers . Beyond key distribution, vSmart also acts as a route reflector, a central policy engine, and is responsible for dynamically distributing routing information (via OMP) and policies across the network .

Why other options are incorrect:

A. facilitation of NAT detection and traversal:
This is the primary function of the vBond orchestrator, not vSmart. vBond handles the initial authentication and NAT discovery for edge routers joining the network .

B. redistribution between OMP and other routing protocols: While OMP carries routes from protocols like BGP and OSPF, the actual redistribution of these routes into OMP is configured locally on the WAN Edge routers through route policies, not performed centrally by vSmart .

D. execution of localized policies:
This task belongs to the WAN Edge routers (vEdge/cEdge). Localized policies, which affect routing and data flow at the local site, are provisioned on the edge devices themselves, either via CLI or vManage templates . In contrast, vSmart provisions and enforces centralized policies that affect the entire overlay network .

References:

Cisco Catalyst IR1800 Configuration Guide: "vSmart is the control plane... acts as the route reflector, key reflector, and policy engine"

Cisco SD-WAN Migration Guide: "vSmart provides... dynamic distribution of routing information, encryption keys and policies"

Explanation:

In a Cisco Mobility Express wireless deployment, when the primary AP (which runs the virtual controller function) fails, the selection of a new primary AP is determined by an automatic election process . This process is based on Virtual Router Redundancy Protocol (VRRP) and evaluates eligible APs according to a specific order of precedence .

Why other options are incorrect:

A. AP with highest IP address:
IP address is not used as a selection criterion in the primary AP election algorithm. Neither IP address nor IP address order is referenced in Cisco's documentation for this process.

B. AP with the lowest IP address:
Similarly, IP address plays no role in the election. The algorithm is based on controller uptime, VRRP configuration, client load, and MAC address.

C. AP with the highest MAC address:
This is the opposite of the correct MAC address logic. The election process uses the lowest MAC address as the final tie-breaker among APs with equal client load . The highest MAC address is never used.

References:

Cisco Mobility Express User Guide, Release 8.10: "The AP with highest controller up-time compared to other Cisco Mobility Express-capable APs"

Cisco Mobility Express Deployment Guide: "Lowest MAC Address – If all of the Access Points are the same and have the same client load, then Access Point with the lowest MAC will be elected"

Explanation:

Ansible is an open-source automation tool used for configuration management, application deployment, and orchestration. It operates on a push model, meaning the control node initiates communication and pushes changes to managed hosts via SSH or WinRM—no agent software needs to be installed on target devices . Playbooks are written in YAML, but Ansible is built on Python, and its modules can also be developed in Python or Ruby .

Why other options are incorrect:

A. Puppet:
Uses a pull model. The agent on each node periodically checks the master server for updates and applies them . This requires an agent to be installed on every managed host .

C. SaltStack:
Can support push via its master-minion architecture, but requires minion agents to be installed on managed nodes for full functionality . It does have an agentless salt-ssh mode, but agentless operation is not its default.

D. Chef:
Traditionally uses a pull model with an agent on each node . Chef requires the Chef Client agent to be installed, though an agentless mode is available as a newer option .

References:

Cisco DevNet Documentation: "Ansible is a good example of an agent-less configuration management tool"

Educative: "Ansible is agentless and push-based, connects to hosts via SSH, requires no client-side agent"

Explanation:

The API response is a Python dictionary containing a key 'response' that holds the list of VLAN names, along with a 'version' key for metadata.

To access the list of VLANs, you need to reference the dictionary using the key 'response'. The correct syntax for accessing a value in a Python dictionary is dictionary_name[key], which in this case is VlanNames['response']. This will return the list ['Vlan1', 'Vlan2', ...].

Why other options are incorrect:

A. VlanNames(0): This uses parentheses, which is the syntax for calling a function, not indexing a dictionary. It would result in a TypeError: 'dict' object is not callable.

B. VlanName['Vlan1']: This is missing the s in VlanNames (the variable name), and it tries to use a VLAN name as a key. The actual dictionary keys are 'response' and 'version', not individual VLAN names.

D. list(VlanNames):
The list() function would convert the dictionary's keys into a list, not the values. This would return ['response', 'version'], which is not the list of VLAN names.

References:

Python Official Documentation: "Dictionary values are accessed using square brackets with the key, e.g., dict['key']"

Cisco DNA Center API Documentation: The /vlan/vlan-names endpoint returns a JSON object with a response array containing VLAN names

Explanation:

FastLocate is a Cisco Wi-Fi location technology designed to improve the refresh rate of location-based services (LBS) by collecting RSSI (Received Signal Strength Indication) or location information from data packets rather than relying solely on probe requests .

Traditional Wi-Fi location tracking relies on mobile devices sending probe request messages to Access Points (APs). However, Wi-Fi clients are increasingly probing less frequently to conserve battery life, with intervals varying anywhere from 10 seconds to 5 minutes depending on the client, operating system, driver, and activity . This results in inadequate data points to represent real-world movement accurately .

FastLocate overcomes this limitation by using the more frequent data packets—rather than relying solely on probe requests—to collect RSSI data . Since data packets are more frequent than probe request packets, they can be aggregated better, enabling higher location refresh rates . When FastLocate is enabled, APs collect RSSI data from data packets sent by both associated and unassociated clients, and forward this information to the controller via CAPWAP .

Why other options are incorrect:

A. RFID:
RFID (Radio-Frequency Identification) is a separate technology for asset tracking using active RFID tags that emit frames captured by APs . This is a different location solution for tagged assets, not the method used by FastLocate.

B. client probing:
Probe requests are the traditional method used for location tracking (often called Probe RSSI) before FastLocate. FastLocate was introduced specifically to overcome the limitations of probe-based location by supplementing it with data packets .

C. beacons:
Beacons refer to Bluetooth Low Energy (BLE) beacon broadcasts used in Cisco Hyperlocation solutions. While Cisco Spaces uses FastLocate to improve location refresh rates, beacons are a separate technology for proximity-based services.

References:

Cisco Catalyst 9800 Configuration Guide: "FastLocate enables higher location refresh rates by collecting RSSI or location information through data packets received by the APs"

CMX FastLocate Deployment Guide: "With FastLocate, we add the capability to get RSSI/Location information using data packets received by the AP"