Free 350-401 Practice Test Questions 2026

✅ Explanation:

Sticky clients occur when a wireless client remains connected to an AP with a weak signal instead of roaming to a better AP, often due to asymmetric transmit power or mismatched data rate settings. By increasing the mandatory minimum data rates, you prevent clients from using the lowest, most robust data rates (like 1, 2, 5.5, and 6 Mbps) for management and data frames. This effectively shrinks the usable range of each AP, encouraging clients to roam to a stronger AP sooner.

This is a fundamental RF design principle:
Lower mandatory data rates extend the physical coverage cell of an AP.
Higher mandatory data rates reduce the coverage cell size, improving the overall spectral efficiency .
By forcing clients to only associate if they can support higher data rates, you reduce the incidence of sticky clients and improve the overall performance of dense RF environments.

Why other options are incorrect:

A. Decrease radio channel widths to 40 MHz:
Reducing channel width improves signal quality and reduces interference at the cost of throughput; it does not directly address sticky clients, which are caused by clients choosing not to roam to better APs, not by channel width.

C. Decrease the mandatory minimum data rates:
This would extend the cell range, encouraging clients to associate with the AP from a greater distance and reducing their likelihood of roaming to a better AP. This would worsen the sticky client problem.

D. Increase radio channel widths to 160 MHz:
Wider channels increase throughput but reduce the received signal strength at the client and make the network more susceptible to interference . This does not address the root cause of sticky clients and can actually degrade the client experience.

🔗 References

Cisco Wi-Fi Design Guide: Sticky clients can be minimized by tuning data rates, specifically by setting mandatory data rates appropriately .

Cisco Community Discussion:
Explains that setting 12 Mbps as the minimum mandatory rate can help prevent sticky clients .

✅ Explanation:

Data models facilitate a unified approach to configuration and management in a multivendor environment. They provide a vendor-neutral way to define network configurations, enabling organizations to manage diverse devices with consistent tools and processes. This reduces complexity and promotes interoperability. For instance, protocols like NETCONF and RESTCONF use data models (e.g., YANG) to enable a single management platform to configure devices from different vendors using a standardized, programmatic interface . This approach reduces network faults caused by manual configuration errors . As a result, management systems can discover capabilities of devices from different vendors and adjust their behavior accordingly .

Why other options are incorrect:

B. improving communication security with binary-encoded protocols:
This is incorrect. Data models standardize the structure of data, not how it is communicated. Communication security (confidentiality and integrity) is handled by transport protocols like SSH or TLS, which are used by NETCONF and RESTCONF . Data models themselves do not rely on binary encoding for security.
C. lowering CPU load incurred to managed devices:
This is incorrect. Data models do not directly lower CPU load. They describe what data is available and its format. While structured data may enable more efficient interactions, the primary benefit is interoperability and standardized management, not CPU load reduction.

D. removing the distinction between configuration and runtime state data:
This is incorrect. Data models define the structure and constraints for configuration data as well as state data, but they do not remove the distinction between them. Both types of data coexist in a device's data model, representing "desired" vs. "actual" states .

🔗 References:

NETCONF Overview: NETCONF uses XML and RPC mechanisms to manage devices .

Benefits of NETCONF: Facilitates configuration data management and interoperability between different vendors' devices .

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

JWTs are encoded, not encrypted by default. The token consists of three parts: a header, a payload, and a signature, each separated by a dot .. The header and payload are Base64Url-encoded JSON objects . This encoding makes the token compact and URL-safe for transmission in HTTP headers.

The purpose of a JWT is to securely exchange information between the client and server. The signature (created using a secret or private key) allows the receiver to validate that the content has not been tampered with . This makes JWTs suitable for both authentication (proving who the user is) and information exchange (securely sharing claims between parties) .

Why other options are incorrect:

A. an encrypted JSON token that is used for authentication
– JWTs are encoded and signed, but not necessarily encrypted. The payload is Base64Url-encoded, which is not encryption (it can be easily decoded). While JWT can be encrypted (using JWE), the standard format is signed, not encrypted . Additionally, JWTs can be used for both authentication and information exchange.

B. an encrypted JSON token that is used for authorization
– Same encryption inaccuracy as Option A, and authorization is a separate process from authentication. JWTs primarily facilitate authentication (verifying identity) or secure information exchange, not directly authorization (granting permissions) .

D. an encoded JSON token that is used for authentication
– This option is partially correct (JWTs are encoded) but incomplete. The full definition of a JWT is a token for securely exchanging information, which includes but is not limited to authentication. JWTs can carry any claims, not just authentication credentials.

🔗 References:

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

Visa Acceptance Solutions JWT Guide: "JWTs provide a compact, self-contained method for securely transmitting information between parties" .

✅ Explanation:

The XML response shown is:
This is a standard NETCONF that contains an empty element. When a NETCONF operation (such as or ) returns an empty element, it indicates that the request was syntactically valid and the server processed it, but the requested data was not available or the request yielded no content.

