350-901 Designing, Deploying and Managing Network Automation Systems Exam Topics and Questions

This is the largest slice of the exam and the one that will expose gaps fastest if your hands-on experience is narrow. The domain covers writing working automation code across four distinct toolchains, choosing between them for a given scenario, and consuming REST APIs in ways that go well past a simple GET request. Breadth is the trap: you cannot afford to be strong in Python but shaky in Ansible, or comfortable with basic API calls but lost when pagination and rate limiting enter the picture.

– Ansible and Terraform for device configuration

Both tools appear independently, and the exam treats them as separate competencies rather than interchangeable options. With Ansible, you need to be able to construct playbooks that manage VLANs, OSPF, interface settings, ACLs, and asset records on real Cisco devices. The key examinable skill is knowing how playbook structure, inventory, and modules interact to produce a specific configuration outcome. With Terraform, the equivalent constructs are providers, resources, and state. Terraform's declarative model means the exam will probe whether you understand what the tool does when desired state differs from current state, not just how to write HCL that looks syntactically correct. For both tools, the question style tends to give you a partial solution and ask what is missing or wrong, so you need to read code rather than recall syntax from memory.

– RESTCONF and Python scripting

RESTCONF under RFC 8040 is testable in a specific way: you are given a YANG model and asked to construct or interpret a RESTCONF operation against it. The path structure, HTTP method, and payload must all align with the model. Misreading the YANG hierarchy is the most common source of error. Python scripting covers the same configuration targets (VLANs, OSPF, ACLs, interfaces, assets) but the focus is on writing code that produces the right outcome, handles responses correctly, and does not break when the device returns something unexpected. Libraries such as Netmiko, NAPALM, and Nornir are fair game. The exam is less interested in whether you can recite method signatures and more interested in whether you can trace through a short script and identify what it will actually do on the network.

– Choosing an approach and consuming APIs properly

Selecting between an infrastructure-as-code framework, a low-code/no-code platform, and a custom application is a scenario-based skill. The exam gives you technical constraints (team skill level, change frequency, auditability requirements, scale) and asks which approach fits. There is no universally correct answer across all scenarios, which is exactly why this sub-topic appears. REST API consumption goes further than most candidates expect. Pagination means your code must handle multi-page responses without dropping records. Rate limiting means you need backoff logic. Complex authentication workflows cover token refresh, OAuth flows, and session persistence. Error handling means acting correctly on 4xx and 5xx responses rather than assuming success. Items on this sub-topic reward candidates who understand what breaks in production, not just what works in a demo.

How Network Automation is tested

At 30% of the exam, this topic will appear in more items than any other. Expect scenario-driven questions that present a code fragment, a YANG snippet, or an API response and ask you to identify the outcome, the error, or the missing piece. Items rarely ask for pure recall. The demand is interpretation: read the code, trace the logic, and determine what happens. The traps are subtle. An Ansible playbook that is structurally valid but uses the wrong module for the target platform will produce a wrong outcome that looks plausible. A RESTCONF path that misreads the YANG container hierarchy will fail silently in some implementations. API questions reward candidates who know that a 429 response requires backoff, not a retry at the same rate. Candidates lose marks by pattern-matching on surface features of code rather than tracing execution. Practise reading unfamiliar code in all four toolchains, not just the one you use at work.

This topic shares the same weight as Network Automation but pulls in a different direction: less about writing device configs and more about the engineering discipline around them. Version control, CI/CD pipelines, containerisation, simulation, and data modelling sit together here because they are the scaffolding that makes automation repeatable and safe. If you work in a team that skips branching strategy or runs no pipeline validation, this is where the exam will find you out.

– Git operations at the command level

The exam is specific about which Git commands are in scope, and several of them are ones engineers reach for less often than the basics. Merging a branch is table stakes, but squash merges and conflict resolution during a merge are the parts that generate exam items. Cherry-picking a commit requires you to know what it selects and what it leaves behind. Git reset has three modes (soft, mixed, hard) and the difference between them is precisely what gets tested. Git checkout and git revert appear together because candidates confuse them: one moves HEAD or restores files without creating a commit, the other creates a new commit that undoes a previous one. Items in this area tend to describe a repository state and ask which command produces a specified outcome, or they describe a command and ask what the repository looks like afterward. Reading the output of git log or git status is a common setup for these questions.

