Free ENCOR-350-401 Practice Test Questions and Answers (2026) Practice Questions

The Cisco DNA Center (now Catalyst Center) Northbound API allows external applications and orchestrators to interact with the controller. Its key characteristics include:

1. Referred to as Intent API: Cisco officially designates its northbound interface as the "Intent API" because it allows high-level business intent to be translated into network configurations.
2. RESTful API based on HTTP methods: It follows standard REST architecture, utilizing standard HTTP verbs like GET, POST, PUT, and DELETE to perform operations.
3. Uses JSON exclusively: The API typically mandates Content-Type: application/json for requests and returns data in JSON format, distinguishing it from XML-based APIs.

Why others are incorrect:

• Supports NETCONF, SSH, SNMP: These are Southbound protocols used by the controller to communicate with network devices, not Northbound APIs used by applications to talk to the controller.
• Multivendor focus: While limited third-party support exists via SDKs, the primary focus of DNA Center and its specific Northbound API is the management of Cisco Catalyst, Nexus, and Aironet infrastructure, not a generic multivendor focus.

Cisco DevNet. "Cisco DNA Center Intent API - Overview." Cisco Developer Network. The documentation explicitly states: "The Cisco DNA Center Intent API is a northbound REST API... The API allows you to use HTTPS verbs (GET, POST, PUT, DELETE) and JSON structures to discover and control your network."

Cisco Systems. "Cisco DNA Center Platform User Guide, Release 2.3.3." Chapter: Cisco DNA Center Platform Overview. Mentions the exposure of the platform via the Intent API for external integration.

Cisco Systems. "Cisco Digital Network Architecture Center (DNA Center) Data Sheet." Describes the platform's programmability via "Intent-based APIs."

Procedural (Imperative) configuration focuses on the "how." It relies on a specific sequence of commands (scripts) executed in order to reach a state. Because the administrator is writing the explicit steps (e.g., CLI commands), they must possess deep knowledge of the specific syntax for that device and the current context (state) of the system to avoid errors.

Declarative configuration focuses on the "what" (the desired state) without defining the specific steps to get there. The system or tool abstracts the underlying complexity. Puppet is a prime example of a tool that uses a declarative domain-specific language (DSL) where administrators define the end state (e.g., "ensure Apache is installed"), and the tool determines the necessary actions to achieve it.

Cisco Systems. Cisco DevNet Associate DEVASC 200-901 Official Cert Guide. Chapter 14: Infrastructure as Code. Section: "Imperative vs. Declarative." (Defines imperative as sequence-based and declarative as intent-based).

Puppet. Puppet Documentation: Introduction to Puppet. "Understanding the Puppet language." Available at: https://www.puppet.com/docs/puppet/7/puppet_language.html (States: "Puppet uses a declarative language to describe system configuration... You describe the state you want your system to be in, not the steps to get there.").

Microsoft. Azure Architecture Center: Infrastructure as Code. "Imperative vs. declarative code." Available at: https://learn.microsoft.com/en-us/azure/architecture/guide/devops/infrastructure-as-code (Confirming declarative defines "what" and imperative defines "how").

Red Hat. What is infrastructure as code (IaC)? "Declarative vs. imperative." Available at: https://www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac (Reinforces that declarative tools like Puppet focus on the desired state).

PIM Sparse Mode (PIM-SM) is designed for networks where multicast group members are sparsely distributed. It operates on a pull model, meaning multicast traffic is not flooded; instead, routers must explicitly send Join messages to receive traffic.

To facilitate this, PIM-SM requires a Rendezvous Point (RP), which acts as a meeting place for sources and receivers. Traffic initially flows down a shared distribution tree (rooted at the RP) to reach the receivers. In contrast, PIM Dense Mode uses a "push" (flood and prune) model and builds source-based trees by default.

Cisco Systems, IP Multicast: PIM Configuration Guide, "Protocol Independent Multicast (PIM)," Section: "PIM Sparse Mode".

Quote: "PIM-SM uses a pull model to deliver multicast traffic. Only network segments with active receivers that have explicitly requested the data will receive the traffic."

IETF RFC 7761, Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised), Section 3.1.

Summary: Defines the role of the Rendezvous Point (RP) and the creation of shared trees (*,G) for traffic distribution.

Juniper Networks, Multicast Protocols Guide, "Understanding PIM Sparse Mode".

Quote: "PIM sparse mode (PIM-SM) ... relies on a rendezvous point (RP) to forward multicast traffic ... builds a shared tree."