This typically occurs when:
The requested YANG data model path does not exist on the device (the request was valid but the model is unsupported)
The requested configuration or state data is empty (not configured)
The request was well-formed but the device had no data to return

Therefore, the message indicates a valid NETCONF message with valid content based on the YANG data models was made, but the request failed to return the expected data.

Why other options are incorrect:

A. A NETCONF request was made for a data model that does not exist.
– This is a possible scenario, but the response does not specifically indicate a non-existent model. The XML shows a valid reply with an empty data tag, which is the standard NETCONF response for a valid request that returns no data.

B. The device received a valid NETCONF request and serviced it without error.
– While the request was valid and the device serviced it, the presence of an empty tag suggests the request failed to retrieve the expected data. The response indicates no data was found.

D. The NETCONF running datastore is currently locked.
– A locked datastore would return an with an error-tag of "lock-denied" or similar, not an empty element. The response shows no error tags.

🔗 References

RFC 6241 (NETCONF Protocol): Defines the element as the container for configuration or state data in messages.

NETCONF Error Handling: Locked datastore errors are returned as elements, not empty containers.

✅ Explanation:

The response shows a status code of 202 (Accepted), which indicates that the POST request was accepted for processing, but the processing was not completed at the time of the original request. This is expected for asynchronous tasks in Cisco DNA Center.

When querying for more information about the task, the response body reveals:
"isError": false – This explicitly indicates that no error occurred.
"progress": "1" – This represents 100% completion (1 means "completed" in the context of Cisco DNA Center APIs).
"version": 1630851541514 – This timestamp suggests the task has been processed and finalized.
The absence of any error indicators, along with the "progress": "1" field, confirms that the discovery task was completed successfully.

Why other options are incorrect:

A. restarted
– There is no indication in the response that the task was restarted. The isError field is false, and the progress field shows "1", indicating successful completion rather than a restarted state.

B. failed
– The isError field is explicitly set to false, which directly rules out a failure. If the task had failed, this field would be true, and additional error details would likely be included.

C. stopped
– There is no evidence of the task being stopped or interrupted. A stopped task would typically show an error state or incomplete progress (e.g., "0" for progress), neither of which is present in the response.

🔗 References:

Cisco DNA Center Platform API Guide: Defines the response structure for asynchronous tasks, including the isError and progress fields.

HTTP Status Codes: A 202 status code indicates the request was accepted for processing, and subsequent queries should check the task progress.

Explanation:

A key characteristic of an AP operating in FlexConnect mode is that FlexConnect groups are required to support 802.11r fast roaming. FlexConnect groups are logical groupings of FlexConnect APs that share the same VLAN and controller configuration, enabling local authentication and fast roaming features. For 802.11r (Fast Transition) to function, FlexConnect APs must belong to a FlexConnect group. This ensures client information (such as security keys) is shared between the APs in the group, allowing for a seamless transition when a client roams between them.

Why other options are incorrect:

A. Configuration is done directly on the AP rather than on a controller.
Incorrect. FlexConnect APs are lightweight APs that are configured and managed centrally by the WLC. Configuration is pushed from the controller, not applied directly to the AP.

B. Dot1x authentication is not supported for AP clients in this mode.
Incorrect. Dot1x authentication is supported for clients in FlexConnect mode. Authentication can be handled centrally by the controller or locally by the AP (when in standalone mode with a RADIUS server).

C. Client authentication is always performed on the AP.
Incorrect. Client authentication depends on the mode: in connected mode, the controller handles authentication; in standalone mode, the AP can perform local authentication, but this is not the default.

🔗 References:

Cisco FlexConnect Configuration Guide: FlexConnect groups are required for Fast Transition (802.11r) support.

Cisco FlexConnect Overview: FlexConnect APs are centrally managed by a WLC; groups enable fast roaming features like CCKM and 802.11r.

✅ Explanation:

A virtual link is used when an area cannot be physically connected to the backbone area (Area 0), which is a requirement in OSPF . It creates a logical link between two Area Border Routers (ABRs) through a transit area, enabling the disconnected area to reach Area 0 . The transit area must be a non-backbone area and cannot be a stub or NSSA .

Why other options are incorrect:

A. to allow a stub area to transit another stub area: A transit area cannot be a stub area, as stub areas don't carry external routes . Virtual links also don't allow stub areas to transit traffic.

B. to merge two existing Area 0s through a nonbackbone: This is not a recommended use case. OSPF requires a single backbone area, and virtual links cannot merge two separate Area 0s.

C. to connect two networks that have overlapping private IP address space: Virtual links do not address overlapping IP address spaces. This is typically resolved through NAT or VRF technologies.

🔗 References:

Huawei CloudEngine Configuration Guide: Virtual links connect non-backbone areas to Area 0

