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

Explanation:

The provided Python code contains two fatal syntax errors that prevent execution:

Missing format string: The line .{format(key,str(value))} has no string literal before the dot operator. The .format() method must be called on a valid string object (e.g., '{}'.format()). Without a base string, Python raises a SyntaxError.

Unbalanced braces: The dictionary txt has two opening braces { but only one closing brace }. This mismatched bracket causes another SyntaxError.

Because the interpreter cannot parse the code, no output is generated. The script terminates immediately with an error message, so none of the visual outputs (Options A–D) can appear.

Why Other Options Are Incorrect:

Option A assumes the code truncates the value to the first 10 characters (6452987918) and left-pads the key with #. This logic would require '{:#<15}'.format(key[:10]) or similar slicing—not present.

Option B assumes the code takes the last 10 characters of the value (8791871446) and incorrectly wraps the second key. There is no slicing or negative indexing in the snippet.

Option C assumes the code prints the full value without truncation and adds ## padding. However, the code never applies any formatting to the value itself—only the key is referenced in the format placeholder.

Option D assumes the code prints only the values, omitting keys entirely. This contradicts the for key, value in args_dict.items() loop, which clearly iterates over both.

All four options are speculative interpretations of intended formatting behavior, but the actual code is not syntactically valid—making all of them incorrect.

References:

Python Official Documentation – str.format(): States that the method must be called on a format string containing replacement fields.

Explanation:

To allow the network administrator to authenticate via RADIUS when accessing router R1, the required commands are:

text
aaa new-model
aaa authentication login default group radius

aaa new-model globally enables Authentication, Authorization, and Accounting (AAA) on the Cisco IOS device. This is the mandatory first step for any AAA configuration.

aaa authentication login default group radius creates a default authentication method list for login (console, VTY, and auxiliary lines). The keyword default means this method list is automatically applied to all lines that do not have a custom authentication list. The group radius directive instructs the router to query the RADIUS server first for authentication. If the RADIUS server is unreachable or returns an error (e.g., no response), the router will fall back to the local database (if configured) because the local keyword is implicitly added at the end when no fallback is specified. However, in this scenario, the primary mechanism is RADIUS, which matches the requirement of authenticating via the RADIUS server shown in the topology (10.0.2.4).

After these commands, you must also configure the RADIUS server details globally (e.g., radius-server host 10.0.2.4 key ), but those are not listed in the options.

Why Other Options Are Incorrect:

Option B: aaa authentication login console is incomplete. The console keyword is used to define a named authentication list for console lines, but this command lacks the method list (e.g., group radius or local). It also does not apply to VTY lines, which network administrators typically use for remote access. This command would not achieve RADIUS authentication.

Option C: aaa authentication login default is incomplete. It specifies the default authentication list but does not define any authentication methods (e.g., group radius or local). Without methods, the router has no instruction on how to authenticate users, so login attempts would fail.

Option D: aaa authorization exec default group radius is incorrect because it deals with authorization (determining what a user can do after authentication), not authentication (verifying identity). This command would control whether an authenticated user is allowed to execute an EXEC shell, but it does not perform the initial username/password verification against RADIUS.

References:

Cisco IOS Security Configuration Guide – AAA Authentication: States that aaa authentication login default group radius configures the default login authentication method list using RADIUS.

Explanation:

Cisco SD-Access is a fabric-based architecture that separates network functions into distinct planes to enable automation, segmentation, and host mobility. The data plane is responsible for forwarding user traffic across the overlay network. SD-Access uses VXLAN (Virtual Extensible LAN) as the data plane encapsulation protocol. VXLAN employs MAC-in-UDP encapsulation to carry original Layer 2 frames over a Layer 3 IP underlay network, providing up to 16 million VNIs (Virtual Network Identifiers) for network segmentation. This allows SD-Access to extend Layer 2 domains across the entire campus fabric without relying on traditional spanning-tree protocols. The control plane, in contrast, uses LISP (Locator/ID Separation Protocol) to map endpoint identifiers (EIDs) to routing locators (RLOCs), enabling seamless host mobility and endpoint tracking. Therefore, the characteristic that correctly applies to SD-Access is that VXLAN is used for the data plane.