The Northbound API in Cisco Catalyst Center is also known as the Intent API. It is designed to abstract the complexity of the underlying network infrastructure. This API allows external applications, IT systems, and network administrators to declare a desired business outcome or "intent" (e.g., "prioritize video traffic for executive users") without specifying the low-level, step-by-step configuration commands. Cisco Catalyst Center then interprets this intent and automatically translates it into the necessary configurations, which are pushed to the network devices via its southbound interfaces. This approach focuses on the "what" (the outcome) rather than the "how" (the individual steps).

A. Southbound APIs are used by the controller to communicate with and configure network devices. They are concerned with the "how" (the steps), not the "what" (the intent).

B. Westbound APIs facilitate communication between different controller instances or domains (controller-to-controller), not for receiving high-level intent from external applications.

D. Eastbound APIs are also for controller-to-controller communication. "Events and Notifications" describes a function, not the primary API type for defining network outcomes.

1. Cisco DevNet Documentation: Cisco Catalyst Center Platform Overview. In the section "Northbound APIs (Intent APIs)

" it states

"The Northbound APIs

also known as Intent APIs

allow you to programmatically control the network as a single fabric... They allow you to focus on a business or IT outcome (the 'intent') and to express that intent to the network

which then takes care of the details."

Reference: Cisco Developer

"Cisco Catalyst Center Platform Overview

" Section: Northbound APIs (Intent APIs).

2. Cisco White Paper: Cisco DNA Intent-Based Networking: The Assurance Journey. This paper describes the architecture

stating

"Northbound APIs allow for integration with third-party applications and business systems... These APIs are intent-based

meaning they are declarative and describe the 'what' rather than the 'how'."

Reference: Cisco White Paper

"Cisco DNA Intent-Based Networking: The Assurance Journey

" (2019)

Page 4

Section: "Cisco DNA Center architecture".

3. Official Vendor Documentation: Cisco DNA Center Platform User Guide. The architectural diagrams and descriptions in the guide consistently show Northbound APIs interfacing with "Business/IT Applications" to receive intent

while Southbound APIs interface with "Network Devices" to execute configuration.

Reference: Cisco DNA Center Platform User Guide

Release 2.3.5

Chapter: "Cisco DNA Center Platform Overview

" Section: "Cisco DNA Center Platform Architecture".

Cisco Umbrella operates at the DNS layer, providing the first line of defense by blocking requests to malicious domains. AMP4E (Cisco Advanced Malware Protection for Endpoints, now Cisco Secure Endpoint) is specifically designed to provide continuous monitoring and malware protection directly on endpoint devices. FTD (Firepower Threat Defense) is the unified software image for Cisco NG-Firewalls, integrating core firewall functions with Next-Generation IPS (intrusion prevention systems). StealthWatch (now Cisco Secure Network Analytics) utilizes NetFlow and other telemetry to perform security analytics and detect anomalies across the network. ESA (Email Security Appliance, now Cisco Secure Email) is a gateway solution designed to filter SMTP traffic and protect organizations against email-based threats like phishing and spam.

Cisco Systems. Cisco Umbrella: Cloud Security Essentials. Cisco.com. Retrieved from "What is Cisco Umbrella?" product overview.

Cisco Systems. Cisco Secure Endpoint (formerly AMP for Endpoints) Data Sheet. Referencing section "Continuous monitoring and recording" and "Advanced malware protection".

Cisco Systems. Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager. Chapter: "Intrusion Prevention".

Cisco Systems. Cisco Secure Network Analytics (formerly Stealthwatch) At-a-Glance. Referencing "Network Visibility and Security Analytics" and reliance on "network telemetry".

Cisco Systems. Cisco Secure Email Gateway Data Sheet. Referencing "comprehensive protection against email threats".

DHCP Option 43 for Cisco lightweight access points (APs) uses a vendor-specific format to provide the IP addresses of one or more Wireless LAN Controllers (WLCs). This information is encoded using a Type-Length-Value (TLV) structure. The entire TLV string, which includes the type (sub-option 0xf1), length (number of WLC IPs x 4), and value (the WLC IP addresses), must be formatted as a single hexadecimal string. The AP's firmware is designed to parse this specific hexadecimal value to discover and join its controller.

A. ASCII: The AP's CAPWAP discovery process does not parse human-readable ASCII strings for Option 43; it expects a specific binary structure represented in hex.

C. Base64: This is a binary-to-text encoding scheme, but it is not the format required by Cisco APs for DHCP Option 43.