Extreme Networks Documentation: Virtual links connect ABRs through a transit area to the backbone

Explanation:

YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls (RPCs), and notifications for network management protocols . It defines a hierarchical data structure that provides a complete description of all data exchanged between a client and server , enabling network programmability and is transported over protocols such as NETCONF and RESTCONF .

YANG's purpose is to describe the structure, syntax, and semantics of data, not the transport mechanism itself. This allows network devices from different vendors to be managed using a standardized, machine-readable format.

Why other options are incorrect:

A. scraping data via CLI:
YANG is a structured, machine-to-machine interface. It is designed to provide programmatic access to data via protocols like NETCONF, not for screen scraping or parsing command-line output.



B. processing SNMP read-only polls:
YANG is independent of and not reliant on SNMP. It uses its own transport protocols (NETCONF, RESTCONF) and is a separate management framework.

D. providing a transport for network configuration data between client and server:
YANG defines the data model (the structure and meaning of the data), while protocols like NETCONF and RESTCONF provide the transport mechanism . The transport layer is separate from the data modeling language.

🔗 References:

YANG Definition: "YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols" .

YANG and NETCONF: YANG provides the data model; NETCONF is the protocol that transports the operations .

Explanation:

FlexConnect (formerly known as H-REAP or Hybrid Remote Edge Access Point) is a Cisco wireless deployment mode specifically designed for branch offices or remote locations.

Local Switching:In FlexConnect local switching mode, the Access Point drops off (egresses) client data traffic locally directly onto the access point's switch port, bypassing the Wireless LAN Controller (WLC).

Control vs. Data Traffic: While CAPWAP control traffic is maintained back to the centralized WLC, user data plane traffic is processed and switched locally at the AP interface.

Why Other Options Are Incorrect:

A. Bridge:
Used primarily for wireless point-to-point or point-to-multipoint mesh bridging between buildings, rather than standard client access egress at a switch port.

B. Sniffer:
Dedicated mode where the AP acts as a remote packet capture device, capturing over-the-air wireless traffic on a specific channel and forwarding it to a network analyzer (like Wireshark). It does not service or switch wireless client traffic.

D. Monitor:
Dedicated mode where the AP does not process or transmit client traffic; instead, it acts as a sensor for Rogue AP Detection, Location Tracking, and Wireless Intrusion Prevention System (WIPS).

References:

Cisco FlexConnect Configuration Guide: FlexConnect Local Switching vs. Central Switching Architecture.

Cisco 350-401 ENCOR Exam Topics: Section 2.0 Infrastructure — Topic 2.2 Describe wireless deployment modes (Centralized, FlexConnect, Mesh).

✅ Explanation:

JSON (JavaScript Object Notation) is a lightweight, text-based data-interchange format that is widely used for API requests, particularly for RESTful web services . It represents data as key-value pairs and supports arrays, making it both human-readable and machine-parseable . JSON's simplicity, compactness, and language-independent nature make it the preferred choice for API requests, especially in modern web and mobile applications .

Why other options are incorrect:

A. HTML
– HTML (HyperText Markup Language) is a markup language used for structuring and displaying content in web browsers. It is not a data format designed for API requests. APIs typically send and receive data in JSON or XML, not HTML.

B. PERL
– Perl is a programming language, not a data format. APIs use data formats (JSON, XML, etc.) for structuring information, not programming languages.

D. Python
– Python is a programming language, not a data format. APIs are language-agnostic and use standard data formats for request and response payloads.

🔗 References:

JSON is the standard data format for REST APIs.
HTML is for web page display; JSON is for data exchange.
APIs support JSON, XML, and other formats—not programming languages like Python or Perl.

Explanation:

The Intent API provides a policy-based abstraction of business intent, allowing you to focus on the desired outcome rather than the individual steps required to achieve it. It is a Northbound REST API that uses standard HTTPS methods (GET, POST, PUT, DELETE) with JSON data structures. This abstraction hides the underlying complexity of device-level configurations, allowing you to declare business goals—such as "provide connectivity for device X with policy Y"—while Catalyst Center handles the device-level implementations automatically.

Why other options are incorrect:

B. southbound consumer-facing RESTful API
– Southbound APIs are used for communication from the controller to network devices (e.g., NETCONF, RESTCONF, SNMP) to push configurations and collect telemetry. They are not consumer-facing nor do they focus on business outcomes .

C. interface between the controller and the network devices – This describes the southbound interface, which handles device-level communication, not the intent-based northbound API.

D. westbound interface
– While Catalyst Center may support integrations with external systems like ITSM or IPAM, these are not classified as "westbound." East/westbound interfaces typically facilitate communication between peer controllers or external IT systems .

References:

Cisco DevNet: Intent APIs provide policy-based abstraction of business intent
Cisco Platform User Guide:Intent APIs are Northbound REST APIs that exchange JSON