Automation and Programmability

200 questions

Question 81Question

An enterprise network engineering team is evaluating configuration management mechanisms to automate switch provisioning across a campus infrastructure. The network security policy strictly mandates that the selected tool must not require client agent software installation on target devices, must execute configuration pushes on-demand directly from a centralized control node over standard secure transport protocols, and must utilize YAML formatting for configuration code files. Which tool and architectural combination satisfies all specified security and operational requirements?

Show answer & explanation

Answer: Ansible operating with an agentless push architecture using SSH or NETCONF transport and YAML playbooks

Answer

Ansible operating with an agentless push architecture using SSH or NETCONF transport and YAML playbooks
The correct option accurately reflects Ansible's core architecture. Ansible is strictly agentless, requiring no software installation on network nodes. It relies on a centralized push execution model over standard management protocols such as SSH or NETCONF and uses human-readable YAML files structured as playbooks.

Step-by-Step Solution

1
Analyze the constraint requiring no client agent installation on target network switches.
Identifies Ansible as an agentless tool, eliminating traditional agent-based models like Puppet and Chef.
Ansible communicates with network nodes without installing specialized client software by leveraging native protocols like SSH and NETCONF.
2
Analyze the operational direction requirement (on-demand central push vs. client pull).
Confirms Ansible uses a push architecture where the control node initiates configuration deployment.
Puppet and Chef natively operate on a pull model where managed agents poll the master server periodically.
3
Evaluate the file format requirement specified in the policy (YAML).
Validates that Ansible uses YAML for its Playbooks.
Puppet uses its proprietary Puppet DSL (or Ruby), and Chef uses Ruby DSL for recipes and cookbooks.

Key Concept

Capabilities and Operational Models of Configuration Management Tools (Ansible vs. Puppet vs. Chef)
Question 82Question

An enterprise network administrator deploys a Cisco SD-Access fabric overlay using VXLAN for data plane encapsulation over an OSPF-based Layer 3 routed underlay network. During validation, control plane communication between the LISP Control Plane Node and Fabric Edge switches operates normally, and all underlay loopback interfaces show full ping reachability. However, host endpoints in different subnets attached to separate Fabric Edge switches fail to communicate, with packet captures revealing that encapsulated data packets are dropped by transit routers along the underlay path. Which underlay infrastructure condition is causing this traffic delivery failure?

Show answer & explanation

Answer: The Maximum Transmission Unit (MTU) on intermediate underlay router interfaces is set to 1500 bytes, causing VXLAN encapsulated frames with DF flags set to be dropped.

Answer

The MTU on intermediate underlay router interfaces is configured to the standard 1500-byte limit without accounting for VXLAN encapsulation overhead, leading to packet drops along the routed transit path.
In software-defined fabric architectures using VXLAN encapsulation (such as Cisco SD-Access), outer headers add at least 50 bytes of overhead to every packet transmitted between Fabric Edge nodes. Because VXLAN packets typically set the Don't Fragment (DF) bit in the outer IP header, intermediate underlay routers with a standard 1500-byte MTU cannot forward packets exceeding 1500 bytes and will drop them. Therefore, the underlay network interfaces must be configured with an elevated MTU (e.g., 9000 bytes for jumbo frames or at least 1550 bytes) to accommodate the overlay encapsulation.

Step-by-Step Solution

1
Analyze the role of the underlay and overlay components in a fabric architecture.
The underlay provides Layer 3 IP reachability between Fabric Edge loopback interfaces (RLOCs). The overlay uses VXLAN encapsulation to tunnel Layer 2/Layer 3 payload between endpoints.
Understanding the separation of underlay transport and overlay encapsulation isolates where packet processing issues occur.
2
Calculate the header overhead introduced by VXLAN encapsulation.
VXLAN encapsulation adds an outer UDP header (8 bytes), VXLAN header (8 bytes), outer IP header (20 bytes), and outer Ethernet header (14 bytes), totaling 50 bytes of additional encapsulation header.
A standard 1500-byte IP packet becomes 1550 bytes after VXLAN encapsulation.
3
Determine the impact of underlay interface MTU on encapsulated packets with Don't Fragment (DF) bits set.
If transit underlay interfaces retain the default 1500-byte MTU, any 1500-byte host payload encapsulated in a 1550-byte VXLAN packet will exceed the MTU and be dropped by underlay routers.
To support VXLAN fabric overlay traffic, all underlay routed links and switch interfaces must have jumbo frames or an increased MTU (minimum 1550–1600 bytes, typically 9000 bytes) configured.

Key Concept

Underlay MTU Requirements for VXLAN Overlay Encapsulation
Estimated Time:2m 0s
Question 83Question

An administrator needs to modify only the target syslog server address on a network device via a RESTCONF API. The existing target resource container contains configuration attributes for syslog logging levels, facility settings, and buffer sizes. To update the server address without deleting or overwriting the unreferenced logging attributes within that resource container, which HTTP verb and header combination must be transmitted?