D. MD5: This is a cryptographic hash function used for verifying data integrity, not for encoding configuration data like an IP address in a DHCP option.

1. Cisco Catalyst 9800 Series Wireless Controller Configuration Guide

Cisco IOS XE Bengaluru 17.6.x: In the chapter "System Management

" under the section "Configuring DHCP

" it states: "The format of the TLV block is: Type + Length + Value. Type is always the sub-option code 0xf1. Length is the number of controller IP addresses times 4 in hex. Value is the IP addresses of the controller listed sequentially in hex."

2. Lightweight AP (LAP) Registration to a Wireless LAN Controller (WLC) - Cisco Technical Note: In the section "Configure DHCP Option 43

" the document provides examples for various DHCP servers. For a Cisco IOS DHCP server

the configuration command is option 43 hex f104.c0a8.0a05

explicitly using the hex keyword and a hexadecimal value.

3. Cisco Wireless LAN Controller (WLC) Configuration Best Practices: In the "DHCP" section

this guide explains

"For Cisco APs

the value of this option is the IP address of the WLC management interface

which is entered in hexadecimal format." It provides the example f104c0a8640a for WLC at 192.168.100.10.

Blank 1 (event syslog pattern): The string "SYS-5-CONFIG_I" is a standard Cisco IOS system logging (syslog) message generated when a configuration change is made (specifically, "Configured from console..."). To trigger an EEM applet based on a specific log message, the event syslog pattern detector is required.

Blank 2 ("enable"): action 1.0 is used to prepare the CLI session. The command "enable" places the EEM applet into privileged EXEC mode. This is a standard best practice in EEM scripts to ensure subsequent commands (like writing to flash) have the necessary permissions to execute.

Blank 3 (| append flash): action 2.0 executes show clock to generate a timestamp. The goal is to add this entry to a file. The pipe character | followed by append is the IOS syntax to direct output to a file without overwriting existing data. The destination file system is flash, creating the valid path flash:ConfSave.txt.

Cisco Systems. Embedded Event Manager Configuration Guide, Cisco IOS Release 15M&T: "Embedded Event Manager Event Detectors." (Refer to the section on "Syslog Event Detector" which utilizes the syntax event syslog pattern regular-expression).

Cisco Systems. Cisco IOS Network Management Configuration Guide: "Writing EEM Policies using CLI." (See examples involving action cli command where enable is used to enter privileged mode).

Cisco Systems. Cisco IOS Configuration Fundamentals Command Reference: "CLI parsing" and "File System Commands." (Documents the usage of the pipe character | with the append keyword for redirecting command output to file systems like flash:).

The question requires a WLAN configuration that supports two specific features: 802.11r and the use of a passphrase for authentication. The IEEE 802.11r standard is also known as Fast BSS Transition (FT), or simply "Fast Transition." A "passphrase" is characteristic of Pre-Shared Key (PSK) authentication, commonly used in WPA2/WPA3-Personal security policies. To meet both requirements, the engineer must enable the Fast Transition feature on the WLAN and configure the security policy to use the specific Authentication and Key Management (AKM) suite known as FT-PSK. This combination allows for fast roaming between access points while using a shared key for authentication.

A. 802.1X and SUITEB-1X: 802.1X is an authentication framework that uses individual user credentials (e.g., username/password or certificates), not a shared passphrase.

C. 802.1X and Fast Transition: This option is incorrect because 802.1X authentication does not use a passphrase, which is a specific requirement of the question.

D. FT PSK and SUITEB-1X: SUITEB-1X is a high-security cryptographic suite designed for use with 802.1X authentication, not with PSK-based methods.

1. Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide

IOS XE Amsterdam 17.3.x - Security Configuration Guide

Chapter: Configuring Security. This guide details the WLAN security policy configuration. In the section for configuring WPA2

it specifies the options for Authentication Key Management (AKM)

which include "FT-PSK" for Fast Transition with a Pre-Shared Key. It states

"For WPA2 Policy

you can enable... Fast Transition (802.11r)... For AKM

you can choose PSK... When Fast Transition is enabled with PSK

this is FT-PSK."

2. IEEE Std 802.11™-2020

IEEE Standard for Information Technology—Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. - Section 12.4.2.3

"AKM suite selector definitions". Table 12-6 defines the AKM suite selectors. The suite "FT authentication and key management with PSK" is explicitly defined with the selector value 00-0F-AC:3

confirming that FT-PSK is a standardized method.

3. Cisco Wireless Controller Configuration Guide

Release 8.5 - Chapter: Configuring Security Solutions

