Operations

The first two domains build and deliver a change; this one runs it in production, and production is where a green HTTP 200 hides a network that is unwatched, unproven, or exposed. The whole domain hangs on one model: three operational concerns wrap every automated change. You observe it, streaming the device's own state and logging what your code actually did; you verify it, reading a failure down to the layer that broke and proving the result with a structured before-and-after diff; and you secure it, presenting a trusted identity on the wire and writing code that validates its input, scopes its tokens, and keeps secrets off disk. The trap the domain sets in a dozen costumes is trusting the happy path: a 2xx response, a green log line, or a verify=False shortcut that all look fine while the system is blind, unproven, or wide open. Decide whether a question is really about observing, verifying, or securing, and the discipline it wants usually names itself.

At one fifth of the 350-901 blueprint (20%, level with AI in Automation and behind Network Automation and Infrastructure as Code at 30% each), Operations is compact, so read this page as a map and follow the six subtopics in order. The first two make the running system observable. Model-Driven Telemetry Architecture replaces Simple Network Management Protocol (SNMP) polling with a push model, where you create one subscription and the device streams YANG-modeled operational data to your collector (RFC 8641 YANG-Push); reach for it when you need live device state at scale. Logging Strategy: Syslog and Webhooks turns your automation's own events into a stream, routing every record through Python's logging framework and fanning it out to a syslog collector or a webhook endpoint; reach for it to make an automation run traceable. The next two prove the system is right. Diagnosing Automation Problems is triage: when a call fails, isolate the layer that broke (connectivity, then Transport Layer Security (TLS), then authentication, then the request itself) and read the protocol's own RESTCONF or NETCONF error body, not just the status line; reach for it when something broke and you must find why. Change Validation with pyATS is proof: snapshot structured state before and after a change with the pyATS command-line tools so the diff reports only real changes and stays quiet about volatile counters; reach for it to confirm a change did exactly what you intended. The last two keep all of it trustworthy. CA-Signed TLS Certificates is verifiable identity on the wire: a certificate authority (CA) signs a binding between a public key and a name, and a public CA proves you control the domain through an Automatic Certificate Management Environment (ACME) challenge; reach for it when a service must present a trusted TLS identity. Secure Coding Practices hardens the code that drives it all, validating untrusted input against allow-lists, authenticating with scoped short-lived tokens, and keeping secrets out of source and off disk (OWASP Secure Coding Practices); reach for it whenever automation handles external input or credentials. Each subtopic holds the mechanisms and the traps; this page only shows how they connect.

Across every subtopic the exam rewards the same instinct: keep the system legible and never switch off a safety to make things work. Prefer structured data over scraped text, whether that is YANG telemetry over SNMP walking, JSON logs over free-text lines, or a Genie diff over eyeballed show output, because structure is what a collector, a query, or an assertion can act on. Prefer reading the real error over guessing at a fix, and prefer the smallest change that clears the bar. And never disable a protection because it is in the way: turning off certificate verification (verify=False), hardcoding a token, or committing a secret each makes the call succeed today and costs you trust tomorrow. When two options both function, the exam-correct one is the choice that leaves you able to see, prove, and trust the outcome.