What AUTOCOR v2.0 measures
Cisco identifies Designing, Deploying, and Managing Network Automation Systems, 350-901 AUTOCOR v2.0, as a 120-minute certification exam. The official topic page says candidates should expect performance-based, multiple-choice, and drag-and-drop formats. Passing earns the Cisco Certified Automation Specialist – Core credential and can satisfy the core-exam requirement for the current CCNP Automation and CCIE Automation paths. Certification rules and delivery terms can change, so use Cisco's official pages immediately before scheduling.
The published weights are Network Automation 30%, Infrastructure as Code 30%, Operations 20%, and AI in Automation 20%. PrepKloud's 50-question practice bank maps those weights exactly to 15, 15, 10, and 10 questions. That number describes only this original study set. This guide makes no claim about a fixed live question count or passing score.
The core mental model: separate evidence, intent, authority, and outcome
Many automation failures happen because four different things are treated as one. Evidence describes observed state. Intent describes the desired state. Authority determines who or what may change it. Outcome describes whether the service actually works after the change. An API response can confirm a write without proving the user path. A Git merge can confirm review without proving the target supports the model. A model recommendation can summarize evidence without having authority to execute.
Build every design as a sequence of boundaries: collect authorized evidence; normalize and validate it; compare it with reviewed intent; create a deterministic plan; check policy and target scope; obtain accountable approval; execute through a separate least-privilege identity; reread state; test the service; and roll back or escalate when validation fails. Performance-based reasoning becomes easier when the stages are explicit.
Domain 1: Network Automation
Data contracts before scripts
JSON and XML are not merely text formats. Native Boolean, null, numeric, array, namespace, and optional-field semantics matter. A parser that assumes every key exists or converts every value to a string will produce unreliable decisions. Validate transport status, content type, schema, required fields, supported versions, and freshness before deriving a change.
YANG defines hierarchy, types, constraints, lists and keys, actions, and notifications for modeled network data. NETCONF commonly performs XML RPC operations over a secure transport and can expose capabilities and datastores. RESTCONF maps YANG-modeled resources to HTTP methods and XML or JSON representations. Neither protocol guarantees that every platform implements the same model, release, writable node, operation, or default. Capability discovery is a prerequisite, not an optional optimization.
Reliable API clients
A mature client handles authentication, authorization, TLS validation, pagination, rate limits, timeouts, retries, conflicts, and partial failures. It uses a machine identity scoped by target and operation rather than a shared administrator password. It follows pagination until completion and exposes incomplete coverage. On rate limiting, it honors server guidance and applies bounded backoff with jitter. On a version conflict, it rereads and reconciles instead of overwriting newer state.
Timeouts deserve special attention. A client can stop waiting while a device or controller completes the request. Blind retry can duplicate list entries or collide with state. Idempotent automation reads current state, computes a deterministic semantic delta, applies only the missing intent, and verifies. Where supported, request identifiers, ETags, versions, locks, candidate datastores, validation, commit, and confirmed rollback add control.
Software architecture and tests
Separate collection, normalization, planning, approval, execution, and validation. A bounded durable queue can decouple bursty telemetry from slower parsing, but the queue itself requires capacity limits, backpressure, retries, dead-letter handling, lag metrics, and idempotent consumers. Microservices are not automatically better; use boundaries that clarify scaling, ownership, data, and failure.
Tests should include units for parsers and diff logic, contract fixtures for schema variants, integration tests against disposable targets, negative authorization tests, and failure injection for malformed data, absent optional fields, pagination loops, throttling, timeout ambiguity, and stale state. A test suite that includes only perfect payloads is a demo, not resilience evidence.
Domain 2: Infrastructure as Code
Git as change provenance
Version control makes source and intent reviewable. Use focused branches and commits, peer review, automated checks, protected integration, and deliberate reverts. Do not mix broad formatting with a policy change because reviewers then struggle to see operational intent. Do not put state, generated secrets, credentials, raw captures, or private keys in source history. If a secret reaches history, deleting the current line is insufficient: revoke or rotate it, investigate use, remediate history where appropriate, and add prevention.
State, plans, and drift
Terraform state binds declared resource instances to real objects and can hold sensitive values. Secure it with access control, encryption, versioning, and locking; do not commit it. Refresh and plans expose changes and drift, but a plan is based on a particular configuration and prior state. Bind approval to the saved plan, artifact, target inventory, and expiry. A stale plan should fail rather than apply against unexpected reality.
Ansible automation should express state with appropriate modules or deterministic templates. A shell task that appends a line every run is not idempotent merely because it appears in YAML. Dynamic inventory reduces duplicate static lists but introduces source authority, availability, freshness, completeness, and grouping concerns. Validate all targets and fail closed when inventory is partial.
Containers, CI/CD, and artifact promotion
Containers can package a consistent automation userspace across laptops and runners. They do not prove that dependencies are safe, and they commonly share the host kernel. Build minimal images, pin dependencies, scan, sign, use non-root execution where feasible, restrict mounts and networks, and preserve an immutable digest.
A delivery pipeline should format, lint, validate schemas, render every target, run unit and contract tests, scan secrets and dependencies, evaluate policy, and create a human-readable plan. Use minimal token permissions and isolated runners. Pin actions, providers, collections, and images to verified identities. Promote the exact tested artifact rather than rebuilding differently for each environment.
Delivery then moves through target-bound approval, a representative canary, observation, and controlled waves. Stop when error or service thresholds are breached. A successful configuration command is not the end of deployment; collect intended state, observed state, user-path behavior, and rollback evidence.
Domain 3: Operations
Operations asks whether the automation system can be trusted over time. Define service-level indicators such as intended-change success, API latency, drift-detection coverage, queue lag, telemetry freshness, post-check pass rate, rollback time, and unauthorized-target attempts. Define objectives over windows and alert on meaningful error-budget burn rather than every debug line.
Telemetry health is part of the product. Preserve source and ingestion timestamps. Monitor producer heartbeat, queue depth, dropped records, parser errors, delivery failures, data age, and target coverage. A dashboard showing zero errors while the collector is stopped must be unknown or degraded, not green.
When harmful automation runs, stop further execution and define scope. Preserve logs, plans, code revision, target list, identity use, and device state. Revoke exposed authority, restore reviewed intent, and validate forwarding or service behavior. Avoid a blanket reboot that destroys evidence and changes every target. The post-incident review should create owned, prioritized actions with due dates and regression or failure tests.
Capacity failures often move rather than disappear. An unbounded queue converts CPU saturation into memory exhaustion and extreme latency. Backpressure, rate limits, concurrency caps, queue bounds, load shedding, and explicit degraded behavior keep the service predictable. Measure recovery rather than assuming autoscaling worked.
Domain 4: AI in Automation
Choose the task and model deliberately
Classification maps an incident to defined labels. Generation creates text or structured recommendations. Embeddings support semantic similarity and retrieval. Retrieval-augmented generation supplies external context at generation time. Each has different data, evaluation, latency, explainability, and failure needs. Do not choose a model merely because it can produce an impressive demo.
AI can hallucinate plausible device state, invent commands, omit prerequisites, or overstate confidence. RAG improves grounding only when the retrieved documents are authoritative, authorized, current, correctly chunked, and relevant. Every indexed passage should carry source, version, access, freshness, and deletion metadata. Retrieval results are evidence candidates, not trusted instructions.
Prompt injection and data governance
Logs, tickets, configurations, and documents can contain attacker-controlled text. Treat them as untrusted data. Separate system instructions from retrieved content, minimize context, strip secrets, expose no unrestricted tools, constrain output to a schema, and enforce authorization in deterministic code outside the model. A model should not decide whether its own policy gate applies.
Training and evaluation data require lawful purpose, access control, minimization, redaction, lineage, retention, and deletion. Credentials should never enter the dataset. Customer or employee identifiers require appropriate governance. Record what the model saw, but do not create a new sensitive archive through prompts and logs.
Evaluation and closed-loop control
Evaluate representative normal cases plus missing, conflicting, stale, unsupported, adversarial, and dangerous inputs. Measure groundedness, class-specific precision and recall, action validity, policy violations, calibration, abstention, reviewer agreement, latency, and cost. Test prompt injection, poisoned retrieval, tool errors, model outage, and drift after new devices or incident types appear.
The safest AI-assisted closed loop separates stages. Telemetry produces a bounded finding. The model returns structured advice with citations, alternatives, uncertainty, and tests. Deterministic schema and policy checks reject unsupported or excessive scope. A human approves an exact target-bound plan. A separate least-privilege executor applies one canary. Independent service checks determine success or rollback. The model holds no execution credential.
Three projects that integrate the domains
The model-driven automation service discovers IOS XE capabilities, normalizes YANG state, handles sparse and malformed payloads, computes an idempotent plan, tests pagination and rate limits, applies a canary, verifies service behavior, and demonstrates rollback. The key deliverable is not a script that runs once; it is evidence that retries, conflicts, and failure paths are safe.
The GitOps delivery pipeline combines protected Git workflow, Terraform state, Ansible intent, pinned dependencies, secret prevention, policy checks, signed artifacts, target-bound approval, canary and wave rollout, drift detection, and rollback. It demonstrates why source control, state, artifacts, credentials, and operational validation are distinct assets.
The governed AI NOC assistant builds an access-filtered knowledge index and synthetic incident pipeline. It returns evidence-linked advice, is tested against stale and conflicting data, prompt injection, dangerous recommendations, and unsupported platforms, and can only reach a separate canary executor after policy and human approval. The lab ends by deleting identities, embeddings, prompts, logs, and targets.
A ten-week preparation plan
| Weeks | Focus | Evidence |
|---|---|---|
| 1–2 | Python, JSON/XML, YANG, NETCONF, RESTCONF, authentication, pagination, retries, and tests | Capability inventory, parser tests, stable semantic plans |
| 3–4 | Git, Terraform, Ansible, containers, state, secrets, dependencies, and artifacts | Reviewed source, protected state, signed immutable bundle |
| 5–6 | CI/CD, canary and waves, SLI/SLO, telemetry health, incident response, rollback | Pipeline gates, service checks, failure and recovery timelines |
| 7–8 | AI tasks, embeddings, RAG, prompt injection, governance, evaluation, and drift | Model card, adversarial test set, abstention and override results |
| 9–10+ | Three projects, 50 questions, 40 cards, timed performance reasoning | Architecture, approvals, tests, rollback, cost, privacy, cleanup |
Use the five-phase AUTOCOR roadmap as the checklist. Review 40 flashcards with spaced retrieval. Answer the 50 original questions and explain why each distractor violates a contract, misses a prerequisite, expands authority, or fails to validate the outcome.
Performance-based and scenario strategy
Begin by identifying the lifecycle stage: source, build, artifact, plan, approval, execution, state, telemetry, incident, or AI recommendation. Then identify the failure domain and authority boundary. Ask what is known, what is assumed, what can change, and what evidence would prove the result.
For APIs, inspect capabilities and current state before mutation. For IaC, review the exact plan and target. For operations, distinguish source failure from service failure. For AI, separate retrieved evidence from model-generated claims and authorization. In ordering items, prefer discover, validate, approve, apply, verify, and recover.
Beware absolute language. A valid signature does not prove safe content. A Terraform plan does not stop external drift. A container does not eliminate host risk. RAG does not guarantee truth. A high model confidence does not grant authority. A successful API status does not prove the application path.
Official references
- Cisco 350-901 AUTOCOR exam page
- AUTOCOR v2.0 exam topics
- Cisco IOS XE programmability configuration guide
- Cisco Catalyst Center platform documentation
- Cisco artificial intelligence solutions
- Cisco responsible AI
- Terraform state documentation
- Ansible network automation concepts
- GitHub Actions documentation
Continue preparation
- AUTOCOR roadmap
- 50 AUTOCOR questions
- 40 AUTOCOR flashcards
- Three AUTOCOR projects
- Cisco ENCOR study guide
- All roadmaps
- Editorial policy
Frequently asked questions
What is the AUTOCOR exam version and duration?
Cisco identifies 350-901 AUTOCOR v2.0 as a 120-minute exam. Verify the official page before scheduling.
Which formats can appear?
Cisco lists performance-based, multiple-choice, and drag-and-drop formats.
What are the domain weights?
Network Automation 30%, Infrastructure as Code 30%, Operations 20%, and AI in Automation 20%.
Does this guide state a fixed live question count or passing score?
No. Fifty is only the size of PrepKloud's original practice bank. Consult Cisco's current exam information for published logistics.
How should AI be used in network automation?
Use it for bounded correlation, explanation, prediction, and recommendation. Keep evidence authorization, policy, approval, scoped execution, independent validation, and rollback outside the model.
Are the practice materials exam dumps?
No. They are independently authored educational scenarios grounded in public objectives and official documentation.