Section: Configuring Fast Transition. This document explains

"Fast Transition can be configured for WPA2-Enterprise (802.1X) or WPA2-Personal (PSK) security policies." This directly confirms that Fast Transition (802.11r) can be combined with PSK (passphrase).

The event none command is used within an Embedded Event Manager (EEM) applet configuration to register the policy without associating it with a specific system event trigger. This configuration makes the applet available to be executed "on demand" or manually. The applet can then be invoked from the command-line interface (CLI) using the event manager run command or called by another EEM policy. This method is ideal for creating reusable scripts or for tasks that require manual initiation by a network administrator.

A. event register is not a valid EEM event detector command. While some event detectors use the keyword register as an option, it is not used to define a manual trigger.

B. event manual is not a valid EEM event detector command. The term "manual" describes how the applet is run, but it is not the keyword used in the configuration to define the trigger.

D. This configuration is syntactically invalid as it completely omits the mandatory event command. An EEM applet must contain at least one event command to define its triggering condition.

1. Cisco IOS XE Embedded Event Manager (EEM) Configuration Guide

Cisco IOS XE Gibraltar 16.12.x

Section: "Configuring an EEM Applet to Run On Demand or Manually"

Content: "The event none command registers an EEM applet without an event so that it can be run on demand. The applet can be run manually from the CLI using the event manager run applet-name command..." This section explicitly details the use and purpose of the event none command for creating on-demand applets.

2. Cisco IOS Embedded Event Manager Command Reference

Command: event none

Usage Guidelines: "To configure an Embedded Event Manager (EEM) applet to run on demand or manually

use the event none command in applet configuration mode... This command registers an EEM applet but does not associate an event with it." This reference directly confirms the function of the event none command.

3. Cisco IOS XE Programmability Configuration Guide

Cisco IOS XE 17

Section: "Embedded Event Manager Overview"

Content: This guide describes the fundamental structure of an EEM applet

stating that it consists of an event statement and an action statement. This confirms that an applet without an event statement (as in option D) is invalid.

The principle of Complete Mediation requires that every access to every object must be checked for authority. This principle explicitly argues against relying on cached permissions, as the state of authorization can change between the time of the initial check and a subsequent access. The scenario describes a system that must validate access rights for all resources and not use a cached matrix precisely because a revoked permission might not be reflected, leading to a security violation. This is the textbook definition of enforcing Complete Mediation.

A. economy of mechanism: This principle advocates for keeping the design as simple and small as possible to facilitate verification, not for how often access checks are performed.

C. separation of privilege: This principle requires that access be granted based on more than one condition or credential, not that every access attempt must be re-validated.

D. least common mechanism: This principle advises minimizing shared resources between users to prevent unintended information paths, which is unrelated to validating every access request.

1. Saltzer

J. H.

& Schroeder

M. D. (1975). The Protection of Information in Computer Systems. Communications of the ACM

18(7)

38-49. In Section I.A.3.b

"Principle of Complete Mediation

" it states

"Every access to every object must be checked for authority... If a mechanism remembers the result of an authority check

it is acting as a cache... If the rights can change

the cache may be incorrect." This directly supports the answer.

2. National Institute of Standards and Technology (NIST). (2018). Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems (NIST Special Publication 800-160

Vol. 1). In Appendix F.3

"Complete Mediation

" the principle is defined as: "every access to every object must be checked for authority... The checking mechanism should not rely on a previous check."

3. Parno

B.

& Perrig

A. (2014). 6.858 Computer Systems Security

Fall 2014 Lecture Notes. Massachusetts Institute of Technology: MIT OpenCourseWare. In Lecture 2

Section 4

"Secure design principles (Saltzer & Schroeder)

" Complete Mediation is summarized as: "Check every access. Don't cache results of a check."

Auto anchor, also known as Mobility Anchor, is a feature specifically designed to ensure that a client's traffic is tunneled to a pre-designated anchor Wireless LAN Controller (WLC). When a client roams to a new WLC (the foreign controller), even one in a different mobility group, the auto-anchor configuration on the WLAN forces the client's session to be anchored back to the designated WLC. This ensures the client maintains its original IP address and that all its traffic egresses from a consistent point on the network, which is essential for seamless Layer 3 roaming across disparate network segments or mobility domains.

A. interface groups: This feature is used for VLAN pooling and load balancing of clients across multiple interfaces on a single WLC, not for managing inter-controller roaming.

B. RF groups: This feature is used for Radio Resource Management (RRM) to dynamically manage channel and power settings among WLCs; it is unrelated to client data tunneling or IP address retention during a roam.

