Cisco 350-401 ENCOR exam objective 7.1 asks you to describe network automation and programmability tools, APIs, and data formats. When you manage one network switch, typing commands by hand works. But a typical enterprise has hundreds of switches, routers, and wireless controllers. Manual configuration scales poorly and invites mistakes—one mistyped command can cause an outage. This objective teaches you the building blocks that replace repetitive manual effort with reliable, auditable, and repeatable automation.
Jump to a section
A simple way to picture Network Automation and Programmability
A restaurant’s digital ordering kiosk is the single interface through which every customer’s meal request flows. The kiosk screen shows a list of dishes and customisation options—just like an API presents a set of endpoints a script can call. A customer taps their choices and hits Send. The kiosk immediately packages the order into a standardised format (a structured receipt, like a JSON object) and fires it into the kitchen. In a manual kitchen, a chef reads a handwritten ticket and cooks each dish from scratch, repeating the same steps for every order. When the restaurant installs a self-service kitchen line, that changes completely. The receipt triggers a conveyor belt. Pre-programmed dispensers squirt sauce, drop patties, and toast buns exactly the same way every time. No chef touches the ingredients. That conveyor belt is the automation tool—Ansible, Puppet, or Chef. The standardised receipt is the data payload. The kiosk’s screen is the programmable interface. Network automation does exactly this: replace a human typing commands on every device with a system that reads a declarative recipe and pushes the configuration uniformly across the whole estate.
Network automation means using software to push configurations, gather operational data, and verify compliance across many network devices without a human typing every command. Programmability is the ability to interact with a device through a well-defined software interface—an API—rather than only through a human-oriented command line. Together they solve the core problem of scale. A single network engineer cannot log into 500 switches every night to change an NTP server address, but a five-line script can do it in seconds.
Before automation, operators relied on CLI scripting with expect or simple copy-paste from a terminal. That approach was fragile: slight differences in device prompt, firmware version, or output format would break the script. Automation tools and standardised APIs introduce a contract between the management system and the device, so changes happen predictably.
Automation tools fall into three major categories, all of which you must recognise for the exam:
Ansible: An open-source, agentless automation engine. Agentless means you do not install any extra software on the network device; Ansible connects over SSH and runs Python on the control node to execute commands. Tasks are defined in playbooks written in YAML (Yet Another Markup Language), a human-readable data format that uses indentation instead of braces. Ansible uses a push model: the control node initiates the connection to each managed device.
Puppet: An agent-based tool. Each managed device runs a Puppet agent that periodically pulls its desired state from a Puppet server. Configurations are written in a Ruby-based domain-specific language (DSL) called manifests. Puppet follows a pull model, making it strong at enforcing configuration drift remediation—if someone manually changes a setting, the agent resets it at the next run.
Chef: Another agent-based, pull-model tool. It uses Ruby recipes and cookbooks to define policy. Chef is more programmable because you can embed full Ruby code, but that also raises the learning curve. For ENCOR, know that Chef relies on a Chef server and Workstation to manage nodes.
APIs are the language through which applications talk to network devices. The exam expects you to differentiate three core API types:
REST (Representational State Transfer): A stateless API that uses HTTP methods—GET to read, POST to create, PUT/PATCH to update, DELETE to remove. Data is typically formatted in JSON (JavaScript Object Notation), a lightweight text format with curly braces, colons, and commas. Because REST rides on HTTP, it passes through firewalls easily and is the foundation of modern web services. Every network controller (Cisco DNA Center, Meraki Dashboard) exposes a REST API.
NETCONF (Network Configuration Protocol): A standards-based protocol (RFC 6241) designed specifically for network configuration and state retrieval. It runs over SSH, so it needs a persistent, stateful session. Operations are encoded in XML (Extensible Markup Language), and data structures are modelled in YANG (Yet Another Next Generation), a schema language that defines what a device can do. NETCONF excels at transactional configuration changes—apply a candidate config, validate it, and commit or roll back atomically.
RESTCONF: An HTTP-based protocol that exposes NETCONF’s capabilities using RESTful principles. It runs over HTTPS, uses the same YANG data models as NETCONF, but delivers data in JSON or XML. RESTCONF is essentially a thin HTTP wrapper around NETCONF, giving you the best of both worlds: REST’s simplicity and NETCONF’s structured data models. Cisco’s IOS-XE and NX-OS platforms support RESTCONF, making it a frequently tested topic.
Data formats matter because every API and automation tool relies on a serialisation language to represent structured data. The two that dominate network automation are:
JSON: A strict key-value format. Keys must be double-quoted, arrays use square brackets, and objects use curly braces. It is the native language of REST APIs and JavaScript-based tooling.
YAML: A superset of JSON that prioritises human readability. It uses indentations (spaces, never tabs) and hyphens for lists. Ansible playbooks, Docker Compose files, and many automation definitions use YAML.
Understanding what each tool, protocol, and format solves is the first step to passing the exam. Network automation does not eliminate the network engineer; it elevates their work from manual typing to defining desired state in code, which can be version-controlled, tested, and reused.
Install and prepare the automation control node
On a Linux or WSL machine, install Python and ansible-core. This machine becomes the control node that orchestrates all tasks. Inventory files and playbooks are created here. Without this step, no automation can run.
Define the inventory
Write an inventory file (INI or YAML) listing every network device by IP or hostname, grouped logically (e.g., [spines], [leaves]). The inventory tells the automation tool where to connect, and grouping permits role-based configuration.
Create the playbook or manifest
For Ansible, write a YAML playbook specifying which tasks to run on which groups. For Puppet, write a manifest in Ruby DSL. The file declares desired configuration state—VLANs, NTP, ACLs—rather than step-by-step CLI commands. This separation of intent from execution is what makes automation scalable.
Execute the automation
Run the tool’s command (ansible-playbook, puppet agent -t, chef-client). The tool connects to each target device using its native transport (SSH, HTTPS) and brings the device into compliance with the declared state. Parallel execution speeds up the entire process.
Validate and store artefacts
Review execution logs or callback data to verify that every device accepted the configuration. Commit the playbook and inventory to a version control system (Git). This creates an audit trail and enables peer review, closing the loop on safe, repeatable network change management.
An IT professional at a mid-size retail company needs to update the SNMP community string and add a new NTP server on 60 Cisco Catalyst switches spread across three locations. Doing this manually would involve SSH-ing into each switch, entering configuration mode, typing the same commands, saving the config, and logging out. It would consume two hours and almost certainly introduce a typo on one device.
Instead, the engineer writes an Ansible playbook. The playbook is a YAML file that declares the desired state:
- name: Configure NTP and SNMP on access switches hosts: access_switches gather_facts: no tasks: - name: Set NTP server cisco.ios.ios_ntp: server: 192.168.1.10 state: present - name: Set SNMP community string cisco.ios.ios_snmp: groups: - name: read_only version: v2c community: mySecureCommunity
The engineer maintains an inventory file listing all 60 switches by hostname or IP address. With a single command—ansible-playbook -i inventory.yml ntp_snmp.yml—the Ansible control node opens simultaneous SSH sessions to every device, copies the correct IOS module, applies the configuration, and reports success or failure. The whole process completes in under a minute. A log file records exactly which devices were changed and whether any task failed.
Beyond one-off changes, the engineer stores the playbook in a Git repository. Version control gives a full audit trail: who changed what and why. If the network team later adopts Cisco DNA Center, that same desired state can be enforced continuously via its automation policies or exposed REST API, closing the loop from manual ad-hoc work to intent-based networking.
ENCOR exam questions on network automation and programmability test your ability to match a tool or API to its characteristics, not to write code. The traps are subtle differences in architecture, transport, and data format. Expect questions that show a brief scenario and ask which tool or API is the best fit.
Topics you must memorise:
Ansible: agentless, push model, YAML playbooks, uses SSH.
Puppet: agent-based, pull model, Ruby manifests (DSL), good at drift remediation.
Chef: agent-based, pull model, Ruby recipes/cookbooks, higher programmability.
REST API: stateless, HTTP methods, predominantly JSON, web-oriented.
NETCONF: stateful SSH session, XML encoding, YANG data models, transactional config.
RESTCONF: stateless HTTP/HTTPS, uses same YANG models as NETCONF, can return JSON or XML.
JSON vs YAML: JSON uses braces and double-quoted keys, YAML uses indentation and does not require quotes for simple strings; YAML is whitespace-sensitive (tabs are forbidden).
Common trap patterns:
A question describes a tool that connects via SSH and uses YAML; the answer is Ansible, but distractors will list Puppet or Chef by emphasising that they also use YAML-adjacent DSLs.
A scenario asks for a stateless API that can be called directly from a web application. The correct choice is REST, but one distractor will be NETCONF, which is stateful.
You will see RESTCONF described with JSON output; the trap is thinking it replaces NETCONF. In reality, RESTCONF requires a NETCONF server listening underneath.
Questions about YAML will test whether you recognise that tabs cause syntax errors. An answer that says “YAML allows tabs” is always wrong.
A query about transactional configuration (candidate config, commit, rollback) points to NETCONF or RESTCONF, not REST or CLI scripting.
Key definitions to carve into memory:
Agentless: No extra software installed on managed nodes; the control node uses native protocols like SSH or WinRM.
Playbook: An Ansible file containing ordered tasks to be executed on targeted hosts, written in YAML.
Manifest: A Puppet configuration file written in Puppet’s Ruby-based DSL.
Cookbook: A Chef collection of recipes and supporting files.
YANG: A data modelling language used by NETCONF and RESTCONF to define the structure and syntax of configuration and operational data.
Idempotence: A property where running the same automation task multiple times produces the same result, not cumulative changes. All three tools strive for idempotence.
Ansible is agentless, pushes configurations via SSH, and defines tasks in YAML playbooks.
Puppet uses an agent installed on each device that pulls desired state from a master, enforcing configuration consistency over time.
Chef builds on Ruby recipes and cookbooks, offering high programmability at the cost of increased complexity.
A REST API is stateless, relies on HTTP methods, and usually encodes data in JSON, making it firewall-friendly and web-centric.
NETCONF provides transactional configuration sessions over SSH, uses XML, and structures data with YANG models.
RESTCONF exposes NETCONF’s YANG models over HTTP/HTTPS, enabling JSON delivery while preserving transactional semantics.
JSON is machine-optimised with braces and double-quoted keys; YAML is human-optimised with indentation and supports comments.
Automation eliminates repetitive manual typing but still requires an engineer to define the desired state correctly and handle exceptions.
These come up on the exam all the time. Here's how to tell them apart.
Ansible
Agentless – uses SSH
Push model (control node initiates)
Playbooks written in YAML
Puppet
Agent-based – requires installed agent
Pull model (agent initiates check-in)
Manifests written in Ruby-based DSL
REST API
Stateless over HTTP
Uses JSON primarily
Widely adopted for web services
NETCONF
Stateful over SSH
Uses XML exclusively
Transaction-oriented with candidate config and commit
NETCONF
Native SSH transport
Payload always XML
Defined by RFC 6241
RESTCONF
HTTP/HTTPS transport
Payload can be JSON or XML
Defined by RFC 8040, wraps NETCONF
JSON
Requires double-quoted keys
No comments allowed
Strict curly-brace and bracket syntax
YAML
Uses indentation for structure
Comments supported with #
Allows anchors and aliases for reuse
Mistake
Ansible requires a software agent installed on every managed network device.
Correct
Ansible is agentless; it connects to devices over SSH and transfers temporary Python code only while executing tasks.
Because Puppet and Chef both use a persistent agent, beginners assume all automation tools follow the same model. The exam exploits this confusion by offering Ansible as an agentless contrast.
Mistake
RESTCONF is simply a newer REST API that replaces NETCONF entirely.
Correct
RESTCONF is an HTTP-based front end that relies on a running NETCONF server and shares the same YANG data models; the two coexist.
RESTCONF’s use of HTTP and JSON tricks learners into thinking it discards the underlying NETCONF framework, but the protocol stack still requires NETCONF’s stateful session to operate.
Mistake
JSON and YAML are interchangeable formats with no practical difference besides syntax.
Correct
JSON enforces strict rules (double-quoted keys, commas, no comments) that make it ideal for machine-to-machine communication; YAML prioritises human readability with indentation and allows comments, suiting configuration files written by people.
Both represent key-value data, so newcomers treat them as equal. In practice, a YAML file with tabs will fail silently, and a REST API expecting JSON will reject YAML, making format awareness critical on the job and in the exam.
Mistake
Network automation tools can only push configuration changes; they cannot verify operational state.
Correct
Automation tools can also poll devices for state information—interface counters, routing table entries, firmware versions—and use that data to validate compliance or trigger remediation.
Manual workflows focus on ‘make a change’, so it is natural to equate automation with one-directional pushing. The ENCOR blueprint explicitly covers configuration management and monitoring, so questions will test awareness of both capabilities.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Tools like Ansible allow you to write simple task lists in YAML without any programming. Python becomes useful later for custom modules or API scripting, but it is not a prerequisite for basic automation.
NETCONF runs over SSH and uses XML-encoded payloads through a persistent, stateful session. RESTCONF uses HTTP/HTTPS, is stateless, and can return data in JSON or XML using the same YANG models. RESTCONF effectively puts a RESTful face on NETCONF.
Yes. Ansible is agentless. It connects over SSH using the same credentials you would use for CLI access and pushes commands or structured data. No agent or daemon is installed on the network device.
Ansible playbooks are written exclusively in YAML. Although Ansible can parse JSON inventory data, the playbook definition itself always uses YAML’s indentation-based syntax.
A Puppet agent runs on the device and contacts the Puppet server at a configured interval. It receives a catalogue of desired configuration compiled from manifests, applies it locally, and reports back. If someone manually alters the switch later, the agent corrects the drift at the next run.
Yes. Modern Cisco platforms enable RESTCONF along with a built-in NETCONF server. You access RESTCONF via HTTPS on the management interface and interact with YANG-defined data models.
You've finished Network Automation and Programmability. Continue through the 350-401 ENCOR study guide to build a complete picture of the exam.
Done with this chapter?