Domain 1: Network Automation
- AUTOCOR v2.0 replaced the DevNet Professional DEVCOR content with a network-automation focus. The exam is about automating network configuration and operations across Cisco platforms rather than about general application development, which is the single biggest change for anyone who studied the previous version.
- The same four configuration targets recur across every tool in the first domain - VLANs, OSPF, asset management, interface settings and ACLs - so learn each tool by how it expresses those, rather than learning each tool in isolation.
- Ansible is agentless and pushes configuration over SSH or an API using inventory, playbooks and modules. Cisco collections provide the platform-specific modules, and idempotence means running the same playbook twice leaves the device in the same state rather than reapplying changes.
- Structure Ansible for reuse: inventory groups by role or site, group_vars and host_vars for the data, roles for the logic, and Jinja2 templates for the configuration itself. Putting device values inside the playbook is what makes an automation solution unmaintainable.
- Terraform is declarative and state-based: it compares desired configuration against a state file and plans the difference. That state file is the critical artefact - it must be stored remotely with locking so two engineers cannot corrupt it.
- Know when each fits. Terraform excels at provisioning and managing resource lifecycle where a provider exists; Ansible excels at configuration and orchestration of ordered tasks, especially against devices with no Terraform provider.
- RESTCONF (RFC 8040) exposes YANG-modelled configuration over HTTP with standard verbs: GET to read, PATCH to merge a change, PUT to replace, POST to create and DELETE to remove. It is the HTTP-native alternative to NETCONF.
- RESTCONF requests are made against a URI built from the YANG model - /restconf/data/ plus the module and container path - with JSON or XML bodies. Getting the module prefix wrong in the payload is the most common cause of a rejected request.
- The distinction the exam tests is PATCH against PUT: PATCH merges the supplied data into the existing configuration, while PUT replaces the entire target resource, which silently removes anything not present in the body.
- Python automation uses the platform SDKs and HTTP libraries directly, which is the right answer when the logic is beyond what a playbook or plan can express - conditional workflows, data transformation across systems, or anything that must reason about the response.
- Choose the automation approach from the requirement rather than from preference: an infrastructure-as-code framework where state and repeatability matter, low-code or no-code where the team lacks development capacity, and a custom application where the workflow is genuinely bespoke.
- Weigh the trade-offs explicitly, because the exam asks you to justify a choice: an IaC framework gives repeatability and review at the cost of learning curve; low-code delivers quickly but constrains what you can express; custom code is unlimited and becomes your maintenance burden.
- Consuming REST APIs properly is a published objective in its own right. Handle pagination by following the next link or offset until exhausted rather than assuming the first page is the whole answer - a script that silently processes only the first fifty devices is worse than one that fails.
- Handle rate limiting by respecting HTTP 429 and its Retry-After header with exponential backoff, rather than retrying immediately. Meraki and other Cisco APIs enforce limits, and an aggressive client makes the problem worse.
- Persistent authentication means obtaining a token once and reusing it until it expires, then refreshing - not authenticating on every call. Cisco platforms differ: Catalyst Center and ISE issue tokens, Meraki uses an API key header, and Webex uses OAuth.
- Implement real error handling: check status codes rather than assuming success, distinguish retryable errors such as 429 and 503 from permanent ones such as 400 and 401, and fail loudly when a change cannot be applied rather than logging and continuing.
- Know the platforms by their automation interface: IOS XE with RESTCONF, NETCONF and YANG; ACI with its REST API and object model; Meraki with its cloud dashboard API; Catalyst Center with intent APIs; SD-WAN with vManage APIs; ISE with ERS and pxGrid; and Webex Messaging for notifications.
Domain 2: Infrastructure as Code
- Git is the foundation of infrastructure as code, and the exam tests specific operations rather than general familiarity. Know what each command does to history, because several of them rewrite it.
- A merge combines a branch and preserves both histories; a squash merge collapses the branch into a single commit on the target, which keeps mainline history readable but loses the individual commits.
- Resolve a merge conflict by editing the conflicted file to the intended result, removing the conflict markers, staging it and completing the merge. Choosing one side wholesale without reading is how a colleague's change disappears.
- git cherry-pick applies the change from a specific commit onto the current branch, which is how you take one fix from a branch without merging everything else on it.
- git reset moves the branch pointer and rewrites history: --soft keeps changes staged, --mixed unstages them but keeps the files, and --hard discards them entirely. It is destructive on a shared branch.
- git revert creates a new commit that undoes a previous one, leaving history intact. Revert is the correct answer for anything already pushed to a shared branch; reset is for local history only.
- git checkout switches branches or restores files from a commit. Newer Git splits these into switch and restore, but checkout remains what the exam names.
- A GitLab CE pipeline is defined in .gitlab-ci.yml as stages containing jobs, run by runners. Jobs in the same stage run in parallel, and the next stage starts only when the previous one has fully succeeded.
- Build the pipeline with the four published stages: build to produce the artefacts, prevalidation to check the change is safe before it touches the network, deploy to apply it, and post-validation to prove the network is in the intended state afterwards.
- Prevalidation and post-validation are what make network automation safe to run unattended. A pipeline that deploys without proving the outcome has automated the change and not the confidence in it.
- Diagnose a pipeline failure by reading the job log for the first failure rather than the last: a missing dependency shows as a command not found or an unresolved package, incompatible versions show as import or syntax errors, and failed tests show as assertion output.
- Distinguish a pipeline failing because the code is wrong from one failing because the runner environment is wrong. A job that passes locally and fails in CI is usually a missing dependency, a different interpreter version, or an absent variable.
- Store secrets as protected, masked CI/CD variables rather than in the repository, and scope them to protected branches so a merge request from a fork cannot exfiltrate them.
- Cisco Modeling Labs builds a virtual topology so automation can be tested against real network operating systems before it reaches production. Testing a playbook against a simulated topology is the published expectation, not an optional nicety.
- A Docker Compose file describes multi-container environments: services define the containers and their images, networks define how they communicate, volumes persist data beyond the container lifetime, and links are the legacy mechanism superseded by networks.
- Read a Compose file for what it actually declares - which service depends on which, which ports are published against merely exposed, and whether a volume is a named volume or a bind mount to the host.
- A source of truth holds the intended state of the network - device inventory, addressing, VLANs, ownership - and automation reads from it rather than from hard-coded values. NetBox and Nautobot are the common implementations.
- Integrating a source of truth is what makes automation scale: the pipeline queries intended state, renders configuration from it, applies it and validates the result, so adding a device is a data change rather than a code change.
- YANG is the modelling language that defines the structure of configuration and operational data, and a YANG model can be represented in either JSON or XML for RESTCONF. Constructing that payload correctly from a given model is an explicit objective.
- When building a payload from a YANG model, respect the container and list hierarchy, include the module prefix on the top-level element, and supply every key of a list entry - a missing list key is rejected even when the rest of the payload is valid.
Domain 3: Operations
- Model-driven telemetry pushes operational data from the device on a subscription rather than waiting to be polled, which is what makes it scale where SNMP polling does not. The data is defined by YANG models, so it is structured rather than free text.
- Know the architectural components: a publisher on the device, a subscription defining which YANG paths are sent, a transport such as gRPC or NETCONF, an encoding such as JSON or protobuf, and a collector that receives and stores the stream.
- Subscriptions are either periodic, sending a snapshot on an interval, or on-change, sending only when a value changes. On-change suits state such as interface status; periodic suits counters and utilisation.
- Dial-out has the device initiate the connection to the collector, which suits devices behind a firewall; dial-in has the collector initiate to the device. Which one is possible is usually decided by the network path rather than by preference.
- Implement a logging strategy deliberately: structured logs with a consistent format, meaningful levels, and enough context - device, change ID, correlation ID - to reconstruct what an automation run did. Print statements scattered through a script are not a logging strategy.
- Send logs where they will be seen: syslog for infrastructure-standard aggregation into an existing collector, and webhooks to push events into a chat channel or an incident tool for things a human must act on immediately.
- Log the automation run, not just errors: what was intended, what was actually changed, and what the post-validation found. That record is what makes a failed change diagnosable after the fact.
- Diagnose automation failures by isolating the layer: an authentication error means credentials or token handling, a connection error means reachability or TLS, a 4xx means the request was wrong, a 5xx means the platform failed, and a task that succeeds without the intended effect means the payload was accepted but did not say what you meant.
- Read Ansible failure output for the failed task, the module's message and the affected host, and re-run with increased verbosity to see the exact request. Ansible reporting changed=false on a task you expected to change something is a signal, not a success.
- pyATS is the framework for change validation: capture a snapshot of device state before the change, apply it, snapshot again, and compare. The CLI tools do this without writing test code.
- A pyATS learn and diff over the relevant features is the published way to prove a change did what was intended and nothing more. Comparing intended state to actual is what distinguishes validation from hoping.
- Obtaining a CA-signed TLS certificate follows a fixed process: generate a key pair and a certificate signing request containing the subject and any subject alternative names, submit the CSR to the CA, receive the signed certificate, and install it with its chain.
- The private key never leaves the system it was generated on and is never sent to the CA. Certificates must carry the correct subject alternative names, since modern clients ignore the common name, and the full chain must be installed or clients fail to build a path to trust.
- Practise secure coding rather than bolting security on afterwards: validate and sanitise every input, never build a command or query by string concatenation, and fail closed when validation fails.
- Manage secrets properly: never commit credentials, read them from environment variables, a vault or CI/CD protected variables at runtime, use Ansible Vault for playbook data, and rotate anything that has been exposed rather than assuming nobody noticed.
- Authenticate every automation identity with least privilege - a dedicated service account with only the rights the task needs - so a compromised automation credential cannot reconfigure the whole estate.
Domain 4: AI in Automation
- AI in Automation is a full 20% of AUTOCOR v2.0 and is genuinely new, so it is where most existing study material is silent. It covers AI-assisted development, the security risks of AI-based automation, MCP servers, conversational agents and evaluating AI output.
- AI-assisted code development speeds up writing playbooks, scripts and templates, and it accelerates learning an unfamiliar API. Those are real benefits and the exam expects you to state them rather than to be uniformly sceptical.
- The risks are equally examinable. Data privacy: code and configuration sent to a hosted model may leave your organisation, and network configuration contains addressing, topology and sometimes credentials.
- Intellectual property is the second published risk: generated code may reproduce licensed material, and the ownership of what a model produces is not always clear. Organisational policy on generated code is a governance question, not a technical one.
- Code validation is the third: generated automation is plausible-looking by construction and can be confidently wrong. Review it, test it in simulation, and put it through the same pipeline and prevalidation as anything a person wrote.
- Interpret the security risks of an AI-based automation solution by asking what the model can reach and what it can do. A model that can read device state is an information exposure risk; one that can push configuration is a change-control risk.
- Prompt injection is the risk specific to agents: untrusted content the agent reads - a ticket description, a device banner, a log line - can contain instructions the model follows. Never let retrieved content carry authority to trigger actions.
- Constrain what an agent may do rather than trusting it to behave: least-privilege credentials, an explicit allow-list of actions, read-only by default, and a human approval step before anything changes production.
- The Model Context Protocol is a standard way to expose tools and data to an AI agent, so the agent can query systems through defined tools instead of being given raw credentials or having integrations hard-coded into it.
- Build an MCP server in Python with FastMCP: define the server, decorate functions as tools with clear names, typed parameters and docstrings, and run it. The docstring and type hints are what the model uses to decide when and how to call the tool, so vague ones produce wrong calls.
- Design MCP tools around what the network can safely be asked. A tool that returns device inventory or interface state is low risk; a tool that pushes configuration needs validation inside the tool itself, because the model decides the arguments.
- A conversational agent for network automation combines an LLM with those tools and a system prompt that sets its role and limits. The model decides which tool to call from the request; your code executes it and returns the result.
- Ground the agent in real data rather than letting it answer from training: retrieve current device state, documentation and the source of truth, and require the agent to answer from what it retrieved. That is what stops an agent inventing an interface name.
- Evaluate the accuracy of AI recommendations systematically, not impressionistically: check the recommendation against actual device state and the source of truth, test it in simulation, and track how often recommendations are correct so quality is measured rather than assumed.
- Treat an AI recommendation as a proposal requiring the same evidence as any other change. If it cannot be validated by pyATS or a pipeline's post-validation stage, it is not ready to apply, regardless of how confident the explanation sounds.
Cisco CCNP Automation (350-901 AUTOCOR) exam tips
- Network Automation and Infrastructure as Code are 30% each - together 60% of the exam. Ansible, Terraform, RESTCONF, Python, Git and GitLab CI/CD are where the majority of the marks are.
- AI in Automation is 20% and is the newest part of the blueprint, so most older study material omits it entirely. Cover MCP servers with Python FastMCP, conversational agents, the published risks of AI-assisted development, and evaluating AI recommendations.
- The first domain repeats the same five configuration targets - VLANs, OSPF, asset management, interface settings and ACLs - across Ansible, Terraform, RESTCONF and Python. Learn one target in all four tools rather than one tool at a time.
- Know the Git operations precisely, because several rewrite history: merge against squash merge, cherry-pick, reset with --soft, --mixed and --hard, checkout, and revert. Revert is the right answer for anything already pushed to a shared branch.
- Memorise the four published pipeline stages - build, prevalidation, deploy, post-validation - and be able to say why prevalidation and post-validation are what make unattended network change safe.
- For RESTCONF, the recurring distinction is PATCH against PUT: PATCH merges, PUT replaces the entire resource and removes anything absent from the body.
- REST API consumption is examined in detail, not in passing. Pagination, rate limiting with 429 and Retry-After, persistent token authentication, and real error handling all appear as published sub-topics.
- pyATS is the named tool for change validation: learn state before, apply, learn again, and diff. Any question about proving a change did what was intended is pointing at it.
- For AI questions, the three published risks of AI-assisted development are data privacy, intellectual property ownership and code validation. Answer with those rather than with general unease about AI.
Study guide FAQ
How is AUTOCOR different from the old DEVCOR exam?
The exam code 350-901 is the same, but version 2.0 refocused it. DEVCOR was the DevNet Professional core exam and leaned towards application development on Cisco platforms; AUTOCOR is Designing, Deploying and Managing Network Automation Systems and is the core exam for CCNP and CCIE Automation. Infrastructure as code, operations and a full AI in Automation domain replaced much of the application-development content, so study material written for DEVCOR is not sufficient.
What are the domains and weightings?
Cisco publishes four: Network Automation 30%, Infrastructure as Code 30%, Operations 20%, and AI in Automation 20%. The exam is 120 minutes and is associated with both the CCNP Automation and CCIE Automation certifications.
How much Python do I need to write?
A working amount. Python appears as a way to construct network automation solutions, to consume REST APIs with pagination, rate limiting and persistent authentication, and to build an MCP server using FastMCP. You should be comfortable reading and correcting Python that calls an API and handles errors, rather than only recognising the syntax.
What is an MCP server and why is it on a Cisco exam?
The Model Context Protocol is a standard way to expose tools and data to an AI agent, so the agent calls defined tools instead of being handed raw credentials or bespoke integrations. Cisco lists constructing an MCP server with Python FastMCP as an explicit objective because it is how a conversational agent safely gets network information: you define typed, documented tools, and the model chooses among them. The tool docstrings and type hints are what the model reads to decide how to call them, so writing them carefully is part of the engineering.
Do I need Ansible and Terraform, or is one enough?
Both. They appear as separate published sub-topics under Network Automation, and the exam expects you to choose between them for a given requirement. Terraform is declarative and state-based, which suits provisioning and lifecycle management where a provider exists; Ansible is agentless and procedural, which suits configuration and ordered orchestration, particularly against devices with no Terraform provider. Knowing why you would pick one is as examinable as knowing how to use it.