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

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

In a Cisco SD-Access fabric, the fabric edge node is responsible for connecting endpoints (e.g., user devices, IoT devices) to the network. It serves as the first-hop gateway for these endpoints. To provide seamless mobility and optimized traffic forwarding, all fabric edge nodes that service a particular subnet are configured with the same Switched Virtual Interface (SVI) IP address and MAC address. This distributed gateway functionality is known as the Anycast Gateway. It ensures that an endpoint can use the same default gateway regardless of which edge node it is physically connected to within the fabric.

A. fabric border node: This node connects the SD-Access fabric to external networks (e.g., WAN, data center) and is not the default gateway for endpoints within the fabric.
B. control plane node: This node hosts the LISP mapping database (EID-to-RLOC mappings) and does not participate in data plane forwarding as an endpoint gateway.
C. intermediate node: This is an underlay routing device that forwards encapsulated traffic between fabric nodes but does not terminate endpoint traffic or provide gateway services. ---

1. Cisco Systems

Inc. (2022). Cisco SD-Access Solution Design Guide (CVD) - Cisco DNA Center 2.3.3.

Section: Fabric Roles and Terminology > Fabric Edge Node

Quote/Content: "Within the fabric

the default gateway for wired clients is provided in a distributed fashion on all edge nodes. This is accomplished by instantiating a Switched Virtual Interface (SVI) for a given endpoint subnet on all edge nodes where the subnet is present. All edge nodes are configured with the same IP address and MAC address for the SVI

creating a distributed anycast gateway."

2. Cisco Systems

Inc. (2023). Software-Defined Access Configuration Guide

Cisco IOS XE Bengaluru 17.9.x.

Section: About Fabric Edge Node

Quote/Content: "A fabric edge node is a switch that connects wired endpoints to the SD-Access fabric. It is responsible for identifying

authenticating

and registering endpoints... It also functions as the anycast gateway for the connected endpoints."

3. Cisco Systems

Inc. (2023). Cisco SD-Access Technology Overview. White Paper.

Section: SD-Access Fabric Components > Fabric Edge Nodes

Quote/Content: "The fabric edge nodes are the access switches that connect to the policy-extended nodes or endpoints... The fabric edge nodes also provide the Anycast L3 gateway for the connected endpoints."

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:).