Show answer & explanation

Answer: HTTP PATCH verb with Content-Type: application/yang-data+json

Answer

HTTP PATCH verb with Content-Type: application/yang-data+json
The HTTP PATCH verb is designed for partial resource modification. When modifying a sub-element (such as a syslog server IP) inside an existing resource container, PATCH applies changes only to the keys included in the request payload while preserving unreferenced parameters such as facility settings and buffer sizes.

Step-by-Step Solution

1
Identify the required CRUD operation
The operation requires a partial update to modify specific fields within an existing configuration container without affecting existing untouched parameters.
Understanding whether the intent is partial modification or complete resource replacement dictates the choice between REST HTTP verbs.
2
Map the required operation to the correct HTTP verb
The HTTP PATCH verb corresponds to partial update in REST API architecture.
HTTP PUT replaces the complete resource object, whereas HTTP PATCH updates only the supplied fields.
3
Verify payload format headers for RESTCONF data interaction
RESTCONF uses specialized media type headers such as application/yang-data+json to process JSON payload data structures.
Correct HTTP Content-Type headers ensure the target API parser interprets the body syntax properly.

Key Concept

REST HTTP Verbs vs CRUD Operations (PUT vs PATCH differences)
Estimated Time:1m 0s
Question 84Question

A network automation engineer sends an HTTP GET request to a Cisco IOS XE RESTCONF endpoint to check IP SLA operation status. The API returns the following JSON payload:

{
"Cisco-IOS-XE-sla:sla": {
"ip-sla": [
{
"oper-id": 101,
"type": "icmp-echo",
"destination": "192.168.50.1",
"stats": {
"rtt-ms": 14,
"state": "active",
"history": [
{"sample-id": 1, "rtt": 12, "success": true},
{"sample-id": 2, "rtt": 16, "success": true}
]
}
},
{
"oper-id": 102,
"type": "udp-jitter",
"destination": "10.10.20.5",
"stats": {
"rtt-ms": 4,
"state": "inactive",
"history": [
{"sample-id": 1, "rtt": 4, "success": false}
]
}
}
]
}
}

Based on the JSON payload provided above, match each data extraction path on the left to its correct extracted value and data type on the right.

Click a left item, then click its matching right item

Items

`Cisco-IOS-XE-sla:sla` → `ip-sla[0]` → `stats` → `state`
`Cisco-IOS-XE-sla:sla` → `ip-sla[1]` → `destination`
`Cisco-IOS-XE-sla:sla` → `ip-sla[0]` → `stats` → `history[1]` → `rtt`
`Cisco-IOS-XE-sla:sla` → `ip-sla[1]` → `stats` → `history[0]` → `success`

Matches

Show answer & explanation

Answer

The correct matches map each zero-indexed JSON array path to its corresponding value and type: `ip-sla[0]->stats->state` maps to `"active" (String)`, `ip-sla[1]->destination` maps to `"10.10.20.5" (String)`, `ip-sla[0]->stats->history[1]->rtt` maps to `16 (Number)`, and `ip-sla[1]->stats->history[0]->success` maps to `false (Boolean)`.
All four extraction paths correctly evaluate zero-based array indices (`[0]` for first element, `[1]` for second element) and trace object key structures to their exact primitive values and data types.

Step-by-Step Solution

1
Locate top-level keys and array indices
The top-level key `Cisco-IOS-XE-sla:sla` contains an array named `ip-sla`. Index `[0]` refers to the first object (`oper-id` 101), and index `[1]` refers to the second object (`oper-id` 102).
JSON arrays use zero-based indexing, where the first element is at index 0.
2
Extract direct keys from array elements
For `ip-sla[0] -> stats -> state`, the value is `"active"`. For `ip-sla[1] -> destination`, the value is `"10.10.20.5"`.
Navigating directly through key-value maps yields the string values bound to those keys.
3
Traverse nested array elements and primitives
For `ip-sla[0] -> stats -> history[1] -> rtt`, index `[1]` of `history` points to sample-id 2, returning `16`. For `ip-sla[1] -> stats -> history[0] -> success`, index `[0]` points to sample-id 1, returning `false`.
Properly indexing sub-arrays prevents off-by-one errors and identifies data types such as numbers vs. booleans.

Key Concept

Traversing nested JSON objects and zero-indexed arrays returned by Cisco REST APIs.
Question 85Question

A network automation engineer is developing a Python script to interact with a Cisco REST-based API controller. Which two statements accurately describe the characteristics of HTTP headers, verbs, or data formats in REST APIs? (Select two.)

Select all that apply

Show answer & explanation

Answer: The Content-Type request header informs the API server about the data format contained within the HTTP request body.; JSON data payloads support native data types including strings, numbers, booleans, key-value objects, and arrays.

Answer

