A monitoring system detects that an uplink changed state, an engineer wants a repeatable command sequence to collect evidence, and a controller exposes a REST endpoint that can provide a structured view of device health. Each is a reasonable automation opportunity, but each requires different judgment: reading a Python script, constructing valid JSON, understanding how a data model constrains configuration, and deciding when an on-box event applet should take action. Automatically executing a command is not the same thing as safely managing a network.
Cisco 350-401 ENCOR v1.2 names its sixth domain Automation and Artificial Intelligence. It tests interpreting Python, constructing JSON, describing YANG and controller APIs, reading REST response codes, constructing EEM applets, and comparing agent-based with agentless orchestration. The existing NETCONF and RESTCONF automation specialist addresses model-driven transactions; the infrastructure-as-code treatment covers wider delivery governance. Here the emphasis is the smallest practical automation: input, event, action, permission and evidence.
Interpret Python without mistaking syntax for intent
A Python script may collect interface states, filter device records, compare results to an expected policy and generate a report. Know what variables, dictionaries, lists, loops, conditionals, functions and exceptions are doing before deciding whether the script is safe. A loop over a list of routers with a dictionary of interface states means something different from a function that blindly applies the same configuration to every device.
Consider a script that reads a JSON list of devices and prints only those whose operational state differs from the expected state. An empty output may indicate compliance, but it may also indicate a failed API call whose exception was silently ignored. Ask where the input came from, which authentication was used, whether a timeout returns an error, and whether the script distinguishes “device not reached” from “device healthy.” Those questions expose operational mistakes more reliably than memorizing all Python keywords without following data flow.
Construct JSON that matches the API’s expected structure
JavaScript Object Notation (JSON) represents objects, arrays, strings, numbers, Booleans and null values. Keys and string values require valid double-quoted syntax, while a Boolean is true or false, not a quoted English word when the API expects a Boolean. The data type and nesting must match the endpoint’s schema. A request can be valid JSON yet invalid for its API because the expected member name or nesting is wrong.
For example, {"device":"branch-01","enabled":true,"interfaces":["GigabitEthernet1","GigabitEthernet2"]} is syntactically valid JSON. It does not automatically represent a Cisco-supported API request; its field names are illustrative until the API contract is checked. A reliable workflow validates syntax, schema, allowed values and intended target before a request can change network state. A simple script should also avoid logging bearer tokens or secrets as part of its error handling. The CCNA REST APIs and JSON foundations provide the introductory grammar; ENCOR emphasizes interpreting operational consequences.
Distinguish YANG data models from serialization formats
YANG describes structured configuration and operational data, including constraints and relationships. JSON or XML can encode a representation of modeled data in an appropriate protocol. An engineer may correctly assemble JSON syntax while still violating a YANG model’s required keys, types or relationships. That difference explains why APIs provide schema and validation errors: a parser accepting the text is not enough to ensure the network can apply the requested state.
NETCONF and RESTCONF expose different operations and transport styles for manipulating modeled state, subject to platform support. A tool that needs an authoritative running configuration and structured edits should understand the device’s supported datastores, capabilities and response errors rather than scrape arbitrary CLI output. Do not claim that one protocol replaces all supported configuration mechanisms. In a migration, compare the actual features and platform release before replacing a working CLI automation task with a malformed model-driven request.
Interpret REST responses before retrying an operation
HTTP success and failure codes convey classes of outcomes. A 200 response commonly represents a successful request with a representation; 201 generally indicates creation; 204 may indicate successful processing without a response body; 400 suggests a malformed request; 401 and 403 distinguish authentication and authorization problems; 404 indicates an unavailable requested resource; and 409 indicates a conflict. The API’s own contract determines the exact behavior and error payload, so never diagnose a network-wide incident from a status code alone.
A write that times out is an ambiguous result. The remote controller may have accepted the change before the client lost its response. Repeating an unverified create request can duplicate a policy or template. Before retrying, perform a safe bounded read of the target’s actual state and use idempotent operations or request identifiers where supported. This is the same operational discipline used in live network changes: absence of an acknowledgment is not proof of absence of an effect.
Use controller APIs with explicit role and site scope
Cisco Catalyst Center and Catalyst SD-WAN Manager expose APIs that help automate inventory, monitoring and selected configuration tasks. Their objects, authentication and supported workflows differ, so an API example from one cannot be transplanted to the other by changing only the hostname. Use the correct endpoint schema, assign a constrained automation identity and capture the target site or template ID before modifying anything. An application that can read assurance metrics should not automatically be empowered to deploy network-wide policy.
A practical safe workflow reads a site inventory, checks that devices have the correct assigned location, identifies discrepancies, and produces a review list. After a human approval, a separate privileged process can make controlled changes, verify the new target state and record the result. The Catalyst Center network assurance material explains why incorrect site hierarchy and missing telemetry invalidate many otherwise impressive automated conclusions. Reliable data quality is a prerequisite for reliable automation.
Construct an EEM applet around a narrow operational trigger
Cisco IOS Embedded Event Manager (EEM) lets a device respond to supported events through applets or scripts. Events may include certain syslog patterns, timer conditions or other platform-defined detectors. The design begins with a specific event and expected safe action, not a promise to “self-heal the network.” A useful applet might capture the output of approved diagnostic commands when a particular interface changes state, then record that a data-collection action ran.
Even a simple EEM applet can become dangerous if its event matches repeatedly or if its actions make configuration changes during instability. Define cooldown or correlation behavior when supported, an event owner, logging, action permissions, failure handling and rollback expectations. In the lab, first build an applet that collects evidence without altering forwarding. Trigger it deliberately, inspect the resulting command output and prove that unrelated syslog messages do not run the action. Constructive EEM practice should be scoped to the actual IOS XE release and its available event detectors.
Compare agent-based and agentless orchestration honestly
An agent-based tool installs or runs software on the managed endpoint to execute tasks or report state. Agentless orchestration can use existing management protocols such as SSH or an API without a separate resident agent, although the controller or platform still needs its own supporting software. Neither model is automatically more secure or reliable. An agent may need patching and lifecycle management; an agentless tool may depend on centralized credentials, network access and API availability.
Consider a large branch fleet with intermittent WAN links. An on-box agent may perform local work while disconnected, subject to its design, while a controller-driven SSH task may fail until reachability returns. Conversely, installing and securing hundreds of agents can create operational overhead compared with using supported built-in device APIs. Choose based on desired state, scale, failure behavior, credential isolation and platform capability. Cisco’s v1.2 blueprint asks for this architectural comparison rather than rote memorization of specific third-party orchestration product names.
Put guardrails around AI-assisted operations
The rename to Automation and Artificial Intelligence does not authorize an agent to change production configuration whenever a health dashboard generates a suggestion. AI-powered assurance can help correlate telemetry or propose likely fault locations, but input data may be stale, incomplete or influenced by unrelated incidents. A recommendation should carry the originating evidence, affected scope, uncertainty and an approval route before any device or controller action.
For a proposed automatic interface shutdown, ask what proves the interface is unsafe, which customer paths depend on it, and how service will recover if the diagnosis is wrong. Start with read-only recommendations, measure false positives, and require a distinct, authorized deployment process for risky changes. Keep the ability to disable the automation independently from the subsystem it manages. Operational safety matters more than whether the policy was suggested by a human script or a machine-learning model.
Rehearse an end-to-end automation check
Build a small exercise with three steps: parse a device inventory JSON file, use a read-only controller or device API to retrieve interface state, and create a report of deviations without changing anything. Then configure a test EEM event to collect local evidence when one lab interface changes. The outputs should show the source data, time, status, error handling and actual triggered action. Test an unavailable device, malformed JSON and an unauthorized API request to see whether the workflow fails safely.
Finally, compare the script’s conclusion with a direct device observation. An API that reports an old interface state can create a false alert even when the Python logic is correct. A safe automation design makes that discrepancy visible and prevents an unseen retry from compounding an outage. ENCOR’s value is understanding the chain from structured data to decision to constrained action, not the number of lines of code produced in one sitting.