C. AAA override: This allows a RADIUS server to dynamically assign attributes like VLANs or ACLs to a client upon authentication but does not provide the tunneling mechanism needed for an inter-controller Layer 3 roam.

1. Cisco Enterprise Mobility 8.5 Design Guide:

Section: Mobility Architecture > Inter-Controller Mobility > Mobility Anchor

Content: "Mobility anchor (or Auto-anchor) is a feature where a WLAN is configured to tunnel client traffic to a specific controller or set of controllers... This feature is used to provide a single point of presence for a client on the network." This guide explains that auto-anchoring is the mechanism for this type of forced tunneling

which is a common requirement for guest access and roaming between different subnets or administrative domains.

2. Cisco Wireless LAN Controller Configuration Guide

Release 8.5:

Chapter: Configuring Mobility Groups > Mobility Anchor

Content: "You can use the mobility anchor feature to restrict a WLAN to a single subnet

regardless of the entry point of a client into the network... When a client associates to a WLAN with a mobility anchor

the client is sent to the anchor controller

and the client traffic is tunneled from the foreign controller to the anchor controller." This explicitly states the feature's purpose is to maintain the client on a single subnet via tunneling

which is the core requirement of the question.

A virtual machine (VM) is a complete emulation of a physical computer system. It operates on a hypervisor, which abstracts the physical hardware of the host machine. Each VM encapsulates its own full guest operating system (OS), kernel, applications, binaries, and libraries. This self-contained nature ensures strong isolation from the host OS and any other VMs running on the same physical hardware. This isolation is a core principle of Type-1 and Type-2 hypervisors, preventing processes or failures within one VM from impacting the host or other guest environments.

A. This describes containers. Containers share the host OS kernel and often its binaries and libraries, which is why they are more lightweight than VMs.

B. VMs are less resource-efficient than containers because each VM requires a full guest OS, consuming significant CPU, memory, and storage overhead.

D. VMs are considered heavyweight due to the inclusion of a complete guest OS, making them significantly less lightweight than containers.

1. Official Vendor Documentation (VMware): VMware

Inc. "What is a Virtual Machine?" VMware Glossary. "Virtual machines are isolated from one another and use their own guest OS

which means that if one crashes

it won’t affect the others. This isolation also boosts security

as malware in one VM won’t spread to the others." Retrieved from the official VMware website.

2. Official Vendor Documentation (Red Hat): Red Hat

Inc. "What is virtualization?" Red Hat Customer Portal. "A virtual machine is a software-based computer that runs on a physical computer... Each VM has its own operating system (OS) and functions separately from the other VMs

even when they are all running on the same host." This document explicitly confirms the isolated OS characteristic.

3. Official Vendor Documentation (Cisco): Wallace

K.

et al. (2020). CCNP and CCIE Enterprise Core ENCOR 350-401 Official Cert Guide. Cisco Press. Chapter 2

"Virtualization Fundamentals

" section "Virtual Machines

" explains that a hypervisor creates VMs

each with its own OS

applications

and virtual hardware

providing isolation from the host.

An SD-Access extended node is a device that connects to a fabric edge node to extend Layer 2 connectivity into areas where deploying a full fabric-capable switch is not practical. It functions as a port extender for the parent edge node. This allows endpoints and even downstream non-fabric Layer 2 switches to connect to the SD-Access fabric, inheriting the policy and segmentation capabilities enforced by the parent edge node. The extended node itself does not perform fabric encapsulation (VXLAN) or control plane functions (LISP); these are handled by the connected fabric edge node.

A. This describes the function of a fabric border node, which connects the SD-Access fabric to external Layer 3 networks.

B. Tunnelling over unknown networks is a function associated with SD-WAN integration or specific border node configurations, not an extended node.

C. This description is too generic; the specific function is Layer 2 extension, not a general remote registration mechanism for all non-fabric devices.

1. Cisco SD-Access Solution Design Guide (CVD)

"SD-Access Fabric Roles and Terminology

" Section: "Fabric Roles in Detail

" Subsection: "Extended Node." The guide states

"An extended node connects to an SD-Access fabric edge node and acts as a port extender... This allows you to extend the enterprise network by connecting additional endpoints... to the fabric."

2. Software-Defined Access Configuration Guide

Cisco IOS XE Bengaluru 17.6.x