The statement that the Content-Type header informs the server of the request body format and the statement that JSON natively supports strings, numbers, booleans, objects, and arrays are both correct.
The Content-Type request header notifies the server of the data format (e.g., application/json) contained within the HTTP request body. Additionally, JSON natively supports data types such as strings, numbers, booleans, objects (dictionaries), and arrays (lists).

Step-by-Step Solution

1
Analyze HTTP request headers in RESTful communications.
Content-Type specifies the format of the data being sent to the server in the request body. Accept specifies the format expected in the response payload.
Header roles must be distinguished: Content-Type describes outgoing body data, while Accept describes incoming body preferences.
2
Evaluate data format characteristics for JSON payloads.
JSON structure contains primitive types (strings, numbers, booleans, null) and complex types (objects enclosed in {}, arrays enclosed in []).
JSON is a standard data format used heavily in REST APIs.
3
Assess HTTP verb idempotence.
GET, PUT, and DELETE are idempotent methods. POST is non-idempotent because repeating it creates new resources.
Idempotency means repeating an HTTP request produces the same result on the server state.

Key Concept

Characteristics of REST HTTP headers (Content-Type vs Accept), HTTP verb idempotency, and JSON data structures.
Estimated Time:1m 30s
Question 86Question

An automation script executes an HTTP GET request to a Cisco RESTCONF API endpoint. The router responds with the following JSON payload:

{
"ietf-interfaces:interface": {
"name": "GigabitEthernet1",
"description": "Uplink to Core",
"type": "iana-if-type:ethernetCsmacd",
"enabled": true,
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.168.1.1",
"netmask": "255.255.255.0"
}
]
}
}
}

What is the value of the "description" key in this interface configuration?

Show answer & explanation

Answer: Uplink to Core

Answer

Uplink to Core
In the provided JSON object, the string key 'description' maps directly to the value 'Uplink to Core'.

Step-by-Step Solution

1
Locate the key named "description" within the root "ietf-interfaces:interface" JSON object.
The key "description" is identified in the object.
JSON formatted data maps unique key strings to corresponding values using colons.
2
Extract the string value assigned after the colon for the "description" key.
The value extracted is "Uplink to Core".
The string enclosed in quotes following "description": represents the value.

Key Concept

JSON Key-Value Pair Extraction
Question 87Question

An enterprise network implements a Cisco Software-Defined Access (SD-Access) solution where two endpoints residing on different IP subnets communicate across a campus fabric. Fabric Edge Switch 1 encapsulates packets from Endpoint A destined for Endpoint B on Fabric Edge Switch 2. Which two statements correctly describe the operational roles and behaviors of the underlay and overlay networks during this communication flow?

Select all that apply

Show answer & explanation

Answer: The underlay network uses standard Layer 3 routing protocols to provide IP reachability exclusively between the Routing Locator (RLOC) addresses of the fabric edge nodes.; The overlay network encapsulates original host packets inside VXLAN headers containing outer source and destination IP addresses corresponding to the fabric edge RLOCs.

Answer

The correct statements are that the underlay network provides Layer 3 IP reachability strictly between fabric edge node Routing Locators (RLOCs) using standard routing protocols, and the overlay network encapsulates host frames using VXLAN with outer IP headers addressing those RLOCs.
In a Cisco SD-Access fabric, the underlay network is responsible solely for providing robust Layer 3 IP connectivity between fabric node loopback addresses, known as Routing Locators (RLOCs). The overlay network abstracts endpoint traffic by using VXLAN encapsulation at the ingress fabric edge node, wrapping the original packet inside an outer IP header directed to the egress fabric edge node's RLOC.

Step-by-Step Solution

1
Identify the primary responsibility of the underlay network in a software-defined fabric.
The underlay consists of physical switches, routers, and Layer 3 links running an IGP (such as IS-IS or OSPF) to establish IP reachability between node loopbacks (RLOCs).
The underlay functions purely as a IP transport mechanism for outer tunnel traffic without tracking endpoint host routes or overlay VLANs.
2
Analyze how the overlay data plane handles host packet transport across the fabric.
Fabric Edge Switch 1 acts as a VXLAN Tunnel Endpoint (VTEP), wrapping the host's original Layer 2 frame/Layer 3 packet into a VXLAN header and outer UDP/IP header with source RLOC of Edge 1 and destination RLOC of Edge 2.
VXLAN encapsulation isolates endpoint addressing (EIDs) from the physical topology and enables virtualized Layer 2 and Layer 3 overlays.
3
Evaluate intermediate underlay device functions to eliminate incorrect options.
Intermediate core/distribution switches in the underlay route packets based solely on the outer IP header (destination RLOC). They do not run LISP, decapsulate VXLAN, or inspect inner MAC/IP headers.
Maintaining clear separation between underlay transport routing and overlay control/data plane operations keeps the network core simple, scalable, and stateless regarding endpoints.

Key Concept

Underlay vs. Overlay Separation in SDN Fabric Architectures
Question 88Question