Why the others are wrong:

A (Uses dynamic routing to discover and provision access switches):
This describes LAN Automation, a Cisco Catalyst Center feature that uses Plug-and-Play (PnP) and dynamic routing protocols to automatically onboard and configure underlay access switches. This is a management-plane function for underlay provisioning, not a characteristic of the SD-Access overlay architecture.

B (Uses VXLAN for the control plane):
This is incorrect because VXLAN is explicitly the data plane protocol. The control plane in SD-Access is handled by LISP, which manages endpoint-to-location mappings and facilitates host mobility. This option confuses the roles of the two protocols.

D (Uses dynamic routing to discover and provision border switches): Like Option A, this describes LAN Automation functionality related to underlay network provisioning. Border switches connect the SD-Access fabric to external networks (such as traditional VLANs or WANs), but their discovery and provisioning fall under management-plane automation, not a defining characteristic of the overlay control plane.

References:

Cisco SD-Access Solution Design Guide: "The control plane is based on LISP... the data plane is based on VXLAN"

Cisco Catalyst Center User Guide: "SD-Access fabric network based on LISP for control plane with VXLAN data plane"

Explanation:

REST API security best practices focus on protecting data in transit and credentials at rest.
SSL/TLS encryption (Option A) ensures all communication between the client and server is encrypted, preventing eavesdropping, man-in-the-middle attacks, and credential interception. Transport Layer Security (TLS) is the non-negotiable standard for any API exposed over the internet.
Password hashing (Option E) protects stored credentials by using one-way cryptographic algorithms such as bcrypt, Argon2, or PBKDF2. Hashing ensures that even if the database is compromised, plaintext passwords are not exposed, as the hash cannot be reversed to reveal the original password. These two measures—encryption in transit and hashing at rest—are foundational security controls recommended by OWASP and industry best practices for API security.

Why the others are wrong:

B (Enable out-of-band authentication):
Out-of-band (OOB) authentication involves verifying a user's identity through a separate communication channel, such as a push notification or SMS. While OOB can add an extra layer of security for user authentication flows, it is not a general best practice for securing REST APIs themselves. OOB is typically application-specific and not a universal requirement for API protection.

C (Enable dual authentication of the session):
This refers to verifying the session through two independent mechanisms, such as combining an API key with a JWT token. This is not a standard security best practice for REST APIs. The industry standard is to use a single, secure authentication method (e.g., OAuth 2.0 with bearer tokens) combined with HTTPS.

D (Use TACACS+ authentication):
TACACS+ is a Cisco proprietary protocol designed for network device administration (AAA). It is not a standard authentication method for REST APIs. REST APIs commonly use OAuth 2.0, OpenID Connect, API keys, or JWT tokens. TACACS+ is not applicable to API security.

References:

OWASP API Security Top 10 (2023): "Always enforce HTTPS/TLS for all API endpoints" and "Securely store passwords using strong hashing algorithms"

NIST Special Publication 800-63B: Recommends using salted hashing for stored passwords and TLS for encrypted communications

Explanation:

Data modeling languages, such as YANG, JSON Schema, and XML Schema Definition (XSD), provide a standardized way to define the structure, syntax, constraints, and hierarchy of data independent of any specific encoding format. A data model describes what data looks like—its data types, mandatory fields, ranges, relationships, and nesting—without specifying how that data is serialized on the wire. This separation of model from encoding is critical because the same YANG model, for example, can be encoded as XML (used by NETCONF), JSON (used by RESTCONF), or CBOR (used by CoAP), depending on the transport protocol or device capability. This abstraction enables multi-vendor interoperability, as network devices from different vendors can share the same data model (e.g., ietf-interfaces) while using different encoding formats. This is the foundation of model-driven programmability and network automation.

Why the others are wrong:

B (to specify algorithms necessary to decode binary-encoded protocol data units): This describes the function of encoding rules or codecs (e.g., how CBOR encodes data into binary). The data model defines structure; encoding rules define serialization and deserialization.