"Configuring SD-Access Extended Node" chapter. This guide details that "The SD-Access extended node feature enables you to extend the SD-Access fabric to non-carpeted spaces... An extended node is connected to a fabric edge node through an 802.1Q trunk port." This confirms its role as a Layer 2 extension.

3. Cisco Digital Network Architecture Center (DNA-C) User Guide

Release 2.3.5

"Provision an SD-Access Extended Node" section. The documentation describes the workflow for onboarding extended nodes

which are connected "to a Fabric Edge device" to provide port extension.

The Cisco Stealthwatch system, now known as Cisco Secure Network Analytics, is the core component of the Cisco Cyber Threat Defense (CTD) architecture responsible for providing network visibility and security intelligence through flow analysis. It collects and analyzes network telemetry, primarily NetFlow, from network infrastructure devices to establish a baseline of normal behavior. By integrating with the Cisco Identity Services Engine (ISE), Stealthwatch enriches this flow data with user and device context, allowing security teams to see not just what is happening on the network, but who is responsible for the activity. This combined flow and user context is crucial for detecting anomalies, insider threats, and advanced malware behavior.

A. Cisco Firepower and FireSIGHT: This is a Next-Generation Firewall (NGFW) and Intrusion Prevention System (IPS) focused on deep packet inspection and policy enforcement, not broad, network-wide flow context analysis.

C. Advanced Malware Protection: Now Cisco Secure Endpoint, this solution focuses on detecting and blocking malware on endpoints (hosts). It does not perform network-level flow analysis.

D. Cisco Web Security Appliance: This is a secure web gateway that inspects and filters HTTP/HTTPS traffic. Its context is limited to web traffic, not the entire network's flow data.

1. Cisco.com Documentation: Cisco Cyber Threat Defense Solution Design Guide. In the "Cyber Threat Defense Solution Architecture" section

under "Sense

" the document states

"The StealthWatch System provides network visibility and security intelligence by collecting and analyzing NetFlow data from all of the network infrastructure devices... The StealthWatch Management Console correlates data from ISE to provide identity-aware NetFlow analysis." (Reference: Chapter 2

"Cyber Threat Defense Solution Architecture").

2. Cisco.com Data Sheet: Cisco Secure Network Analytics (Stealthwatch) Data Sheet. The document highlights its core function: "Cisco Secure Network Analytics provides comprehensive visibility into all network traffic... It also integrates with Cisco Identity Services Engine (ISE) to provide user identity information in its analysis

so you can see who was doing what on the network." (Reference: "Product overview" section).

3. Cisco.com White Paper: Visibility and Threat Detection with Cisco Stealthwatch. This paper explains

"Stealthwatch consumes network telemetry from every part of the network... and enriches it with context such as user

device type

location

and application." (Reference: "How Stealthwatch Works" section).

Increasing the mandatory minimum data rates is a primary technique for tuning the effective cell size of an Access Point (AP). A wireless client must be able to support all mandatory (or "basic") data rates to associate with an AP. By disabling the lowest data rates (e.g., 1, 2, 5.5, 11 Mbps) and setting a higher minimum mandatory rate (e.g., 12 or 24 Mbps), clients at the edge of the cell with weak signals can no longer maintain the required connection. This forces the client to disassociate from the distant AP and initiate a roam to a closer AP with a stronger signal, directly mitigating the "sticky client" problem common in dense RF environments.

A. Decrease radio channel widths to 40 MHz.

This action primarily reduces co-channel interference and is a good practice in dense environments, but it does not directly influence a client's roaming decision to solve the sticky client issue.

C. Decrease the mandatory minimum data rates.

This would have the opposite effect, enlarging the AP's effective cell size and allowing clients to remain connected at greater distances with weaker signals, thus worsening the sticky client problem.

D. Increase radio channel widths to 160 MHz.

This increases potential throughput but also significantly increases the potential for co-channel interference, especially in dense deployments. It does not address client roaming behavior.

1. Cisco

High Density Wi-Fi Design and Deployment Guide (Dec 19

2019). In the "Data Rates" section

it states: "Disabling the lower data rates helps to reduce the cell size of the APs... This can help with 'sticky' clients that tend to hang on to a distant AP by forcing them to roam to a closer AP." (Section: Design for High Density

Subsection: Data Rates).

2. Cisco

Enterprise Mobility 8.5 Design Guide (December 20

2019). Chapter 3

"Wireless LAN RF Design Considerations

" discusses RF tuning. The section "Data Rates" explains: "Setting the lowest data rate to mandatory forces a client to be able to receive the packet at that data rate... Disabling the lower data rates can be used to reduce the cell size and force clients to roam to a closer AP."