A network engineer is inspecting traffic behavior on a multilayer switch operating within a controller-managed fabric network. An ingress data packet matching an existing destination entry in the Forwarding Information Base (FIB) arrives at a switch port. At the same moment, an OSPF Hello packet arrives on the same physical port. Which statement correctly describes how the switch architecture handles these two incoming frames?

Show answer & explanation

Answer: The ingress data packet is forwarded directly by the data plane using specialized ASIC hardware, while the OSPF Hello packet is punted to the control plane CPU for processing.

Answer

The ingress data packet is forwarded directly by the data plane using specialized ASIC hardware, while the OSPF Hello packet is punted to the control plane CPU for processing.
In modern networking devices and SDN architectures, the data plane (forwarding plane) utilizes specialized hardware (ASICs and TCAM) to forward transit user traffic at line rate based on pre-calculated table entries (FIB and Adjacency tables). Conversely, control plane protocols (such as OSPF, BGP, and ARP) require protocol state processing and decision logic, which is handled by the control plane CPU. Therefore, the data packet is switched in hardware by the data plane, while the OSPF Hello frame is punted to the control plane CPU.

Step-by-Step Solution

1
Identify the plane responsible for fast-path data packet forwarding.
Established that user data matching an established FIB entry is handled entirely by the data plane (dataplane/forwarding plane) via hardware ASICs and TCAM without CPU intervention.
Hardware ASICs provide line-rate throughput by offloading packet switching from the main CPU.
2
Identify the plane responsible for routing protocol processing and state maintenance.
Determined that OSPF control messages (such as Hello packets) require complex state processing and must be punted to the control plane CPU.
Control plane processes (OSPF, EIGRP, BGP, ARP) maintain network intelligence and build the Routing Information Base (RIB), which then populates the data plane FIB.

Key Concept

Separation of Control Plane and Data Plane Responsibilities
Question 89Question

A network monitoring application sends an HTTP GET request to a Cisco DNA Center REST API endpoint to retrieve device health metrics. The request header includes `Accept: application/json`. Which outcome occurs as a result of including this request header?

Show answer & explanation

Answer: The API controller returns the requested health metrics formatted as a JSON payload in the HTTP response.

Answer

The API controller returns the requested health metrics formatted as a JSON payload in the HTTP response.
The `Accept` request header allows a client to specify the media type (such as `application/json`) it expects to receive in response from a REST API server. When the server processes the HTTP GET request, it formats the requested data payload as JSON before returning it to the client.

Step-by-Step Solution

1
Analyze the HTTP verb specified in the API call.
The request uses HTTP GET, which maps to the Read operation in CRUD.
HTTP GET is safe and idempotent, designed solely to fetch existing data without modifying server state.
2
Evaluate the function of the `Accept` HTTP header field.
The `Accept: application/json` header informs the server of the data format preferred by the client for the HTTP response body.
`Accept` governs response format expectations, whereas `Content-Type` specifies the format of the request payload body.
3
Synthesize the verb action and header context.
The controller processes the GET request and sends back the requested data encoded in JSON.
This behavior directly reflects standard REST API architecture conventions.

Key Concept

HTTP Headers and Data Formats in REST APIs
Question 90Question

A network technician uses a REST API call to retrieve VLAN configuration data from a Cisco switch. The device returns the following JSON payload:

{
"response": {
"vlan_list": [
{
"vlan_id": 10,
"name": "Management",
"active": true
},
{
"vlan_id": 20,
"name": "Engineering",
"active": false
}
],
"total_vlans": 2
}
}

Based on this JSON payload, which of the following statements are correct? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: The key "vlan_list" contains an array of JSON objects enclosed in square brackets.; The value for the key "active" in the "Engineering" VLAN object is an unquoted boolean data type.

Answer

The key "vlan_list" contains an array of JSON objects, and the value for "active" in the Engineering VLAN is a boolean data type.
The payload uses square brackets `[]` under `vlan_list` to represent an array of objects. Additionally, the value `false` assigned to `active` is unquoted, which correctly identifies it as a native JSON boolean data type.

Step-by-Step Solution

1
Inspect the syntax following the key "vlan_list".
The value starts with square brackets `[ ... ]`, which defines a JSON array containing two curly-brace `{ ... }` dictionary objects.
Square brackets signify arrays in JSON, whereas curly braces denote standalone key-value objects.
2
Analyze the data type assigned to the key "active" inside the second array item.
The second object has `"name": "Engineering"` and `"active": false` without quotation marks around `false`.
Unquoted `true` or `false` values represent boolean data types in JSON syntax.
3
Evaluate the remaining keys and data types.
`"total_vlans": 2` contains an unquoted numerical value (integer), not a string.
String values in JSON must always be wrapped in double quotes (e.g., `"2"`).

Key Concept

Interpreting JSON syntax elements including arrays, objects, strings, numbers, and boolean data types.
Question 91Question

A network security policy requires that all configuration management operations across remote branch routers strictly prevent inbound session initiation from central management servers to remote devices. Outbound HTTPS traffic on TCP port 443 initiated by target devices toward the central server is permitted. Which configuration management tool natively meets these architectural constraints while utilizing Ruby-based files to define system state?