C (to translate encoded data for interoperability between different CPU architectures): This pertains to network byte order or endianness conversion, a low-level transport concern handled by protocols like TCP/IP, not by data modeling languages. Data models are completely agnostic to CPU architectures.

D (to provide a framework to describe data flow patterns in networks):
This describes data flow diagrams or traffic flow analysis, used in network design and monitoring. This is unrelated to data modeling languages, which focus on data structure, not traffic movement.

References:

RFC 7950 - YANG 1.1: "YANG is a data modeling language used to model configuration and state data... independent of the encoding format."

RFC 8040 - RESTCONF Protocol: "RESTCONF uses YANG data models and can encode data in XML or JSON."

Explanation:

In the Cisco SD-WAN architecture, vManage is the centralized network management system that provides a single pane of glass for configuration, monitoring, and troubleshooting . To interact with the fabric devices such as vEdge routers, cEdge routers, and vSmart controllers, vManage uses southbound APIs .

The term "southbound API" refers to the interface used by a controller or management system to communicate downward with the underlying network devices it manages. In this context, vManage communicates with fabric devices using protocols such as NETCONF, RESTCONF, and OMP (Overlay Management Protocol) over secure TLS/DTLS tunnels . This southbound communication allows vManage to push device configurations (via templates), deploy policies, collect telemetry and statistics, perform software upgrades, and monitor device health across the entire SD-WAN fabric .

The separation between southbound and northbound APIs is a fundamental concept in SDN architectures. Northbound APIs are used to communicate upward from the controller to external applications, orchestration systems, or the user interface, typically using REST APIs .

Why the others are wrong:

A (northbound API): This is used for communication from vManage to external applications or the GUI. While vManage does expose northbound REST APIs for programmatic access, these are not used to interact with the fabric devices themselves .

B (RESTCONF): RESTCONF is a specific protocol that vManage may use as part of its southbound communication, but it is not the general term for the interface. The question asks for what is used to interact with fabric devices, and "southbound API" is the correct architectural term .

D (IPsec): While IPsec is used in SD-WAN for secure data plane tunnels between WAN Edge routers, it is not the primary interface used by vManage to manage and configure fabric devices. vManage uses NETCONF/RESTCONF over TLS/DTLS for management plane communication .

References:

Cisco SD-WAN Architecture Documentation: Southbound APIs are used by controllers to communicate with network devices

Cisco Press - Cisco Catalyst SD-WAN Components: vManage provides configuration, monitoring, and troubleshooting via templates and policies

Explanation:

In LISP (Locator/ID Separation Protocol), when an Ingress Tunnel Router (ITR) needs to forward traffic to a destination but does not have the EID-to-RLOC mapping in its local map-cache, it sends a Map-Request to resolve the destination EID. The map resolver is the specific infrastructure component responsible for accepting these Encapsulated Map-Requests from ITRs and finding the appropriate EID-to-RLOC mapping. Acting like a DNS resolver, the map resolver consults the mapping database system to determine if the destination IP address belongs to the EID namespace and then identifies the correct mapping. Once the map resolver locates the mapping, it forwards the request to the appropriate map server or directly to the Egress Tunnel Router (ETR) that holds the authoritative mapping for that EID prefix. The map resolver is a critical component in the LISP control plane, enabling ITRs to dynamically discover reachability information without requiring manual configuration of every destination.

Why the others are wrong:

A (ingress tunnel router): The ITR is the device that initiates the Map-Request and encapsulates traffic into LISP packets. While it triggers the mapping lookup process, it is not responsible for "finding" the mapping from a database perspective. The ITR is the client that asks the question, not the server that answers it.

C (egress tunnel router): The ETR is the authoritative device that holds the actual EID-to-RLOC mapping for its site and responds with a Map-Reply containing the mapping information. However, the ETR does not perform the initial search or database lookup—it only provides the mapping when queried.

D (map server): The map server learns and registers EID-prefix mappings from ETRs and maintains a database of authoritative mappings. While the map server plays a role in forwarding Map-Requests to the correct ETR, the responsibility for initially finding the mapping by consulting the database belongs to the map resolver, not the map server.

