300-435 Automating and Programming Cisco Enterprise Solutions Exam Topics and Questions

This topic establishes the data modelling and protocol foundation that everything else in the exam depends on. You need to know YANG models in three flavours (OpenConfig, IETF, native), the two protocols that carry them (NETCONF and RESTCONF), and how to turn a YANG tree into working JSON or XML. The cost comes when you misread a model structure or build a payload that violates the schema.

– YANG models and their sources

You work with three model types. OpenConfig models are vendor-neutral and designed for multi-vendor environments, so they abstract away platform quirks. IETF models follow RFCs and aim for standardisation across the industry. Native models are written by Cisco for its own devices and expose features that the other two do not cover. The exam expects you to recognise which type suits a given scenario and to understand that native models give you the deepest access but lock you to one vendor. You also interpret YANG module trees generated per RFC8340, which means reading the tree notation that pyang and YANG Suite produce. That notation shows containers, lists, leaf nodes, and their cardinality. Misreading a list as a container or missing a mandatory leaf costs you marks.

– Protocols for model-driven management

NETCONF and RESTCONF are the two protocols that carry YANG-modelled data between your script and the device. NETCONF runs over SSH, uses XML encoding, and supports capabilities negotiation and candidate datastores. RESTCONF runs over HTTPS, uses JSON or XML, and maps YANG operations to HTTP verbs. The exam tests whether you know which protocol fits a given constraint: RESTCONF when you need lightweight integration with a web stack, NETCONF when you need transactional semantics or the candidate config feature. Both protocols let you retrieve operational state, push configuration, and subscribe to notifications. You must know the difference between config true and config false nodes, because trying to write to an operational leaf is a common error.

– Payload construction with tooling

You construct JSON and XML payloads from YANG models using YANG Suite and pyang. The task is not to memorise syntax but to read a YANG tree, identify the path to the node you want, and translate that into a correctly nested payload. JSON payloads follow the structure of the model: objects for containers, arrays for lists, key-value pairs for leaves. XML payloads add namespace declarations and use element nesting. The tools generate skeleton payloads, but you still need to fill in the values and respect constraints like pattern statements, range limits, and mandatory nodes. A missing namespace in XML or a wrong data type in JSON will fail validation on the device, and the exam will ask you to spot or fix that kind of error.

How Network Automation Foundation is tested

At ten percent, this topic appears in roughly one item out of every ten. You face questions that show you a YANG tree excerpt and ask you to construct the matching payload, or that present a payload and ask which protocol or model type it belongs to. The demand is precision: one wrong bracket, one missing namespace, or one misread cardinality turns a correct answer into a wrong one. Candidates lose marks by confusing NETCONF capabilities with RESTCONF HTTP methods, by writing to operational leaves, and by building payloads that ignore mandatory nodes. Another trap is the RFC8340 tree notation. If you cannot read the symbols for presence containers, lists with keys, or config false nodes, you will misinterpret the structure. The exam does not ask you to write a YANG module from scratch, but it does expect you to move fluently between the tree view and the wire format.

Once the foundation is in place, the exam moves to writing Python and Ansible solutions that talk directly to devices. This is the heaviest topic, and it splits into two concerns: building automation that works across CLI, NETCONF, and RESTCONF, and handling Day 0 provisioning plus on-box scripting. The weight means you will see this material in a quarter of the exam, so weak coverage here costs you the pass.

– Python libraries for device interaction

You construct solutions using three Python libraries. Netmiko handles CLI-based automation over SSH, so you send show commands, scrape text output, and push config lines. It works when the device does not support model-driven interfaces or when you need to interact with legacy command syntax. ncclient is the Python client for NETCONF, so you open a session, retrieve configuration or operational data using XML filters, and edit the candidate or running datastore. RESTCONF access is usually built with the requests library, where you map YANG paths to URIs, set Accept and Content-Type headers, and issue GET, POST, PATCH, or DELETE calls. The exam expects you to pick the right library for the scenario and to know which one gives you structured data versus unstructured text. You also need to handle connection parameters, authentication, and error responses in code.

– Ansible for configuration management