Show answer & explanation

Answer: Chef, because it uses an agent-based pull architecture operating over TCP port 443 and defines configurations using Ruby DSL recipes.

Answer

Chef natively operates using an agent-based pull architecture over TCP port 443 (HTTPS) and relies on Ruby-based recipes contained within cookbooks to define device configuration states.
Chef employs an agent installed on managed devices that initiates outbound communication to the central Chef Server over TCP port 443 (HTTPS) to pull its configuration state. Configurations in Chef are authored using a Ruby-based Domain-Specific Language (DSL) organized into recipes and cookbooks, perfectly matching both the port and architectural requirements.

Step-by-Step Solution

1
Analyze the operational direction constraint (inbound vs. outbound).
Since security policies prohibit inbound sessions initiated by the central server, the configuration management system must use a pull-based architecture where the managed node initiates outbound connections.
Chef and Puppet both natively use agent-based pull models, while Ansible primarily uses a push model (where the control node initiates SSH/NETCONF inbound to managed nodes).
2
Evaluate the required transport port and configuration definition language.
Chef client agents initiate outbound HTTPS requests to the Chef server over standard TCP port 443 and parse configuration definitions written in Ruby DSL (recipes/cookbooks). Puppet typically uses TCP port 8140 for agent-master pull communications.
Identifying both the network protocol/port and the underlying formatting language isolates Chef as the correct tool.

Key Concept

Configuration Management Tools Architecture and Capabilities (Ansible vs. Puppet vs. Chef)
Question 92Question

An enterprise network architect is creating documentation to clarify plane responsibilities and interfaces in traditional versus software-defined controller-based architectures. Match each operational task or network behavior on the left to the corresponding architectural component or interface model on the right.

Click a left item, then click its matching right item

Items

Independent, hop-by-hop calculation of routing topology and state maintenance on each individual device
Exposure of RESTful APIs allowing external management applications and scripts to communicate intent to the controller
Provisioning and device configuration management via protocols like NETCONF and RESTCONF from the central controller to nodes
Line-rate frame switching and packet forwarding performed locally in ASIC hardware based on FIB tables

Matches

Show answer & explanation

Answer

Independent hop-by-hop topology calculation pairs with Traditional Distributed Control Plane; RESTful API exposure to management applications pairs with Controller Northbound Interface (NBI); Device provisioning via NETCONF/RESTCONF pairs with Controller Southbound Interface (SBI); Line-rate ASIC forwarding pairs with Controller-Based Data Plane (SDN Data Plane).
Independent routing calculations define traditional distributed control planes where every node operates autonomously. Northbound interfaces expose REST APIs for applications to automate network policies through the controller. Southbound interfaces enable the controller to program and monitor network elements using protocols such as NETCONF or RESTCONF. Localized ASIC-based forwarding represents the data plane, which continues to reside on physical network hardware in both traditional and controller-based models.

Step-by-Step Solution

1
Analyze the operational task of independent local routing topology calculation.
Corresponds to the Traditional Distributed Control Plane.
Traditional devices run distributed control algorithms (like OSPF or EIGRP) on each node independently.
2
Analyze the role of RESTful APIs communicating intent from applications to the controller.
Corresponds to the Controller Northbound Interface (NBI).
Northbound interfaces face upward toward orchestrators, business logic, and applications.
3
Analyze the role of protocols pushing configuration down from controller to network nodes.
Corresponds to the Controller Southbound Interface (SBI).
Southbound interfaces face downward from the controller to manage physical or virtual infrastructure switches and routers.
4
Analyze line-rate hardware forwarding in ASIC hardware.
Corresponds to the Controller-Based Data Plane.
Data plane packet forwarding remains local to network hardware to handle traffic without sending every packet to the central controller.

Key Concept

Distinction between control plane, data plane, Northbound APIs, and Southbound APIs in traditional vs controller-based architectures.
Estimated Time:1m 30s
Question 93Question

A network automation engineer is building a Python script to interact with a Cisco REST-based API. Match each HTTP request verb on the left to its corresponding operational characteristic or CRUD function on the right.

Click a left item, then click its matching right item

Items

POST
GET
PUT
PATCH

Matches

Show answer & explanation

Answer

POST matches with creating a new resource under a target URI, GET matches with retrieving resource representation without making modifications, PUT matches with replacing the entire target resource with the provided payload, and PATCH matches with applying partial modifications to specific fields of an existing resource.
Each HTTP verb directly aligns with specific REST CRUD semantics: POST creates new resources under an endpoint; GET retrieves existing resource states safely; PUT overwrites and completely replaces the target resource entity; and PATCH modifies select attributes of an existing resource without disturbing unreferenced attributes.

Step-by-Step Solution

