Free 300-435 Practice Test

Native YANG data models are developed by a specific network device vendor, such as Cisco, Juniper, or Arista. They are designed to provide a complete and detailed representation of all the configuration and operational state data available on that vendor's specific platform and operating system (e.g., Cisco IOS XE). Because they are tightly coupled with the device's software, they expose all features, including proprietary ones, that are relevant only to that platform. This contrasts with OpenConfig models, which are vendor-neutral and developed by a consortium of network operators to ensure interoperability across different platforms.

A. This statement is incorrect because native models are, by definition, platform-dependent, not independent. Vendor-neutral models (like OpenConfig or IETF) are designed for platform independence.
B. Native models are developed and maintained by network vendors as part of their operating system development, not by individual, unaffiliated developers.
C. This statement incorrectly describes OpenConfig models. OpenConfig models are developed by network operators (not vendors) and are explicitly designed to be vendor-neutral, not platform-specific. ---

1. Cisco Systems

Inc.

"Programmability Configuration Guide

Cisco IOS XE Bengaluru 17.6.x

" Chapter: YANG Data Models.

Section: Cisco-Specific (Native) YANG Models: "Cisco-specific YANG models are also called native models. These models are generated from the Cisco IOS XE Software configuration and operational data... They are bound to the underlying device system

which is tied to a particular software release." This directly supports the answer that native models are vendor-developed and platform-specific.

2. Cisco Systems

Inc.

"YANG Data Models

" Cisco IOS XR Data Models Configuration Guide.

Section: Native Data Models: "Native models represent the complete feature set of the router. These models are vendor-specific

and are generated by Cisco." This confirms that native models are vendor-specific and cover the full feature set of the platform.

3. OpenConfig.

"OpenConfig

" openconfig.net.

About Section: "OpenConfig is an informal working group of network operators sharing the goal of moving our networks toward a more dynamic

programmable

and vendor-neutral footing." This source clarifies that OpenConfig models are operator-driven and vendor-neutral

directly contradicting option C.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/300-435/page_63_img_1.jpg

Zero-Touch Provisioning (ZTP) is a method used to automatically configure network devices upon their initial boot-up. In a typical ZTP workflow, a factory-default device powers on and sends a DHCP request to obtain an IP address. The DHCP server's response includes not only the IP address but also specific DHCP options (e.g., Option 67, Bootfile Name) that point the device to a TFTP or HTTP server. The device then downloads a configuration file or a startup script from this server and applies it, completing the provisioning process without any manual intervention. This process directly matches the scenario described in the question.

A. PnP: While Cisco's Plug and Play (PnP) is an automation solution, it is a more comprehensive, controller-based framework (often using Cisco DNA Center) rather than the fundamental DHCP/TFTP mechanism itself, which is best described as ZTP.
B. iPXE: iPXE (intelligent Preboot Execution Environment) is an open-source boot firmware used primarily for booting computer operating systems over a network, not for provisioning the configuration of network infrastructure devices like switches or routers.
C. SNMP: The Simple Network Management Protocol (SNMP) is used for managing and monitoring devices that are already operational on a network. It is not a mechanism for initial, "day-zero" device provisioning from a factory-default state. ---

1. Cisco Systems

Inc. (2023). Programmability Configuration Guide

Cisco IOS XE Amsterdam 17.3.x.

Section: "Zero-Touch Provisioning"

Content: "ZTP allows you to provision new switches in your network automatically

without manual intervention. When a switch with the ZTP feature is powered on with a factory default configuration

it searches for a DHCP server

gets the IP address and default gateway

and automatically downloads the image and configuration file from the TFTP/HTTP server." This directly confirms the process described in the question as ZTP.

2. Cisco Systems

Inc. (2023). System Management Configuration Guide

Cisco IOS XE Bengaluru 17.6.x.

Section: "Configuring Network Plug-and-Play"

Content: This document describes the PnP agent on a device communicating with a PnP server. It uses DHCP Option 43 to discover the server

highlighting it as a specific

controller-based implementation rather than the generic DHCP/TFTP process itself.

3. Arista Networks. (2023). Arista EOS 4.29.2F Manual.

Section: "Zero Touch Provisioning (ZTP)"

Content: "On boot