3. Cisco

Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide

Cisco IOS XE Bengaluru 17.6.x. The "Configuring Data Rates" chapter details the process: "By default

the 802.11b/g data rates of 1

2

5.5

and 11 Mbps are disabled... Disabling lower data rates can help to reduce the number of sticky clients." (Chapter: Configuring Radio Settings

Section: Configuring Data Rates).

A fundamental characteristic of a traditional WAN is the integration of the control plane and the data plane within each network device. In a traditional router, the control plane is responsible for building the routing table (e.g., via OSPF, BGP), and the data plane is responsible for forwarding packets based on that table. Both functions are tightly coupled and run on the same device's operating system. This architecture necessitates individual, box-by-box configuration and management, which is a defining trait of traditional network designs.

A: Traditional WANs are characterized by high operational complexity that increases significantly with scale, not low complexity.

B: Centralized policy management is a primary feature of Software-Defined WAN (SD-WAN), not traditional WANs where policies are configured decentrally.

C: DTLS and TLS are used to secure control plane connections between edge devices and controllers in Cisco's SD-WAN architecture, not in traditional WANs which typically use IPsec.

1. Cisco Systems

"Cisco SD-WAN Design Guide" (July 20

2022). In the section "Traditional WAN Architecture

" it states: "In a traditional router

the control plane and data plane are coupled. The control plane is the intelligence of the router... The data plane is the forwarding plane that is responsible for forwarding the packets." This directly supports that a unified plane is a characteristic of traditional WANs.

2. Cisco Systems

"Cisco SD-WAN Getting Started Guide." In the "About the Cisco SD-WAN Solution" section

it states: "The Cisco SD-WAN solution separates the data plane and the control plane." This highlights the architectural difference from traditional networks. The same guide

in the "Control Plane" section

specifies

"The vSmart controller establishes a secure Datagram Transport Layer Security (DTLS) connection to each vEdge router." This confirms that DTLS/TLS is an SD-WAN feature.

3. Feamster

N.

Rexford

J.

& Zegura

E. (2014). "The Road to SDN: An Intellectual History of Programmable Networks." ACM SIGCOMM Computer Communication Review

44(2)

87–98. https://doi.org/10.1145/2602204.2602219. This academic paper discusses the evolution of networking

highlighting that the core innovation of SDN (the foundation for SD-WAN) is the separation of the control and data planes

which were traditionally bundled together in network devices (Page 87

Section 1: Introduction).

The goal is to retrieve (return) the configuration data for GigabitEthernet1 displayed in the JSON response.

1. HTTP Verb: The request body is N/A, which indicates a data retrieval operation, requiring the GET method.
2. URL: The base URL ends in /native/. The JSON body corresponds to the YANG model hierarchy for interface -> GigabitEthernet -> 1. Therefore, the correct URI suffix to address this specific resource is interface/GigabitEthernet/1/.
3. Headers: In a GET request, the client uses the Accept header to specify the media type it expects the server to return. The string -application/vnd.yang.data+json represents the media type, so the missing header name is Accept.

IETF RFC 8040, "RESTCONF Protocol", Section 4.1. "HTTP Methods". The document defines that the GET method is used to retrieve data for a resource.

Cisco Systems, "Programmability Configuration Guide, Cisco IOS XE", Chapter: "RESTCONF Protocol", Section: "RESTCONF Headers". This section specifies that the Accept header is used to request the format of the response data (e.g., application/vnd.yang.data+json).

Cisco Systems, "Programmability Configuration Guide, Cisco IOS XE", Chapter: "Native YANG Models". This explains the hierarchy of the native model, confirming the path structure native/interface/{interface-type}/{interface-number} (e.g., interface/GigabitEthernet/1/).

The Cisco Catalyst Center Intent API is the primary northbound, consumer-facing RESTful API. It is designed to abstract the complexity of the underlying network infrastructure. This allows developers and network administrators to programmatically define the desired state or "intent" for the network (e.g., provision a new site, apply a security policy) without needing to manage individual device configurations. The controller then translates this intent into the specific commands required for the network devices.

B. This is incorrect because the Intent API is a northbound interface (NBI), which communicates with applications and external systems, not a southbound interface (SBI), which communicates with network devices.

C. This describes a southbound interface (SBI), such as NETCONF, SNMP, or CLI, which the controller uses to communicate directly with and manage the network devices.

D. This describes an east-west interface, used for integration between different controllers or management platforms at the same logical layer. The Intent API is fundamentally a northbound interface.