1
Identify the primary CRUD operations for retrieve and create actions in REST APIs.
POST corresponds to resource creation (Create), while GET corresponds to retrieving data (Read).
GET is an idempotent and safe read-only operation, whereas POST sends data to create a new resource entry.
2
Distinguish between full replacement (PUT) and partial update (PATCH) behaviors.
PUT completely overwrites the existing target resource, while PATCH modifies only specified resource fields.
PUT requires a complete resource representation in the request payload, whereas PATCH updates targeted attributes without modifying omitted fields.

Key Concept

REST HTTP Verbs to CRUD Operations Mapping
Question 94Question

A network automation workflow uses RESTCONF to manage interface configurations on Cisco IOS XE routers. An engineer sends an HTTP PUT request to the URI endpoint of an existing interface resource (`.../ietf-interfaces:interfaces/interface=GigabitEthernet1`). The JSON payload included in the request contains only the updated `description` attribute and omits previously configured child attributes such as `ip` and `enabled`. Which outcome will occur on the target device when this request is processed?

Show answer & explanation

Answer: The interface description is updated, but any omitted attributes, such as the IP address configuration, are cleared or reset to their default values.

Answer

The interface description is updated, but any omitted attributes, such as the IP address configuration, are cleared or reset to their default values.
In REST-based APIs, HTTP PUT is defined as a full replacement operation (Update/Replace). When sending a PUT request to an existing resource URI, the server overwrites the entire target resource with the data provided in the request body. Any attributes omitted from the JSON payload will be removed or reset to default state. If partial updates are intended without affecting existing unmentioned attributes, HTTP PATCH must be used instead.

Step-by-Step Solution

1
Identify the HTTP verb used in the REST API request.
The request utilizes the HTTP PUT method targeted at an existing resource endpoint.
Understanding the operational contract of HTTP verbs is critical for RESTful API interactions.
2
Distinguish between HTTP PUT and HTTP PATCH resource modifications.
HTTP PUT specifies a complete resource replacement, while HTTP PATCH specifies a partial modification.
Because the request uses PUT, any field not explicitly included in the request payload will be deleted or reset to default settings upon resource replacement.

Key Concept

HTTP PUT vs PATCH Operational Differences in REST APIs
Question 95Question

A network administrator receives the following JSON payload from a Cisco DNA Center REST API request:

{
"response": [
{
"hostname": "Switch-Core-01",
"managementIp": "10.1.10.1"
},
{
"hostname": "Switch-Access-01",
"managementIp": "10.1.20.15"
}
]
}

What is the value of `response[1]["managementIp"]` in this JSON structure?

Show answer & explanation

Answer: "10.1.20.15"

Answer

The value of `response[1]["managementIp"]` is "10.1.20.15".
JSON uses 0-based indexing for array structures defined by square brackets (`[]`). The key `"response"` maps to an array containing two objects. The first element at index `0` corresponds to `Switch-Core-01`, and the second element at index `1` corresponds to `Switch-Access-01`. Accessing key `"managementIp"` on the second element yields `"10.1.20.15"`.

Step-by-Step Solution

1
Locate the top-level key named "response".
The key "response" contains an array holding two object structures.
Top-level access requires locating the target key first.
2
Apply the array index [1] using 0-based indexing.
Index [0] corresponds to the first object (Switch-Core-01), while index [1] targets the second object (Switch-Access-01).
JSON arrays use 0-based indexing.
3
Extract the value associated with the key "managementIp" from the second object.
The key "managementIp" maps to the string value "10.1.20.15".
Accessing the key within the targeted dictionary/object yields its corresponding value.

Key Concept

JSON Data Structure Traversal and Zero-Based Array Indexing
Question 96Question

A network administrator is evaluating the operational differences when transitioning an enterprise campus network from traditional distributed networking to a centralized controller-based architecture. Which operational feature uniquely distinguishes the controller-based architecture from the traditional network model during configuration and policy deployment?

Show answer & explanation

Answer: Network policies and configurations are centrally orchestrated at the controller layer and programmatically applied to network devices using Southbound APIs.

Answer

Network policies and configurations are centrally orchestrated at the controller layer and programmatically applied to network devices using Southbound APIs.
In controller-based networking architectures, management and control intelligence are centralized. Network administrators specify high-level policies at the controller, which then automatically provisions and manages network devices using Southbound APIs (such as NETCONF, RESTCONF, or OpenFlow). This eliminates the need for manual, device-by-device CLI configurations typical of traditional networks.

Step-by-Step Solution

1
Analyze traditional network management operational mechanics.
In traditional networking, the control plane and data plane reside on each individual device, requiring hop-by-hop configuration updates (typically via CLI or SNMP).
Understanding traditional distributed management establishes the baseline comparison.
2
Analyze controller-based software-defined networking (SDN) operational mechanics.
Controller-based networking decouples or centralizes control logic into a controller. Administrators define policy on the controller (or via Northbound APIs), and the controller uses Southbound APIs (e.g., NETCONF, RESTCONF, OpenFlow) to communicate with physical switches and routers.
This identifies the key operational shift to centralized orchestration and Southbound API device communication.
3
Evaluate option choices to identify the correct distinguishing operational feature.
Centralized orchestration pushing configurations via Southbound APIs correctly reflects SDN architecture.
It highlights the direct architectural role of the SDN controller and Southbound interfaces.