Ansible playbooks provide declarative configuration management without writing procedural scripts. You use modules like ios_config, iosxe_netconf, or uri to push configuration, retrieve facts, or interact with REST APIs. The exam tests whether you understand idempotency: running the same playbook twice should not make unnecessary changes. You also work with inventory files, group variables, and host variables to manage device credentials and connection settings. A common error is putting sensitive data like passwords directly in the playbook instead of using Ansible Vault or environment variables. Another trap is assuming that all modules support check mode, when some do not. You must know how to structure a playbook with tasks, handlers, and conditionals, and how to register output from one task to use in the next.

– Day 0 provisioning and on-box automation

Day 0 provisioning means getting a device from factory state to operational state without manual CLI work. You construct solutions that use Zero Touch Provisioning (ZTP), where the device downloads a Python script or configuration file from a server on first boot. The script can call NETCONF or RESTCONF locally, install software, or apply a bootstrap config. On-box automation uses Embedded Event Manager (EEM) applets or scripts, the guest shell Linux container, and on-box Python. EEM responds to events like interface state changes or syslog patterns and runs CLI commands or Python scripts. Guest shell gives you a persistent Linux environment where you can install Python packages, schedule cron jobs, or run long-lived processes. On-box Python can call Cisco APIs locally without SSH. The exam asks you to choose the right mechanism for a given trigger or constraint.

– Troubleshooting model-driven automation

You troubleshoot solutions based on RESTCONF, NETCONF, and YANG models by interpreting error messages, checking logs, and validating payloads. NETCONF errors come back as rpc-error XML elements with error-type, error-tag, and error-message. RESTCONF errors use HTTP status codes: 400 for bad request, 404 for wrong URI, 409 for edit conflicts. You look for schema violations, missing namespaces, wrong XPath filters, and datastore locks. A locked candidate config prevents other sessions from editing. A payload that does not match the YANG model fails validation. You also check that the device supports the model you are trying to use and that the feature is enabled. Logs on the device (debug netconf, debug restconf) show what the device received and why it rejected the operation.

How Device-Level Network Automation is tested

With a quarter of the exam weight, this topic appears in one out of every four items. You see code snippets in Python or Ansible YAML and must identify what they do, spot the error, or complete the missing line. The demand is practical fluency: you need to read Netmiko connection setup, recognise ncclient filter syntax, interpret RESTCONF URIs, and parse Ansible task output. Candidates lose marks by confusing Netmiko send_command with send_config_set, by building NETCONF filters that select the wrong nodes, and by writing RESTCONF URIs that omit the YANG module prefix. Another common mistake is ignoring error handling. Code that does not check the HTTP status or catch exceptions will fail in production, and the exam will ask you to fix it. Day 0 and on-box automation questions test whether you know which tool runs where: EEM on the device, ZTP during boot, guest shell as a persistent container. Mixing those up costs you the mark.

This is the single heaviest topic. The focus shifts from individual devices to orchestration through controllers like Cisco DNA Center or SD-WAN vManage. You write Python and Ansible code that calls controller REST APIs, build advanced Jinja2 templates for configuration generation, and automate security policies at scale. Thirty percent means roughly one in three items, so this topic decides whether you pass.

– Controller APIs for provisioning and management

You construct solutions that use controller REST APIs for Day 0 provisioning, configuration management, and monitoring. Day 0 provisioning through a controller means onboarding a device into the fabric or overlay, assigning it to a site, and pushing the initial configuration without touching the device CLI. The API calls authenticate with a token, then chain together: claim the device, assign it to a site, trigger provisioning, and poll the task status. Python code uses the requests library to POST the claim, GET the task ID, and loop until the task completes. Ansible uses the uri module or a vendor-supplied collection. You must handle token refresh, task polling, and error responses. Configuration management through the controller means pushing templates or policies to groups of devices. Monitoring means calling APIs to retrieve device health, client count, interface status, or compliance state. The exam expects you to read API documentation, construct the correct URI, set headers, and parse the JSON response.

– Jinja2 templates with advanced constructs

