Network Automation and APIs for ENCOR 350-401

Network automation is sometimes advertised as a way to stop engineers from touching the command line. That is the wrong goal. The real benefit is making routine, well-understood operations consistent, testable, and repeatable across devices without losing accountability. A script that pushes the wrong configuration to a hundred switches is not better than one manual mistake. To be useful, automation must have accurate inputs, bounded permissions, a reliable understanding of device state, and a way to verify what happened afterward.

The 350-401 ENCOR v1.2 blueprint calls its sixth domain “Automation and Artificial Intelligence.” It focuses on interpreting basic Python, constructing JSON, understanding YANG, describing controller APIs, interpreting REST responses, constructing EEM applets, and comparing agent-based with agentless orchestration. NETCONF and RESTCONF configuration and verification appear in the current network assurance domain, creating a natural connection between structured configuration and operational evidence. Candidates should follow the actual verbs: explain, interpret, construct, or configure, rather than studying every programming topic at the same depth.

Start with the network change you want to make safer

Suppose an organization needs to update an NTP server address on eighty branch routers. The manual approach risks skipping devices, typing inconsistent values, or failing to record exceptions. A better automation design first establishes an accurate inventory, reads current settings, identifies the devices that require change, applies the intended state, and checks that the post-change configuration matches the approved policy.

That workflow is more important than the programming language. If the device inventory is stale, the tool may ignore a newly deployed router. If authentication fails, the tool should report a failure rather than claiming completion. If a branch has a justified local exception, the automation must recognize it or send the case for review. Idempotent behavior—repeating the process without unnecessary additional change—is particularly useful in routine configuration management.

A rollback plan matters as well. Changes to routing, authentication, or management reachability can disconnect the very automation system doing the work. Stage risky changes, verify them in small groups, and maintain out-of-band recovery where the environment requires it. Automation reduces repetitive labor only when it also improves the discipline around changes.

Read Python for control flow, not clever syntax

The current blueprint expects candidates to interpret basic Python components and scripts. Concentrate on variables, lists, dictionaries, loops, conditionals, and simple function calls as they appear in network tasks. A list of device addresses might be traversed in a loop; a dictionary might store facts such as hostname and software version; an if statement might decide whether to flag a noncompliant interface. The important skill is predicting what the code does when different values appear.

Consider a script that reads an API response and prints only devices whose state is not reachable. A common error is misreading the Boolean condition, such as confusing not in with equality, or failing to notice that the script handles only the first item in a collection. Another is assuming that a missing key always returns a valid empty value. In real automation, input can be incomplete; the script should handle unexpected responses without silently reporting the network as healthy.

The guide to Python libraries for network automation offers a broader view of engineering tools, but ENCOR candidates should not be distracted into mastering an entire software development framework. Practice tracing small scripts by hand and explaining each operation’s effect on a device list or configuration payload.

Construct JSON that preserves meaning and structure

JSON is a structured text format widely used for API requests and responses. Objects contain named members, arrays contain ordered lists, strings need appropriate quotation marks, and values such as booleans and numbers have their own representations. Valid JSON syntax matters because an API may reject an otherwise correct configuration idea if the payload cannot be parsed.

Take a simple conceptual device record: {"hostname":"branch-07","enabled":true,"mtu":1500}. The boolean is true, not the quoted string "true"; the MTU is numeric, not necessarily a string; and commas separate members without appearing after the last one. In nested data, a device may have an array of interface objects, each with its own name and administrative state. A candidate should recognize where a property belongs and why the type affects how software interprets it.

Syntax is only the first validation layer. A JSON document can be perfectly valid and still violate the receiving application’s schema. An API expecting an interface identifier may not accept a friendly display label. A controller may require fields the user did not include. Confirm both structural validity and whether the payload represents the intended configuration before attempting a write operation.

Relate YANG to predictable device data

YANG is a data modeling language used to describe structured configuration and operational state, including the organization, types, and constraints of data elements. Its value is not that it replaces every vendor command with a single universal standard. It creates machine-readable expectations about what data exists and how it is represented through supported management interfaces.

For instance, an interface model might distinguish configured administrative state from observed operational state. An interface may be administratively enabled yet operationally down because a physical link is absent. A schema that makes those fields distinct helps clients avoid ambiguous assumptions. Different models and implementations can still have varying coverage; always check what a platform actually supports.