References:

RFC 9301 - LISP Specification: "A network infrastructure component that accepts LISP Encapsulated Map-Requests, typically from an ITR... finds the appropriate EID-to-RLOC mapping by consulting a mapping database system."

Cisco LISP Configuration Guide: "The map resolver handles Map-Request messages from ITRs and resolves EID-to-RLOC mappings."

Explanation:

In Cisco SD-Access architecture, the Edge Node is the access-layer device that connects wired endpoints such as users, printers, and servers to the fabric overlay network. The Edge Node performs two primary functions. First, it authenticates and authorizes endpoints using security mechanisms like 802.1X (port-based authentication), MAB (MAC Authentication Bypass), or static configuration. This ensures that only legitimate devices gain access to the network and that each endpoint is assigned the appropriate Scalable Group Tag (SGT) for policy enforcement. Second, the Edge Node maintains a local Host Tracking Database that maps endpoint identifiers (such as IP addresses or MAC addresses) to their current Routing Locator (RLOC), which is the Edge Node's own IP address in the underlay network. This mapping is then registered with the central Control Plane Node (based on LISP), enabling the fabric to track endpoint locations as devices roam across the network. Together, these functions allow the fabric to provide secure access, mobility, and consistent policy enforcement.

Why the others are incorrect:

A (provides multiple entry and exit points for fabric traffic):
This describes the function of a Fabric Border Node, not an Edge Node. Border Nodes provide connectivity between the SD-Access fabric and external networks, serving as multiple gateways for traffic entering or leaving the fabric domain. Edge Nodes only handle endpoint connectivity, not external routing.

B (provides the default exit point for fabric traffic):
This is also a function of the Fabric Border Node, which serves as the default gateway for traffic destined outside the fabric. Border Nodes handle inter-VLAN routing and connectivity to traditional networks, Data Centers, or the Internet.

C (provides the default entry point for fabric traffic):
This is another Border Node function. Border Nodes are the entry points for external traffic entering the SD-Access fabric from outside networks. Edge Nodes do not handle external traffic—they only connect internal endpoints.

References:

Cisco SD-Access Solution Design Guide: "Edge nodes provide endpoint authentication and host tracking database for endpoint-to-RLOC mapping."

Cisco Catalyst Center User Guide: "Edge node acts as an access-layer switch that authenticates endpoints and registers them to the control plane."

Explanation:

A JSON Web Token (JWT) is an open standard (RFC 7519) used for securely transmitting information between parties as a JSON object. The token is a compact, URL-safe string composed of three distinct parts separated by dots (.):

Header: Contains metadata about the token, typically the signing algorithm used (e.g., HS256 or RS256) and the token type (JWT). This is Base64Url-encoded.

Payload: Contains the claims, which are statements about the entity (user) and additional data. Claims can be registered (e.g., iss, exp, sub), public, or private. This is also Base64Url-encoded.

Signature: Created by taking the encoded header and payload, concatenating them with a dot, and signing them using the specified algorithm and a secret key (for HMAC) or a private key (for RSA). The signature ensures the token's integrity and authenticity, allowing the receiver to verify that the token was not tampered with.

Why other options are incorrect:

A. header and payload:
This omits the signature, which is essential for verifying token integrity. Without the signature, the token would be just an unverified JSON object, compromising security. All three parts are required for a valid JWT.

B. three parts separated by dots:
version, header, and signature: This is incorrect because JWT does not include a version field. The first part is the header, not a version. The dot-separated format always follows header, payload, and signature.

C. payload and signature:
This omits the header, which is necessary to inform the recipient about the signing algorithm used to validate the signature. Without the header, the recipient cannot determine how to verify the token's authenticity.

References:

RFC 7519 - JSON Web Token (JWT): "A JWT is represented as a sequence of base64url-encoded values, separated by period characters. The three parts are: Header, Payload, and Signature."

IETF RFC 7519: "The header and payload are Base64Url-encoded JSON objects, and the signature is generated using the algorithm specified in the header."