Jinja2 templates generate device configurations from structured data. You use loops to iterate over interfaces or VLANs, conditionals to include blocks only when a variable is true, filters to transform data, and tests to check types or values. A for loop walks a list of interfaces and renders one config block per interface. An if statement includes a feature only when the device role requires it. Filters like upper, default, or ipaddr transform strings or validate addresses. Output modifiers like trim or indent clean up whitespace. The exam tests whether you can read a template, predict its output given a set of variables, or fix a template that produces malformed configuration. Common errors include forgetting to close a loop or conditional, using the wrong filter, and producing extra blank lines that break CLI parsing. You also need to know where the template is rendered: on the controller, on the Ansible control node, or on the device itself.

– Security automation at scale

Security automation solutions enforce policy, monitor compliance, and implement segmentation. Policy enforcement means defining access rules in the controller and pushing them to devices as ACLs, SGTs, or firewall rules. Compliance monitoring means running checks to verify that devices match a baseline configuration and flagging or remediating drift. Network segmentation uses VRFs, VLANs, or Software-Defined Access (SD-Access) to isolate traffic. You construct Python or Ansible code that calls controller APIs to create policies, assign devices to security groups, and retrieve compliance reports. The exam asks you to identify which API endpoint applies a policy, how to map a user group to an SGT, and what happens when a device fails a compliance check. You also troubleshoot solutions where the policy is defined but not applied, or where the segmentation breaks connectivity.

– Troubleshooting REST API automation

You troubleshoot controller-based solutions by interpreting HTTP status codes, reading error messages in JSON responses, and checking API logs. A 401 means the token is missing or expired. A 403 means the token is valid but lacks the required role. A 404 means the URI is wrong or the resource does not exist. A 500 means the controller hit an internal error, often because the payload violated a constraint. The JSON response body contains an error message, sometimes a task ID you can poll for details. You check that the API version in the URI matches what the controller supports, that required fields are present in the payload, and that the task completed successfully. Another trap is calling APIs in the wrong order: trying to provision a device before claiming it, or deleting a template that is still attached to devices. The exam will show you a failed API call and ask you to identify the fix.

How Controller-Based Network Automation is tested

At thirty percent, this topic owns nearly a third of the exam. You see Jinja2 templates with missing or incorrect syntax, Python code that calls controller APIs and fails, and scenarios where you must choose the correct API workflow for a task. The demand is end-to-end thinking: you need to know the sequence of API calls, the data structure each call expects, and how to handle asynchronous task completion. Candidates lose marks by writing Jinja2 loops that do not close, by polling a task ID once instead of looping until success, and by ignoring HTTP status codes. Security automation questions test whether you understand the difference between defining a policy and applying it, and whether you know which API enforces segmentation. Another trap is assuming all controller APIs behave the same way. DNA Center, SD-WAN vManage, and Meraki each have different authentication, URI structures, and response formats. Mixing them up costs you the mark.

Operations covers the testing, validation, monitoring, and lifecycle management that keep automation solutions running in production. You work with platform APIs to validate changes, use topology simulations to test before deploying, automate software upgrades, monitor health through APIs, and configure model-driven telemetry. At twenty percent, this topic appears in one out of every five items, and it punishes candidates who skip the operational side of automation.

– Testing, validation, and simulation

Cisco platform APIs support the testing and validation phase by providing endpoints to verify configuration syntax, check policy consistency, and preview the effect of a change before applying it. You call these APIs in your CI/CD pipeline or from a test script to catch errors early. Network topology simulations let you model the enterprise in a virtual environment, run your automation code against it, and observe the outcome without touching production. Tools like CML (Cisco Modeling Labs) or VIRL give you virtual routers and switches that respond to API calls the same way physical devices do. The exam expects you to explain when simulation is needed: before a major change, when testing Day 0 provisioning, or when validating a new template. You also need to know that simulation does not catch every issue, because virtual devices may not model hardware-specific behaviour or scale limits.

– Software version and health management

You construct controller-based solutions to manage device software versions and monitor network health. Software version management means using the controller to inventory current versions, upload new images, schedule upgrades, and verify success. The workflow calls APIs to get the device list, check compatibility, stage the image, trigger the upgrade, and poll until the device reloads and rejoins the fabric. Health monitoring means calling APIs to retrieve metrics like CPU, memory, interface errors, client count, and reachability. You set thresholds and trigger alerts when a metric crosses the line. The exam asks you to identify which API returns health data, how to filter the response to one site or device group, and what to do when the upgrade task fails. A common error is not verifying image compatibility before starting the upgrade, which leaves the device in a broken state.

