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

Explanation:

A VXLAN Tunnel Endpoint (VTEP) requires a VXLAN Network Identifier (VNI) to operate . The VNI is a fundamental component of the VXLAN protocol, serving as a 24-bit identifier that uniquely distinguishes different overlay networks or segments . A VTEP encapsulates and decapsulates VXLAN packets; it needs the VNI to determine which virtual network traffic belongs to and ensure proper forwarding between endpoints across the Layer 3 underlay network .

Why other options are incorrect:

A. a VXLAN tunnel endpoint identifier – The VTEP is identified by its IP address and configured VNI; there is no separate "VTEP identifier" required. The VTEP's identity is provided by its source IP address .

B. at least one Layer 2 interface and one Layer 3 interface – A VTEP does not strictly require both types of interfaces simultaneously. While a source interface (typically a loopback) and a transport interface are needed, the architecture focuses on the overlay and underlay distinction rather than requiring both Layer 2 and Layer 3 interfaces on the same device .

C. at least one IP for the transit network and one IP for endpoint connectivity – This describes a general networking requirement, not a specific VXLAN requirement. The VTEP's core function is to map VNIs to overlay segments and forward traffic using its configured source IP, not to require multiple IP addresses for different purposes .

🔗 References:

Debian Manpages (ifupdown-ng): "A VXLAN Virtual Tunnel Endpoint (VTEP) interface must an ID set" .

Extreme Networks VOSS Guide: VNID allows up to 16 million VXLAN segments and each VTEP can support multiple VNIDs .

Explanation:

To make Router A become the active VRRP router, its priority must exceed that of Router B (which currently holds a priority of 110), or Router A must become the owner of the virtual IP address.

Option E (vrrp 1 priority 120): By default, Router A has a priority of 100, while Router B has 110. Increasing Router A's priority to 120 ensures it is higher than Router B's priority (120 > 110), triggering an election where Router A becomes the active master router.

Option D (ip address 10.1.0.11 255.0.0.0): In VRRP, the router that owns the primary IP address associated with the virtual router (the IP address owner) automatically assumes a priority of 255, which is the highest possible priority. Since Router B's virtual IP configuration uses 10.1.0.11, changing Router A's physical interface address to 10.1.0.11 makes it the address owner, immediately making it active.

Why Other Options Are Incorrect:

A. vrrp 1 priority 90: Lowering Router A's priority to 90 further reduces its chances of becoming active, as it remains well below Router B's priority of 110.

B. vrrp 1 timers advertise 1: Changing the advertisement timer interval affects how frequently hello messages are sent, but timers play no role in determining which router wins the active master election.

C. vrrp lip 10.1.0.11: This command is syntactically invalid in Cisco IOS for configuring VRRP.

References:

Cisco IOS IP Addressing Services Configuration Guide: Configuring VRRP (Virtual Router Redundancy Protocol) — Explains priority mechanics and IP address ownership.

Cisco 350-401 ENCOR Exam Topics: Section 3.0 Infrastructure — Topic 3.1 Configure and verify First Hop Redundancy Protocols (HSRP, VRRP).

✅ Explanation:

VXLAN is the data plane encapsulation protocol that creates the overlay network in SD-Access. The responsibility for performing this encapsulation and decapsulation lies with specific fabric roles:

Edge Nodes: These are the access layer switches where endpoints (such as PCs, phones, printers, and Access Points) connect to the network. Edge Nodes are responsible for endpoint registration and, crucially, for VXLAN encapsulation and decapsulation of traffic to and from these endpoints. In the case of fabric-enabled wireless, a VXLAN tunnel called an "access-tunnel" is established directly between the Access Point and the Edge Node to carry client traffic.

Border Nodes: These nodes are the gateway between the SD-Access fabric and external networks (e.g., data centers, WAN, internet). They also perform VXLAN encapsulation and decapsulation on traffic entering or leaving the fabric. This ensures seamless policy enforcement and segmentation as traffic moves in and out of the overlay.

Why other options are incorrect:

A. core nodes – "Core" is a traditional networking layer, not a distinct SD-Access node type. In SD-Access, the core function is often integrated with the distribution layer in a collapsed design. These nodes do not directly participate in VXLAN encapsulation.

B. distribution nodes – Distribution is another traditional layer, not a standard SD-Access role. In a typical SD-Access design, the distribution layer is collapsed with either the core or border layer, and its primary role is to provide Layer 3 connectivity in the underlay, not to perform VXLAN tunneling.

D. aggregation nodes – This is not a role defined in the SD-Access architecture. It is a term from traditional campus networking and is not used to describe nodes that handle VXLAN encapsulation.

🔗 References:

Cisco SD-Access Solution Design Guide: Confirms Edge Nodes perform VXLAN encapsulation/decapsulation. Border Nodes perform VXLAN encapsulation and decapsulation.