REST APIs operate over the HTTP protocol. The standard and fundamental method for securing this communication is to use HTTPS (HTTP Secure), which encapsulates HTTP traffic within a Transport Layer Security (TLS) encrypted tunnel. TLS provides three critical security services: confidentiality (encryption to prevent eavesdropping), integrity (to ensure data is not tampered with in transit), and authentication (verifying the server's identity via digital certificates). This transport-level security is a baseline requirement for protecting sensitive data exchanged with a REST API.

A. MD5 is a cryptographically broken hashing algorithm with known collision vulnerabilities and is not considered secure for verifying data integrity in modern applications.
B. Web Services Security (WS-Security) is a message-level security specification designed specifically for SOAP-based web services, not for the REST architectural style.
D. XML Encryption and Signatures are standards for message-level security, typically used with SOAP/XML-based services, not the transport-level security model common to REST APIs.

1. Cisco DevNet Learning Labs

"REST API Fundamentals" Module: In the "Introduction to REST APIs" section

it states

"All communication with a REST API should be encrypted with TLS (Transport Layer Security). You may also see this referred to as SSL. This prevents man-in-the-middle attacks where an attacker can see all the traffic between the client and the server." This directly supports the use of TLS for REST API security.

Source: Cisco DevNet

"Introduction to REST APIs"

available at developer.cisco.com.

2. Internet Engineering Task Force (IETF) RFC 6749

"The OAuth 2.0 Authorization Framework": This standard

which is fundamental to securing modern REST APIs

mandates the use of TLS.

Section 1.6

"Transport Layer Security"

states: "The authorization server

resource server

and client MUST support TLS."

Section 10.15

"Use of Transport Layer Security (TLS)"

further emphasizes: "OAuth 2.0 requires the use of TLS to protect the confidentiality and integrity of all protocol messages."

3. OWASP Foundation

"REST Security Cheat Sheet": The Open Web Application Security Project (OWASP)

a reputable source for web security standards

lists "Enforce TLS" as a primary security control.

Section "Enforce TLS"

states: "Lack of transport layer encryption is one of the most common vulnerabilities in mobile clients and REST services... TLS should be enforced for any exchange of information."

Source: OWASP REST Security Cheat Sheet

available at cheetsheetseries.owasp.org.

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

Stateful Switchover (SSO) is an intra-chassis high-availability feature for devices with redundant Route Processors (RPs). SSO synchronizes critical state information, including HSRP state, between the active and standby RPs. If the active RP fails, the standby RP on the same physical device immediately takes over control. Because the HSRP state is already synchronized, the device continues its HSRP role (either active or standby) without interruption from the perspective of other network devices. This prevents an unnecessary HSRP failover to a different router in the group, thus minimizing network disruption caused by an RP failure.

A. It enables HSRP to elect another switch in the group as the active HSRP switch. This describes the standard HSRP failover process between different physical devices, which SSO is designed to prevent in the event of an internal RP failure.
B. It ensures fast failover in the case of link failure. SSO's primary function is to provide redundancy for a Route Processor failure, not a link failure. Other mechanisms like HSRP interface tracking or BFD handle link failures.
C. It enables data forwarding along known routes following a switchover, white the routing protocol reconverges. This describes the function of Non-Stop Forwarding (NSF), which works in conjunction with SSO but is a distinct feature responsible for maintaining data plane forwarding during a control plane switchover.

1. Cisco IOS XE Bengaluru 17.6.x (Catalyst 9300 Switches) - High Availability Configuration Guide

"Stateful Switchover (SSO)" Chapter.

Section: Information About Stateful Switchover (SSO)

Content: "Stateful Switchover (SSO) provides redundancy for routing protocols and Layer 2 protocols... In networking devices that support dual Route Processors (RPs)

SSO provides RP redundancy by establishing one of the RPs as the active processor while the other RP is designated as the standby processor... It also synchronizes line card status

hardware-programming

and Layer 2 protocol states (for example

HSRP state)." This confirms SSO synchronizes HSRP state for failover to the standby RP on the same device.

2. Cisco ASR 9000 Series Aggregation Services Router System Management Configuration Guide

Release 7.5.x

"Implementing High Availability" Chapter.

Section: Route Processor Redundancy and Stateful Switchover

Content: "Stateful Switchover (SSO) works with Nonstop Forwarding (NSF) to minimize network downtime... SSO synchronizes routing protocol state

HSRP state

and other information between the active and standby RPs. In the event of a failure of the active RP

the standby RP immediately takes over." This explicitly states HSRP state is synchronized for an immediate takeover by the standby RP.

3. Cisco IOS High Availability Configuration Guide

"Stateful Switchover" Chapter.

Section: SSO-Aware Protocols and Applications

Content: This section lists HSRP as an SSO-aware protocol. It explains that for SSO-aware features

state information is synchronized from the active to the standby RP

allowing the standby to take over seamlessly without losing its state in the protocol. This supports the concept that the HSRP role is maintained by the new RP on the same device.

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

To fulfill the requirements, R3 is configured with AS 130. The bgp router-id command is used within the BGP process to manually assign the ID from Loopback 0, satisfying the first constraint without using address families. External BGP (eBGP) peerings are established with R1 (AS 110) and R2 (AS 120) using their adjacent interface IP addresses (.130 and .230 respectively). Finally, the network command is used directly under the global BGP configuration to advertise the Loopback 100 and 200 subnets. This method utilizes the default IPv4 unicast behavior of Cisco IOS, avoiding the address-family command as requested.

Cisco Systems. IP Routing: BGP Configuration Guide, Cisco IOS Release 15M&T. Section: "Configuring a Basic BGP Network." Link

Cisco Systems. BGP Command Reference. Commands: router bgp, neighbor remote-as, bgp router-id, and network (BGP).

Doyle, J., & Carroll, J. (2005). Routing TCP/IP, Volume II. Cisco Press. Chapter 1: "Introduction to BGP," pp. 35-50. (ISBN: 978-1587052026).

Edgeworth, B., et al. (2020). CCNP and CCIE Enterprise Core ENCOR 350-401 Official Cert Guide. Cisco Press. Chapter 9: "BGP Fundamentals."

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.