1. Cisco Systems

"Cisco DNA Center Platform Overview": In the section "Cisco DNA Center Platform Architecture

" the document states

"The Northbound APIs

also known as Intent APIs

are REST APIs that expose specific capabilities of the Cisco DNA Center platform. These APIs provide a programmable interface to the platform and allow you to create applications and integrate with other systems." (Reference: Cisco DNA Center Platform Overview

"Northbound APIs (Intent APIs)" section).

2. Cisco DevNet

"Getting Started with the Cisco DNA Center APIs": The documentation explicitly defines the API's direction and purpose: "The Cisco DNA Center platform exposes a rich set of REST APIs on its northbound interface. These APIs allow you to programmatically control your network

get information about your network's health and performance

and much more." (Reference: Cisco DevNet

Cisco DNA Center API Fundamentals

"Cisco DNA Center APIs" section).

3. Cisco Systems

"Cisco DNA Center Platform API Reference Guide": The introduction to the API reference guide consistently refers to the APIs as northbound interfaces that allow for the automation of network operations based on intent. It details how these REST APIs are the entry point for external systems to interact with the controller's functions. (Reference: Cisco DNA Center Platform API Reference Guide

"Introduction" section).

The exhibit shows a 400 Bad Request status code with a response body explicitly stating: "detail": "s is not a valid UUID of device". In the Cisco Catalyst Center Intent API, the endpoint for retrieving specific device information is GET /dna/intent/api/v1/network-device/{id}. The error indicates that the URI string was constructed incorrectly by appending "s" (likely a typo in the URL path) where a valid Universally Unique Identifier (UUID) was expected. Because this is a GET request, the identifier is passed within the URI path, not a JSON payload. Therefore, the malformed URI is the root cause of the "Invalid input request."

A. The token has expired: An expired or missing token would result in a 401 Unauthorized status code, not a 400 Bad Request related to input validation.

C. Authentication has failed: Authentication failures return a 401 Unauthorized or 403 Forbidden response. The exhibit shows a valid token header is present and the server accepted the credentials.

D. The JSON payload contains the incorrect UUID: This is a GET request. According to Cisco API standards, GET requests for device details use path parameters, not a JSON request body (payload).

Cisco Catalyst Center Intent API Reference, Version 2.3.7.x: Section "Get Device by ID". This documentation specifies that the device UUID must be passed as a path parameter in the URI.

Cisco DevNet Learning Labs: "Cisco DNA Center Intent APIs" module, which details the structure of REST API calls and common HTTP error codes like 400 Bad Request for path parameter mismatches.

IETF RFC 7231: Section 6.5.1, defining the 400 Bad Request status code as the appropriate response when the server cannot process the request due to perceived client error (e.g., malformed request syntax).

Protocol Independent Multicast - Dense Mode (PIM-DM) is designed for networks where multicast group members are densely distributed. It operates on a push model (also known as flood-and-prune), where multicast traffic is initially flooded to all parts of the network under the assumption that every subnet has at least one receiver. This flooding process builds source-based distribution trees (also called Shortest Path Trees or SPTs), rooted at the source of the multicast stream ($S, G$). Routers that do not have active receivers for a specific group must explicitly signal their upstream neighbors to stop forwarding traffic by sending Prune messages; therefore, PIM-DM uses prune mechanisms to remove branches of the tree that do not need the traffic.

In contrast, PIM Sparse Mode (PIM-SM) uses a pull model, shared trees (*, G), and relies on a Rendezvous Point (RP).

Adams, A., Nicholas, J., & Siadak, W. (2005). Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) (RFC 3973). Internet Engineering Task Force.

Section 1 (Introduction): Describes PIM-DM as using a "push model" where traffic is flooded to the entire network.

Section 1.1: Confirms the mechanism of "Prune messages" used to stop traffic flow on specific interfaces.

Section 2 (Protocol Overview): "In PIM-DM, a source-based tree is built...".

Cisco Systems. (2024). IP Multicast: PIM Configuration Guide, Cisco IOS XE 17.x.

Chapter: PIM Dense Mode: States, "PIM dense mode (PIM-DM) uses a push model to flood multicast traffic to every corner of the network." and "This method creates a source-based distribution tree."

Williamson, B. (2000). Developing IP Multicast Networks, Volume 1. Cisco Press.

Chapter 6 (PIM Dense Mode): Details the "Flood and Prune" behavior, characterizing it as a push model that utilizes source distribution trees (S,G) exclusively, distinguishing it from the shared trees used in Sparse Mode.