Key Concept

Traditional vs. Controller-Based Network Architecture and Interface Roles
Question 97Question

In a modern enterprise network transitioning from traditional routing to a software-defined fabric architecture, different operational tasks are assigned to distinct functional planes. Match each specific network task or protocol operation to the corresponding architectural plane responsible for executing it.

Click a left item, then click its matching right item

Items

Processing gNMI streaming telemetry and executing REST API configuration calls from an administrative platform
Building the local Routing Information Base (RIB) and processing incoming OSPF Hello packets on the switch CPU
Performing wire-speed ASIC TCAM table lookups and handling VXLAN header encapsulation for ingress data frames
Maintaining fabric-wide LISP endpoint mapping databases and dynamically pushing control policies to edge nodes

Matches

Show answer & explanation

Answer

Processing gNMI/REST APIs matches Management Plane; Building local RIB and OSPF Hellos matches Distributed (Local) Control Plane; ASIC TCAM lookups and VXLAN encapsulation matches Data Plane (Forwarding Plane); Maintaining LISP mapping database matches Centralized Controller Control Plane.
Administrative monitoring and programmatic configuration interfaces (gNMI/REST APIs) reside in the Management Plane. Local routing engine tasks like OSPF neighbor maintenance and RIB construction execute within the Distributed (Local) Control Plane on the device CPU. Hardware-accelerated packet switching, TCAM lookups, and VXLAN header manipulations take place purely in the Data Plane. Centralized fabric-wide mapping databases (LISP) and policy distribution are functions of the Centralized Controller Control Plane.

Step-by-Step Solution

1
Identify administrative and monitoring functions
Handling REST API calls and gNMI telemetry fall under system administration and device monitoring tasks.
Administrative access, configuration interfaces, and external telemetry generation operate within the management plane.
2
Analyze local routing daemon operations
OSPF Hello packet processing and RIB compilation require local CPU compute resources on the network device.
Local routing protocols run in software as part of the distributed control plane on individual network nodes.
3
Examine line-rate packet forwarding and encapsulation
TCAM lookups and VXLAN encapsulation take place in specialized hardware ASICs without invoking the main CPU.
The data plane is dedicated to high-speed, hardware-based packet handling and forwarding along the path of user traffic.
4
Analyze centralized SDN fabric mapping operations
Managing fabric endpoint location maps via LISP across multiple nodes is handled by the central controller software.
In software-defined architectures, control plane intelligence and endpoint mapping databases are offloaded from edge switches to a centralized controller control plane.

Key Concept

Separation of Management, Local Control, Centralized Control, and Data Planes in Enterprise SDN Architectures
Question 98Question

A network automation script executes a REST API call to a Cisco SD-WAN vManage controller to retrieve operational statistics. The API returns the following JSON payload:

{
"system_status": {
"controller_group": "Group-Alpha",
"devices": [
{
"hostname": "vEdge-Branch1",
"site_id": 100,
"reachability": "reachable",
"tunnel_stats": [
{"color": "biz-internet", "latency_ms": 12},
{"color": "mpls", "latency_ms": 8}
]
},
{
"hostname": "vEdge-Branch2",
"site_id": 200,
"reachability": "unreachable",
"tunnel_stats": [
{"color": "biz-internet", "latency_ms": 45}
]
}
]
}
}

Assuming the response is stored in a Python dictionary named `payload`, which data path expression correctly extracts the integer value `8` representing the MPLS tunnel latency for `vEdge-Branch1`?

Show answer & explanation

Answer: payload["system_status"]["devices"][0]["tunnel_stats"][1]["latency_ms"]

Answer

The expression `payload["system_status"]["devices"][0]["tunnel_stats"][1]["latency_ms"]` correctly extracts the integer value 8.
The correct expression accurately navigates the nested JSON hierarchy. The top-level key 'system_status' maps to an object containing the key 'devices', which holds an array (list). Index 0 retrieves the first device ('vEdge-Branch1'). Within that device dictionary, 'tunnel_stats' holds another array. Index 1 retrieves the second tunnel entry ('mpls'), and the key 'latency_ms' yields the value 8.

Step-by-Step Solution

1
Locate the top-level object key 'system_status'
Accesses the object containing 'controller_group' and the 'devices' array.
Top-level JSON element is a dictionary object containing 'system_status'.
2
Access the first element of the 'devices' array
References index [0] to select the dictionary object for 'vEdge-Branch1'.
JSON arrays use zero-based indexing; index 0 represents the first element.
3
Locate the 'tunnel_stats' key within the selected device dictionary
Retrieves the list of tunnel statistics dictionary objects.
'tunnel_stats' contains an array of objects enclosed in square brackets [].
4
Select the second element of the 'tunnel_stats' array and extract 'latency_ms'
Index [1] selects `{"color": "mpls", "latency_ms": 8}`, and key `["latency_ms"]` yields `8`.
Zero-based index 1 points to the second element in the array.