– Model-driven telemetry and webhooks

Model-driven telemetry streams operational data from the device to a collector at regular intervals, using subscriptions instead of polling. You configure a subscription on a Cisco IOS XE device via CLI, NETCONF, or RESTCONF by specifying the YANG path, the encoding (JSON or GPB), and the receiver address. The device then pushes data to the collector without waiting for a request. This reduces CPU load and gives you near-real-time visibility. Webhook-based monitoring uses controllers to send HTTP POST requests to your endpoint when an event occurs: a device goes down, a policy is violated, a threshold is crossed. You write a small web service that listens for the POST, parses the JSON payload, and takes action. The exam tests whether you know the syntax to configure a subscription, which YANG paths to subscribe to for a given metric, and how to validate that data is arriving at the collector.

How Operations is tested

At twenty percent, this topic appears in one out of every five items. You see configuration snippets for telemetry subscriptions and must identify the YANG path or encoding. You see API workflows for software upgrades and must spot the missing step or the wrong order. You see webhook payloads and must parse the event type or device identifier. The demand is operational realism: you need to know what happens when an upgrade fails mid-flight, how to recover from a telemetry subscription that sends no data, and which API call tells you whether a device is healthy. Candidates lose marks by configuring telemetry subscriptions with the wrong transport, by not polling the upgrade task until completion, and by writing webhook handlers that do not validate the sender. Another trap is assuming that all health metrics come from the same API endpoint. Some controllers separate device health, client health, and application health into different URIs. Calling the wrong one returns no data, and the exam will ask you why.

The final topic introduces AI-assisted tooling in network automation. You describe how controllers use AI for troubleshooting and insights, how large language models assist with code generation, the security risks that AI introduces, and how to build an MCP server that exposes network data to an AI agent. At fifteen percent, this material appears in roughly one item out of every seven, and it is the newest addition to the exam.

– AI in controllers and code development

AI in controller-based platforms means using machine learning models to analyse telemetry, predict failures, and recommend fixes. Cisco DNA Center uses AI to correlate events across devices, identify the root cause of an outage, and suggest remediation steps. The controller learns normal behaviour patterns, then flags anomalies that do not match. You do not train the model yourself, but you need to understand what the AI can and cannot do: it helps with correlation and prediction, but it does not replace your judgment. AI-assisted code development uses large language models to generate Python or Ansible code from natural language prompts. You describe what you want, and the model writes the first draft. The exam expects you to know that the generated code needs review: it may call deprecated APIs, omit error handling, or misinterpret your prompt. You still need to understand the libraries and APIs to verify the output.

– Security risks and MCP servers

AI-based automation solutions introduce security risks. A model trained on your network data may leak sensitive information if the training set is not sanitised. Generated code may include hardcoded credentials or call APIs without authentication. An AI agent that can execute commands on devices is a lateral movement risk if it is compromised. The exam asks you to identify which risks apply to a given scenario and how to mitigate them: use secrets management, validate generated code, restrict agent permissions, and audit AI actions. You also construct an MCP server to provide network information to an AI agent using Python FastMCP. The Model Context Protocol (MCP) defines how an agent queries external data sources. Your FastMCP server exposes functions that the agent can call: get device inventory, retrieve interface status, check compliance. The server handles the API calls to the controller or devices, then returns structured data to the agent. The exam tests whether you understand the MCP request-response flow and how to implement a resource or tool in FastMCP.

How AI in Automation is tested

At fifteen percent, this topic appears in one out of every seven items. You see descriptions of AI features in controllers and must identify what the AI does or what it requires to work. You see generated code snippets and must spot the security flaw or the missing validation. You see MCP server definitions and must identify which function the agent would call for a given task. The demand is critical evaluation: you need to know that AI is a tool, not a solution, and that every AI output needs verification. Candidates lose marks by assuming generated code is production-ready, by ignoring the risk of credential leakage in training data, and by not understanding the separation between the agent, the MCP server, and the network APIs. Another trap is confusing AI-assisted code generation with automated code execution. The model writes code, but a human or a CI/CD pipeline decides whether to run it. Mixing those roles costs you the mark.