a factory-defaulted switch with ZTP enabled first attempts to obtain an IP address via DHCP. [...] The DHCP offer can also contain the location of a startup-config or boot script." This shows that ZTP

as a concept using DHCP and file servers (like TFTP)

is an industry-standard term

not just specific to Cisco.

In the RESTCONF protocol, the HTTP PUT method is used to completely replace the target data resource. If the resource exists, it is replaced; if it does not exist, it is created. The Python requests library directly maps HTTP methods to its functions. Therefore, to replace a device configuration, an automation engineer would use the requests.put() function to send a PUT request to the appropriate RESTCONF API endpoint with the new configuration in the request body.

A. delete(): This method corresponds to the HTTP DELETE verb, which is used to remove a resource, not replace it.
B. post(): This method corresponds to the HTTP POST verb, which is used to create a new data resource within a collection or to invoke an RPC.
D. patch(): This method corresponds to the HTTP PATCH verb, which is used to partially modify or merge data into an existing resource, not replace it entirely. ---

1. RFC 8040 - RESTCONF Protocol:

Section 4.5

"Replacing a Resource": "The PUT method is used to replace the target data resource... If the target resource exists

it is replaced. If the target resource does not exist

it is created." This section explicitly defines the role of the PUT method for resource replacement.

Section 4.4

"Creating a Resource": This section details the use of POST for creation.

Section 4.6

"Modifying a Resource": This section details the use of PATCH for partial modification.

Section 4.7

"Deleting a Resource": This section details the use of DELETE for removal.

2. Cisco IOS XE Programmability Configuration Guide

Cisco IOS XE 17.x:

Chapter: "RESTCONF Protocol"

Section: "RESTCONF Requests and Responses": This documentation confirms the standard HTTP method usage for RESTCONF on Cisco devices. It specifies that "To replace the contents of the resource identified by the target URI

use the PUT method."

3. Python Requests Library Official Documentation:

Section: "Quickstart"

Subsection: "Make a Request": The documentation shows the direct mapping of HTTP methods to function calls

stating: r = requests.put('https://httpbin.org/put'

data={'key':'value'}). This confirms put() is the function for an HTTP PUT request.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/300-435/page_59_img_2.jpg

The Python script sends a NETCONF request to the router. The core of this request is the XML payload, which targets the Loopback interface with a name of 2. The key directive is the attribute nc:operation="delete" applied directly to the element. According to the NETCONF protocol standard (RFC 6241), when the delete operation is applied to a data node (in this case, the entire element), the entire corresponding configuration entry is removed from the target datastore. Therefore, the entire interface Loopback2 configuration, including its description and IP address, is deleted from the router's running configuration.

A. The delete operation explicitly modifies the configuration; it does not leave the interface description or any part of the interface configuration unchanged.
B. The XML payload is well-formed, and nc:operation="delete" is a standard, valid NETCONF operation. The router will accept and execute this command.
D. The delete operation is specified on the parent element, not the child element, resulting in the deletion of the entire interface, not just its description.

1. RFC 6241 - NETCONF Configuration Protocol: Section 7.2, Operation. This section defines the operation attribute. It states for the delete value: "The configuration data identified by the element containing this attribute is deleted from the configuration datastore... if the configuration data currently exists...". In the exhibit, the element containing the attribute is , thus the entire interface is deleted.

2. Cisco IOS XE Programmability Configuration Guide, Release 17.x: In the "NETCONF Protocol" chapter, the section on "NETCONF edit-config Operations" details how Cisco IOS XE implements the standard NETCONF operations defined in RFC 6241. It confirms that applying a delete operation to an interface container will remove the entire interface configuration.

3. Yang, L. (2016). Network programmability and automation: Skills for the next-generation network engineer. O'Reilly Media, Inc. Chapter 4, "NETCONF," explains the protocol's operations. It provides examples showing that an operation="delete" attribute on a list element (like an interface) removes the entire instance of that list element.

A Python virtual environment provides a self-contained directory tree that includes a specific Python interpreter and its own set of installed packages. The primary benefit is isolation. This allows a developer to work on a project with specific library versions without affecting the system-wide Python installation or other projects on the same machine. Each project can have its own distinct environment, preventing dependency conflicts and ensuring that the application's dependencies are managed independently. This is crucial for creating reproducible and stable development and deployment workflows.