The combined operational benefit becomes clear in assurance workflows. When several devices expose structured state, an engineer can compare intended and observed values without writing brittle text parsers for every command output. The limitation is equally important: structured data can be inaccurate, stale, or incomplete if collection fails. Data modeling improves consistency but does not eliminate the need for validation.

Understand REST APIs through requests and responses

A REST-style interface commonly uses HTTP methods to request or modify resources. A GET may retrieve information, a POST may create or initiate an operation, and a PUT or PATCH may update according to a service’s contract. These are common patterns, not an excuse to assume every vendor endpoint behaves identically. Authentication, authorization, headers, content type, URL path, and request body all influence the result.

Response interpretation is especially useful for incident diagnosis. A 2xx response generally indicates success under the service’s defined behavior; a 4xx response points to a client-side request or authorization issue; a 5xx response generally indicates a server-side problem. A 200 with a JSON body that contains application-level warnings should still be inspected rather than blindly treated as a successful network configuration. Similarly, 202 Accepted often means a job was accepted for processing, not necessarily completed.

Cisco Catalyst Center and SD-WAN Manager expose management workflows through APIs. Candidates should understand that a controller API can operate on centrally managed resources, while device-level management interfaces may expose a different scope. The existing discussion of network operations APIs and automation frameworks helps place those concepts in a broader engineering context without making product-specific command memorization the objective.

Recognize the role of NETCONF and RESTCONF

NETCONF and RESTCONF enable programmatic interaction with device configuration or state through structured models. NETCONF typically uses an RPC-oriented approach with XML encoding over a secure transport, while RESTCONF exposes modeled data using HTTP-oriented operations and supported encodings. Both can help automate comparison and configuration when the device supports the necessary model and features.

The key operational distinction is how clients establish a session, target resources, read current state, apply edits, and report errors. A transaction that fails halfway through could leave the network inconsistent if the design does not account for device capabilities and error handling. When performing configuration changes, confirm that the desired state was applied and that the affected service still works. A positive protocol response is necessary evidence, not the entire acceptance test.

The v1.2 blueprint assigns configuration and verification of these protocols to network assurance, so build a small lab that both reads a current interface value and verifies it independently. That demonstrates how automation and assurance converge without pretending the certification demands writing a full-scale controller application.

Use EEM for contained, local operational tasks

Cisco Embedded Event Manager can run an applet in response to configured events or conditions. That makes it appropriate for certain device-local reactions, such as collecting diagnostic information when an interface changes state or a monitored condition is met. A useful EEM applet should have a clear event trigger, an action, and a way to verify that it operated as intended.

Consider a branch device that occasionally loses an upstream neighbor. Instead of relying on someone to log in during the incident, an applet could record selected operational commands when the relevant event occurs. This can preserve transient evidence that would otherwise disappear. But the design must control how often the applet runs, how much output it generates, and whether commands could increase load during an already unstable event.

Avoid turning a simple monitoring event into an uncontrolled configuration loop. Automation that repeatedly changes interfaces in response to ambiguous conditions can amplify an outage. Start with observational actions, test in an isolated environment, and introduce state-changing behavior only when the triggering evidence and recovery conditions are well understood.

Compare orchestration models without vendor-name dependency

Agent-based orchestration uses software components deployed on managed endpoints to receive or carry out tasks, while agentless approaches generally connect using protocols already available on the device or system. Both can be designed securely; neither is inherently more compliant, scalable, or simple in every environment. The practical comparison concerns installation overhead, credential management, network reachability, offline behavior, and the actions supported by each endpoint.

An agent may support rich local functions and persistent reporting but create a lifecycle problem for the team that must update it. An agentless controller can reduce software installed on devices but may require broad management connectivity and carefully managed credentials. For network devices, the choice is constrained by the interfaces and protocols they expose. A configuration system that does not speak the required device protocol cannot be rescued by calling it “agentless.”

The automation portion of the ENCOR blueprint is an engineering judgment test as much as a syntax test. A secure, well-scoped workflow should make desired state observable, failures explicit, and recovery possible. Practicing those outcomes provides far more durable knowledge than memorizing a list of tools whose product names change between blueprint revisions.