Understand Access Tunnel Creation in SD-Access: Documents VXLAN tunnels (access-tunnels) between Edge Nodes and Access Points.

Explanation:

Northbound APIs allow external software, automation scripts, and orchestration systems to interact with network controllers like Cisco Catalyst Center (formerly Cisco DNA Center) and Cisco SD-WAN vManage.

JSON Format (Option B):
Both Cisco DNA Center Intent APIs and vManage Northbound APIs are designed primarily around REST architecture using JavaScript Object Notation (JSON) as the primary data exchange payload format for HTTP GET, POST, PUT, and DELETE requests.

REST / RESTCONF Protocols (Option C):
Northbound controller APIs primarily expose RESTful interfaces over HTTPS. Certain Cisco controller management interfaces also support RESTCONF (RFC 8040) interfaces to access YANG data models programmatically over HTTP/HTTPS.

Why Other Options Are Incorrect:

A. They exchange XML-formatted content: While some legacy or southbound interfaces support XML, Northbound APIs on Catalyst Center and vManage rely almost exclusively on JSON payloads for lightweight data exchange.

D. They implement the NETCONF protocol: NETCONF is used as a Southbound API (communicating down from controllers like vManage to managed network devices/vEdges using SSH and XML), not as a Northbound API.

E. They exchange protobuf-formatted content: Protocol Buffers (protobuf) are typically used for Model-Driven Telemetry (MDT) encoding rather than standard Northbound REST controller APIs.

References:

Cisco DNA Center Platform User Guide: Intent APIs (Northbound RESTful APIs utilizing HTTPS and JSON).

Cisco SD-WAN (vManage) Architecture Guide: vManage REST APIs and Protocol Standards.

✅ Explanation:

The data shows two people, each with a first name, last name, and a list of hobbies. In JSON, an array of objects is represented with square brackets [] containing objects enclosed in curly braces {}. String values must be enclosed in double quotes " ". Object keys must also be in double quotes. Arrays of strings are represented with square brackets.

Why the other options are incorrect:

B. Option B:
The Hobbies values are not enclosed as an array; they are listed as separate key-value pairs with the same key name (Hobbies).
JSON keys must be unique within an object. Repeating the same key is invalid and would overwrite the previous value.
Some string values are missing closing double quotes.

C. Option C:
This option has multiple syntax errors, including missing closing quotes and missing commas.
The Hobbies values are not enclosed as arrays, and the string values are not properly quoted.
It does not correctly represent the list structure of hobbies.

D. Option D:
This contains the same errors as Options B and C.
The Hobbies values are not represented as arrays.
String values are missing proper quotes, making it invalid JSON.

🔗 References:

JSON (JavaScript Object Notation) Specification (RFC 8259): States that JSON is built on two structures: a collection of name/value pairs (object) and an ordered list of values (array).

JSON.org: Keys must be strings in double quotes; values can be strings, numbers, objects, arrays, booleans, or null.

Explanation:

MAB is specifically designed for legacy devices or endpoints that are not 802.1X-capable. When a device connects to a port configured for 802.1X, the switch first attempts 802.1X authentication. If it determines the host does not support 802.1X (e.g., no EAPoL (Extensible Authentication Protocol over LAN) response is received), it falls back to MAB. The switch then uses the device's MAC address as the username and password to query a RADIUS server. The server checks its database to see if the MAC address is authorized; if it is, the port is opened for network access.

Why other options are incorrect:

B. when the attached host supports 802.1X and must authenticate itself based on its MAC address instead of user credentials:This is incorrect. If a host supports 802.1X, it should authenticate using its credentials (like a username/password or certificate) via EAP, not using MAC authentication. MAB is a fallback for non-802.1X devices.

C. when authentication should be bypassed for select hosts based on their MAC address: This is incorrect. Bypassing authentication is not what MAB does. MAB still performs authentication, just using the MAC address as the credential. To truly bypass security, you would configure a port for "auto" or configure an exception, not MAB.

D. when the attached host supports limited 802.1X:This is incorrect. MAB is not for hosts that support 802.1X, even if the support is limited. If a host supports 802.1X, it should use that method. MAB is specifically for hosts that have no 802.1X capability at all. It is considered a fallback authentication method for non-supplicant devices.

References:

Cisco 802.1X Configuration Guide: MAB is used to authenticate hosts that do not have 802.1X supplicant software. The switch uses the MAC address to authenticate the host via RADIUS.

Cisco Identity Services Engine Guide: Defines MAB as a method to authenticate devices that do not support 802.1X, such as printers, IP phones, or legacy devices.

✅ Explanation:

Cisco's official documentation explicitly lists Cisco Express Forwarding (CEF) and IP routing as a prerequisite for deploying BFD on all participating routers and switches . BFD relies on CEF to efficiently forward the rapid detection packets and IP routing to establish the necessary forwarding path context. Without these enabled, BFD cannot operate. CEF provides the forwarding infrastructure, while IP routing establishes the foundation for the routing protocols that BFD supports.