A. This describes distributed or parallel computing, which is a system architecture concern, not a function of Python virtual environments.
B. Concurrency and multithreading are programming paradigms supported by Python's core libraries (e.g., asyncio, threading), independent of virtual environments.
C. A virtual environment does not inherently make an application cross-platform; code portability depends on the application's logic and library compatibility.

1. Python Software Foundation, Official Documentation, "venv — Creation of virtual environments": "The venv module supports creating lightweight “virtual environments”, each with their own independent set of Python packages installed in their site directories. A virtual environment is created on top of an existing Python installation... and is isolated from the packages in the base installation." (Source: https://docs.python.org/3/library/venv.html, Introduction section)

2. Python Software Foundation, The Python Tutorial, "12. Virtual Environments and Packages": "The solution for this problem is to create a virtual environment, a self-contained directory tree that contains a Python installation... Different applications can then use different virtual environments. To resolve the earlier example of conflicting requirements, application A can have its own virtual environment with version 1.0 installed while application B has another virtual environment with version 2.0." (Source: https://docs.python.org/3/tutorial/venv.html, Section 12.1 Introduction)

3. Stanford University, Code in Place Courseware, "Virtual Environments": "A virtual environment is a way to have an isolated python installation. This is useful because it means that packages you install for one project don't affect other projects. It is considered good practice to have a different virtual environment for every python project you work on." (Source: https://codeinplace.stanford.edu/cip3/share/pysetup/venv.html, Introduction section)

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/300-435/page_81_img_1.jpg

The provided configuration for the telemetry subscription (telemetry ietf subscription 101) defines what data to send (filter xpath), how to encode it (encoding encode-kvgpb), and how often to send it (update-policy periodic 500). However, it is missing the crucial information of where to send the data. The subscription must include a configured receiver, which specifies the destination IP address, port, and transport protocol for the telemetry stream. Without the receiver command, the device has no destination for the data, and consequently, no telemetry packets are sent to the consumer.

B. The stream type yang-push is a valid and appropriate setting for periodically pushing YANG-modeled data, which is what this subscription is configured to do.
C. The update policy period of 500 centiseconds (5 seconds) is a valid frequency. Changing this value would only alter how often data is sent, not fix the issue of no data being sent at all.
D. Specifying a sender (source) IP address is an optional parameter. If not configured, the device will automatically select the IP address of the appropriate egress interface based on its routing table.

1. Cisco IOS XE Programmability Configuration Guide, Release 17.9.x, "Model-Driven Telemetry" chapter, "Configuring a Telemetry Subscription" section. The configuration examples for static subscriptions consistently demonstrate the mandatory inclusion of the receiver ip address protocol command within the subscription definition to specify the data destination. The guide states, "To configure a telemetry subscription, you must specify the receiver details..."

2. Cisco IOS XE Programmability Configuration Guide, Release 17.9.x, "Model-Driven Telemetry" chapter, "Telemetry Command Reference" section. The documentation for the telemetry ietf subscription command lists receiver as a key sub-command required to "Configure the receiver IP address, port, and protocol." The absence of this sub-command results in an incomplete configuration that cannot be activated to stream data.

According to the official Cisco DNA Center Intent API documentation, the GET /dna/intent/api/v1/device-detail endpoint is used to retrieve detailed information about a specific device. This endpoint requires two query parameters: searchBy and identifier. The searchBy parameter specifies the attribute to use for the search, and the documentation explicitly lists "MAC Address", "device id", or "device name" as the only valid values. Therefore, "MAC address" is an acceptable value for this parameter.

A. Platform type is not a supported value for the searchBy parameter in this specific API endpoint.
B. IP address is not a valid value for the searchBy parameter; other API calls might use IP, but not this one.
C. Software version is not a valid search criterion for the searchBy parameter as per the API specification.

1. Cisco DNA Center Platform API Reference

Devices > Get Device Detail. Cisco Developer. Accessed [Current Date].

Reference Details: In the documentation for the GET /dna/intent/api/v1/device-detail endpoint

under the "Query Parameters" section

the description for the searchBy parameter states: "MAC Address or device id or device name of the device to be searched". This directly confirms that "MAC address" is a valid option.

URL: https://developer.cisco.com/docs/dna-center/#!get-device-detail