Key Concept

JSON Nested Data Structures and Zero-Based Array Indexing
Question 99Question

When contrasting traditional distributed networking with a centralized controller-based architecture, which of the following statements accurately highlight key operational and architectural differences? (Select two.)

Select all that apply

Show answer & explanation

Answer: Control plane intelligence in controller-based networks is centralized or orchestrated, communicating instructions down to edge devices via Southbound APIs such as NETCONF or RESTCONF.; Traditional networks require individual box-by-box configuration via CLI or SNMP on distributed nodes, whereas controller-based networks enable central policy management across the fabric.

Answer

In controller-based networking, control plane intelligence is centralized or policy-driven, relaying forwarding rules to devices via Southbound APIs (such as NETCONF or RESTCONF). Additionally, traditional networks depend on individual box-by-box management via CLI or SNMP, while controller-based networks allow network-wide policy provisioning from a single management plane.
Controller-based architectures decouple or centralize control logic, allowing network-wide policies to be deployed across devices using Southbound APIs (such as NETCONF/RESTCONF). Furthermore, while traditional networking depends on distributed control planes managed through individual CLI or SNMP sessions per device, controller-based networking provides centralized abstraction and management across the entire network fabric.

Step-by-Step Solution

1
Analyze control plane deployment and API roles in traditional vs. controller-based environments
Controller-based architectures centralize or abstract control plane logic and use Southbound APIs (NETCONF, RESTCONF, OpenFlow) to program data plane devices.
This contrasts with traditional devices where each node independently computes routes and updates local forwarding tables.
2
Compare configuration and management approaches
Traditional network management requires manual, distributed box-by-box CLI or SNMP interactions, whereas controller-based networks utilize centralized management and Northbound APIs to streamline policy deployment.
Centralized controllers provide abstraction, reducing configuration drift and operational overhead across enterprise fabrics.
3
Evaluate distractor statements for technical accuracy
Statements claiming Ansible requires resident agent daemons or that HTTP GET modifies configuration state are false.
Ansible is inherently agentless, and HTTP GET is strictly a read-only operation in RESTful architecture.

Key Concept

Comparing Traditional Networks with Controller-Based Networking
Question 100Question

During a stress test on a core network device within a controller-managed fabric, control processor CPU utilization reaches 100% due to an excessive rate of incoming ARP requests directed to the router's local interfaces. Despite this control processor saturation, pre-established transit data traffic continues to be forwarded between endpoints with zero packet loss and at full line rate. Which architectural characteristic explains why transit data forwarding continues at full line rate despite control processor exhaustion?

Show answer & explanation

Answer: The data plane uses specialized hardware ASICs and a compiled Forwarding Information Base (FIB) to handle transit packet forwarding independently of control plane CPU operations.

Answer

The data plane uses specialized hardware ASICs and a compiled Forwarding Information Base (FIB) to handle transit packet forwarding independently of control plane CPU operations.
In modern networking devices, the control plane (CPU-driven software process) creates routing and resolution tables (RIB/ARP) and installs them into the data plane as the Forwarding Information Base (FIB) rendered in ASICs/TCAM. Because transit packet switching occurs entirely in data plane hardware, a 100% CPU spike caused by control-plane-bound ARP packets will not impact the line-rate forwarding of pre-established transit data traffic.

Step-by-Step Solution

1
Differentiate the roles of the control plane and the data plane in network devices.
The control plane handles protocol processing (e.g., OSPF, BGP, ARP, ICMP targeted at local IP addresses) via the main CPU, whereas the data plane (forwarding plane) handles switching transit packets from input interfaces to output interfaces.
Control plane operations populate the Routing Information Base (RIB) and ARP tables, which are then used to build the Forwarding Information Base (FIB) and adjacency tables.
2
Analyze the impact of control processor CPU saturation on established transit flows.
Once the FIB and TCAM are programmed by the control plane, data plane hardware (ASICs) forwards matching transit packets directly without interrupting or consulting the main CPU.
Hardware-based forwarding ensures high throughput and low latency, insulating existing data flows from control plane spikes.
3
Identify why local interface ARP requests cause high CPU usage without dropping transit packets.
Packets destined for the router's own IP address (such as ARP requests) are punted to the CPU/control plane, spiking CPU load, while transit traffic matching existing FIB entries stays strictly on the data plane.
This clear separation of control plane and data plane responsibilities accounts for uninterrupted line-rate transit forwarding during control plane overload.

Key Concept

Control Plane and Data Plane Separation
Estimated Time:2m 0s
PreviousPage 5 / 10Next
Automation and Programmability Practice Questions — Cisco CCNA — Page 5 | Examkin