CCNA Automation (Cisco, exam 200-901)Study guide

Covers the traits of the three data-interchange formats JSON, YAML, and XML, and the judgment of parsing each into Python data structures (dict, list) to extract values, framed as interpreting and diagnosing given artifacts: "how do I read this response/config and where do I pull a value from?" and "why did the load fail?"

Covers when to use the waterfall, agile, and lean methodologies, the red -> green -> refactor cycle of test-driven development (TDD) that writes tests before implementation, and the role of unit tests, framed as the judgment/diagnosis of "which approach fits this requirement volatility?" and "how do I respond to this failing test?"

Covers organizing code with functions/methods, classes, and modules/packages, plus the MVC pattern that separates responsibilities and the Observer pattern that notifies subscribers of state changes, framed as the design judgment of "how do I split this monolithic script?" and "which pattern fits this notification requirement?"

Covers the benefits of version control with Git, the roles of clone, add, commit, push/pull, branch, and merge, plus resolving a merge conflict and reading a unified diff (@@ hunks and +/- lines), framed as interpreting and diagnosing given artifacts: "what does this git output mean and what do I do next?"

Covers assembling a REST API request that accomplishes a task from the API docs: the HTTP method (GET/POST/PUT/PATCH/DELETE) and endpoint (URL), headers such as Content-Type/Accept/Authorization, query parameters, and the JSON request body, together with the Basic authentication, API key, and Bearer token (OAuth) authentication schemes, framed as the diagnosis of "does my request match what the docs demand?"

Covers reading the parts of an API response—the status code (2xx success / 3xx redirect / 401 unauthenticated, 403 forbidden, 404 not found, 429 rate exceeded / 5xx server-side), the response headers (Content-Type, Retry-After, WWW-Authenticate, etc.), and the response body (JSON containing an error message)—and troubleshooting by isolating the cause from the triad of code + the request you sent + the docs.

Covers webhooks that push a notification from the server to the client on an event (the inverse of polling), and the constraints you inevitably meet when consuming APIs—rate limiting that caps calls per unit time (429, Retry-After, exponential backoff) and pagination that splits large data (limit/offset, cursors, next links)—framed as the judgment/diagnosis of "polling vs. webhook for this requirement" and "how to handle this 429 or truncated data."

Covers the difference between resource-oriented, stateless REST (operating URL-addressed resources with HTTP methods) and RPC designed as a call to a procedure (function), plus choosing between synchronous (the caller waits for the response) and asynchronous (the request is merely accepted and the result returned later, 202 Accepted + polling/callback), framed as the design judgment of "which style fits this requirement and this processing time."

Covers building a script that calls a REST API with Python's requests library—sending requests via requests.get(url, headers=, params=, auth=) / requests.post(url, json=) and reading resp.status_code (checking the code, resp.raise_for_status()), resp.json() (parsing the JSON body into a dict), and resp.headers—framed as the diagnosis/fix of "what is wrong in this requests script and why does it not behave as expected?"

Covers how an SDK (a language-specific library) abstracts raw REST calls, and the scope of the main network-management platforms—Meraki (Dashboard API), Catalyst Center (Intent API), ACI (APIC), Catalyst SD-WAN, and Cisco NSO—framed as the judgment of "which platform's API to choose for this requirement."