– GitLab CI/CD pipeline construction and diagnosis

Two distinct skills appear here and both are examinable: building a pipeline and fixing one that is broken. A pipeline for network automation follows four stages in this syllabus: build, prevalidation, deploy, and post-validation. You need to know what each stage is responsible for and what a failure in each stage implies about the state of the deployment. Prevalidation failures mean the environment was not ready before the change; post-validation failures mean the change was applied but produced an unexpected state. Diagnosing a broken pipeline is a scenario skill. The exam gives you pipeline output or a .gitlab-ci.yml excerpt and asks you to identify why a job failed. Missing dependencies, version mismatches between pipeline components, and failed test assertions are the stated failure categories. Items reward candidates who can read pipeline YAML and trace which job failed, at which stage, and for what structural reason.

– Simulation, containers, and source of truth

Cisco Modeling Labs appears as the simulation environment for testing automation solutions before production deployment. The exam expects you to know how CML fits into a pipeline workflow and what it provides that a production device does not, specifically a safe target for destructive tests. Docker Compose is tested at the interpretation level: given a Compose file, identify what the services do, how the networks connect them, how volumes are mounted, and what the links between containers mean. You do not need to write Compose files from scratch, but you do need to read one accurately. Source of truth integration means understanding how an authoritative data store (NetBox is the common example) feeds variables into an automation workflow and why a mismatch between the source of truth and the live network is operationally significant.

– YANG-based data models and serialisation

Constructing a YAML or JSON representation of a network configuration from a YANG model is the data-modelling skill that bridges this topic back to the RESTCONF work in Topic 1. The exam gives you a YANG model and asks you to produce, or evaluate, the correct serialised representation of a configuration object. The errors that cost marks here come from misreading container and leaf relationships in the YANG hierarchy, producing a structure that is syntactically valid JSON or YAML but does not match the model. You also need to know how YANG namespaces appear in RESTCONF paths and payloads, because omitting or mis-specifying a namespace produces a request the device will reject. This is a reading and mapping skill more than a memorisation task.

How Infrastructure as Code is tested

At 30% of the exam, this topic generates as many items as Network Automation but the cognitive demand shifts from code execution toward workflow reasoning. Expect questions that present a Git repository state, a CI/CD pipeline excerpt, a Docker Compose file, or a YANG model fragment and ask you to interpret or diagnose it. Items on Git commands reward precision: the difference between reset modes or between revert and checkout is exactly the kind of distinction the exam exploits. Pipeline questions reward candidates who can map a failure message to a specific stage and cause. The trap across almost all sub-topics is surface plausibility: a pipeline YAML that looks correct but has a stage ordering problem, or a YANG-to-JSON mapping that has the right keys in the wrong nesting level. Candidates lose marks by answering what they expect to see rather than what the exhibit actually shows. Treat every exhibit as potentially containing the error, not as background context for the question.

After the toolchain-heavy first two topics, Operations shifts the focus to keeping automation solutions running safely in production. The concern is no longer whether the code works in a lab but whether it fails gracefully, logs usefully, validates changes before and after they happen, communicates securely, and handles secrets without exposing them. Candidates who have only built automation in controlled environments tend to underestimate this topic, and the 20% weight means underestimating it hurts.

– Telemetry, logging, and diagnostics

Model-driven telemetry is tested at the architectural level: you need to understand the components (publisher, receiver, subscription model) and the difference between dial-in and dial-out streaming. The exam is not asking you to configure a telemetry stack from scratch but to identify which component is responsible for which function and what breaks when one is misconfigured. Logging strategy is more implementation-focused. The exam expects you to know how to direct log output from an automation solution to syslog or a webhook endpoint, and to understand what information a log entry should carry to be useful for diagnosis. Diagnosing problems from logs and event output is the applied version of this: given a log excerpt related to an automation event, identify what went wrong and at which layer. Items here reward candidates who can read log output rather than recall logging configuration syntax.

– Validation, security, and certificate management