Why other options are incorrect:

A. BFD requires a FHRP to provide subsecond host failover.
Incorrect. BFD can operate independently to detect forwarding path failures for routing protocols like OSPF, EIGRP, or BGP without any FHRP configured . While BFD can be integrated with HSRP to accelerate failover, this is an optional application, not a prerequisite .

B. BFD can be deployed without any IP routing protocols being configured.
Incorrect. The prerequisites require that "one of the IP routing protocols supported by BFD must be configured on the routers before BFD is deployed" . BFD is designed to complement routing protocols by providing fast failure detection; it is not typically deployed in isolation.

C. NSF and graceful restart must be enabled on all participating routers.
Incorrect. NSF and graceful restart are optional high-availability features that can work with BFD but are not prerequisites . In fact, Cisco warns that configuring both BFD and BGP graceful restart may result in suboptimal routing, indicating these features can be conflicting rather than required .

🔗 References:

Cisco IOS IP Routing Configuration Guide: "Cisco Express Forwarding and IP routing must be enabled on all participating routers" .

Cisco Catalyst Switch Configuration Guide: "All participating switches must enable Cisco Express Forwarding and IP routing" .

✅ Explanation:

A collision domain in Wi-Fi defines the set of devices that must contend for the same wireless medium (airtime). All devices operating on the same channel and within range of each other share this domain . Because Wi-Fi is a shared, half-duplex medium, they must compete to transmit using CSMA/CA, and cannot detect collisions directly—they rely on acknowledgements to confirm successful reception . By contrast, devices on non-overlapping channels operate in separate collision domains, enabling spatial reuse and increased capacity .

Why other options are incorrect:

A. The 2.4-GHz band has 24 non-overlapping channels: The 2.4 GHz band has only 3 non-overlapping channels (1, 6, and 11) in North America due to severe spectral overlap .

C. Wi-Fi channels are spaced 30 MHz apart: Wi-Fi channels in both 2.4 GHz and 5 GHz bands are spaced 5 MHz apart . The 20/22 MHz channel width causes adjacent-channel overlap .

D. The 5-GHz band offers 11 different channels for Wi-Fi clients: The 5 GHz band offers up to 25 non-overlapping 20 MHz channels, far more than 11 .

🔗 References

HPE Aruba Theory Guide: Defines collision domains and medium contention in 802.11 networks .
Aerohive High-Density Wi-Fi Design Guide: Explains channel planning, non-overlapping channels, and collision domains .

✅ Explanation:

This classification is a fundamental distinction in configuration management:

Procedural (Imperative) Tools – You write scripts or code that describe the exact steps to execute in order to reach a desired state. Chef is a procedural tool where you define recipes that instruct the system on how to install, configure, and manage services, step-by-step, using an imperative programming style.

Declarative Tools – You define the desired configuration (the "what"), and the tool determines the necessary steps (the "how") to achieve that state. Puppet uses a declarative language where you specify the desired resources and attributes. SaltStack is also declarative, using state files to define the desired configuration, though it also supports some imperative execution.

References

Red Hat White Paper: "Puppet and SaltStack are declarative, while Chef is procedural"

Puppet and Chef Documentation: Contrasts declarative vs procedural configuration management

IAC Tools Cheat Sheet: Lists Chef as procedural, Puppet and SaltStack as declarative

✅ Explanation:

HTTPS (Hypertext Transfer Protocol Secure) uses TLS (Transport Layer Security) to encrypt the entire communication channel between the client and the server. This ensures that sensitive data, such as authentication credentials and API keys, are protected from interception and tampering while in transit, providing privacy and integrity.

Encryption in transit is a foundational and widely recognized security practice for any web API. It is often complemented by other security measures like authentication and authorization.

Why other options are incorrect:

A. using an MD5 hash to verify the integrity
MD5 is a broken, cryptographically insecure hashing algorithm. It should not be used for any security-sensitive purpose, including verifying API integrity.

B. using built-in protocols known as Web Services Security
Web Services Security (WS-Security) is a standard associated with SOAP web services, not REST APIs. REST APIs typically rely on simpler mechanisms like OAuth, API keys, and JWT.

D. using a combination of XML encryption and XML signatures
XML encryption and XML signatures are also part of the WS-Security standard for SOAP, not REST. REST APIs typically use JSON as their primary data format and rely on HTTPS for transport security.

🔗 References

Microsoft Learn: Highlights "HTTPS by default" as a key feature, emphasizing end-to-end encryption to ensure privacy and prevent interception.

TechTarget: Lists "Secure" as a benefit of REST APIs, mentioning OAuth and SSL/TLS encryption.