Covers compute (UCS Manager's on-prem XML API and Intersight's cloud REST), collaboration (the Webex API and CUCM's AXL/UDS), and security (XDR, Firepower (FMC), ISE (ERS), Secure Malware Analytics), framed as the judgment of "which domain's API solves this operational requirement."

Covers the on-box APIs of IOS XE/NX-OS and the three pillars of model-driven programmability—YANG (data-model definition), NETCONF (XML/SSH with datastores), and RESTCONF (HTTP+JSON/XML, CRUD<->HTTP methods)—as response interpretation and method selection. It also pins down DevNet learning/testing resources (Sandbox, Code Exchange, Learning Labs, API docs).

Covers typical tasks—fetching a device list (Catalyst Center Intent API/Meraki), posting a message to Webex, and fetching a client list (Meraki)—as the construction judgment of "requirement -> which platform's endpoint and HTTP method to assemble," along with diagnosing faulty scripts (missing auth, wrong endpoint, method mismatch).

Frames "where to run an app" as choosing among the private / public / hybrid / edge cloud models, edge computing (processing near the data source), and the runtime substrate—virtual machine (VM), bare metal, and container—as the judgment of "which fits this requirement (latency, isolation, performance, portability)."

Covers the CI/CD pipeline that delivers code safely (automating build -> test -> deploy), the unit tests that guard changes (Python unittest/pytest), and the Dockerfile (FROM/RUN/COPY/CMD/EXPOSE) plus the image-and-container relationship that makes an app portable—framed as reading/diagnosing "what this pipeline/Dockerfile guarantees, and where it is wrong."

Covers secret management for handling credentials safely (environment variables/secret stores, never committing plaintext) and encryption (at rest and in transit), the roles of the firewall, DNS, load balancer, and reverse proxy, and the representative OWASP threats (XSS, SQLi, CSRF)—framed as diagnosing "what this handling protects and where the hole is."

Covers the basic bash commands used in deployment/operations (file/directory ops—ls/cd/pwd/mkdir/cp/mv/rm/cat, and environment variables export/env) as reading "what this command sequence does," and the DevOps principles (culture, automation, measurement, sharing) as the judgment of "why this practice creates value."

Covers the value of moving from manual CLI configuration to Infrastructure as Code (IaC), the IaC principles of being declarative, idempotent, and version-controlled, and choosing between device-level automation that touches each device directly and controller-level automation that goes through a controller's intent, framed as the judgment of "at which layer should this operational problem be automated."

Covers the CI/CD pipeline (lint -> test -> deploy) for shipping network changes safely, Cisco Modeling Labs (CML) for trying changes in a virtual lab, pyATS for validating state, and the strengths of Ansible (agentless, idempotent), Terraform (declarative, state management), and Cisco NSO (multi-vendor, service model), framed as the judgment of "what does this pipeline stage protect" and "which tool for this requirement."

Builds the ability to read a given Python (requests/SDK) script, Ansible playbook, or bash script and determine "what it automates, on which devices, and how." From hosts/tasks/modules/loops/backup/when conditions you judge whether it is idempotent config delivery, information gathering, or backup, and learn to spot dangerous operations (unconditional save/reload).

Builds the ability to read RESTCONF/NETCONF responses (JSON/XML, <ok/>, rpc-reply), the underlying YANG data model (the container/list/leaf hierarchy), and the unified diff representing change (the @@ hunk, +/- lines), so you can judge "is this response success or failure," "what does this part of the model represent," and "what does this diff actually change."

Builds the ability to grow automation code safely through code review principles (small PRs; emphasis on readability/correctness/security; knowledge sharing) and their benefits, and to read the order and dependency of API calls (token fetch -> GET -> 429 -> retry, etc.) from a sequence diagram (actors/lifelines, request/response arrows, time flowing top to bottom).

As the prerequisite for an automation script or API client to actually reach its target, this section covers L2 MAC addresses and VLANs, and L3 IP addresses, subnet mask/prefix, routing, and the default gateway—framed as the connectivity diagnosis of "why can only this host not reach the API."

Covers the roles of the switch, router, firewall, and load balancer (LB); reading topology diagrams and interface/port values; and the view that splits a device into the management plane, control plane, and data plane—framed as the judgment of "which plane automation touches and which device along the path can stop an API call."

Covers the common IP services apps/automation depend on—DHCP (auto IP assignment), DNS (name resolution), NAT (address translation), SNMP (monitoring), NTP (time sync)—and the port numbers to memorize (SSH 22 / Telnet 23 / HTTP 80 / HTTPS 443 / NETCONF 830 / SNMP 161 / NTP 123 / DNS 53 / DHCP 67-68), framed as the diagnosis of "which missing service breaks an API call and how."

Systematically isolates app/automation connection failures as NAT translation issues, port blocking by firewalls, the need to traverse a corporate proxy, VPN connection/split-tunnel behavior, and the effect of network constraints such as latency/MTU/rate limits on apps. Builds the diagnostic skill of linking "error symptom -> the network factor to suspect -> the verification command."