Change validation with pyATS CLI tools is a specific, examinable workflow. The exam expects you to know how to use pyATS to capture a pre-change baseline and compare it to a post-change state, and what the tool reports when the two differ. This is the post-validation stage from the CI/CD pipeline in Topic 2, seen from the operational tool side. TLS certificate management appears as a process question: how a CA-signed certificate is obtained (CSR generation, CA submission, chain of trust) and how it is deployed to a network automation component. The exam tests the sequence and the roles of each artefact, not the cryptographic mathematics behind them. Secure coding practices cover input validation (rejecting unexpected data before it reaches a device), authentication patterns, and secret management. The last of these is the most operationally consequential: hardcoded credentials in automation scripts are a specific failure mode the exam asks about directly.

How Operations is tested

Items in this topic tend to be scenario-based rather than definitional. A question might present a log excerpt and ask which component of the automation solution produced the error, or it might describe a pyATS test run and ask what the output indicates about the change that was applied. The telemetry architecture questions reward knowing the direction of data flow and the role of each component. Candidates lose marks on the security sub-topics by treating them as theoretical: the exam expects you to recognise a specific insecure pattern (hardcoded secret, missing input validation, absent TLS verification) in a code or configuration exhibit and identify the risk it introduces. Certificate management questions reward knowing the process steps in the right order, particularly the distinction between the CSR, the signed certificate, and the trust chain. At 20%, this topic is large enough that a weak performance here, combined with gaps in Topic 4, will put a pass out of reach even if Topics 1 and 2 go well.

The final topic is also the newest material on the syllabus and the one where most candidates have the least structured preparation. AI-assisted development and AI-agent construction are moving targets in practice, but the exam pins down a specific set of skills: understanding the risks of AI-generated code, building components that connect AI agents to network data, and evaluating whether AI recommendations are actually correct. The 20% weight means this is not a section you can skim.

– Risks, security, and evaluating AI output

The exam approaches AI risks from two angles. The first is the risks of using AI-assisted code development in a network automation context: data privacy (what data leaves your environment when you prompt a code assistant), IP ownership (who holds rights to AI-generated code in a commercial context), and code validation (AI-generated code can be syntactically correct and logically wrong in ways that are not obvious). The second angle is security risks in a deployed AI-based automation solution. This means evaluating a described or diagrammed solution and identifying where an attacker could manipulate inputs, exfiltrate data through the AI layer, or exploit a misconfigured integration. Evaluating the accuracy of AI recommendations is the applied version of both: given a recommendation produced by an AI agent for a network change, identify whether it is correct, incomplete, or dangerous. Items here reward scepticism and systematic checking rather than trust in the output.

– Building MCP servers and conversational agents

Two construction tasks appear in this topic and both are specific enough to generate code-reading questions. An MCP (Model Context Protocol) server built with Python FastMCP exposes network information to an AI agent. The exam expects you to understand how the server is structured, what it exposes, and how an AI agent consumes that information. You do not need to have the FastMCP API memorised, but you do need to be able to read a short server implementation and identify what it provides and what it would fail to provide. Constructing a conversational agent that uses large language models for network automation is the second task. The examinable skill is understanding how the agent is wired: how prompts are constructed, how the LLM response is parsed, and how the result is translated into a network action. Items in this area tend to present a partial implementation and ask what is missing or what would cause the agent to produce an incorrect network change.

How AI in Automation is tested

This topic generates scenario and code-reading items more than definitional ones. Expect to be shown a short Python implementation of an MCP server or an LLM-based agent and asked what it does, what it fails to do, or what security risk it introduces. Risk questions reward systematic thinking: the exam presents a plausible-sounding AI integration and asks you to identify the specific failure mode, whether that is a data privacy exposure, an IP ownership issue, or a code validation gap. Accuracy evaluation questions are particularly demanding because they require you to reason about whether an AI-produced recommendation is correct for the described network scenario, without the exam telling you the AI is wrong. Candidates lose marks by treating AI output as authoritative within the question itself. The exam rewards treating AI recommendations as hypotheses to be verified against network principles. At 20%, combined with Operations, this half of the exam is where well-prepared candidates separate themselves from those who focused only on the toolchain topics.