Automation: from CLI craft to config as code

Configuring devices one command line at a time is a craft, and it was a good one. It also scales with headcount and with nothing else, which is why it lost. The failure is not typing speed and it is not the number of devices on its own. It is that a command line session gives you no way to say what a device should hold, so there is nothing to compare the device against when it stops behaving.

Three specific weaknesses do the damage. The first is that a hand-typed change is not a transaction. Twelve lines pasted into a session are twelve separate events, and if the seventh is rejected the device is left in a state nobody wrote down and nobody intended. The second is that there is no reference copy. The running configuration is the only record of what the device holds, so the question "is this box configured correctly" can only be answered by reading it and forming an opinion. The third follows from the first two: drift. Across three hundred devices configured by six engineers over four years, small divergences accumulate silently, and the estate ends up with three hundred separate records that disagree with each other in ways nobody can enumerate.

None of this is an argument that engineers were careless. It is an argument that the interface offered no place to put the intention. A command changes a device. It does not record why, it does not record what the device was supposed to look like afterwards, and it cannot be checked before it lands. Automation, done properly, is the practice of adding those missing things, and the tooling below exists to hold them.

This is a later step in a move the practice stage already began. The remote-access module there described a branch office where policy, rather than static routing typed into each box, decides which link every application takes, which is the deciding logic leaving the device. Control placement is the general form of that question: whether the logic that decides forwarding sits on each device, on a regional controller, or in one central platform. Once it can sit somewhere other than the box, the configuration of the box stops being the interesting artefact. What matters is the description that produced it, and a description is a file rather than a session.

The industry evidence points one way, and it deserves the same scepticism this course applies to every other adoption figure. Industry surveys report network management automation rising from roughly 44 percent of organisations in 2024 towards two thirds by early 2026. That is a range from self-reported surveys rather than a single dated measurement taken from the network itself, which is why the diagram above carries no percentage: there is no one observatory to attribute it to, and a figure without a named method does not belong inside a teaching diagram. Treat it as a direction with a rough magnitude, not as a data point you would quote to a board without saying where it came from.

Even read cautiously, the direction changes who has to justify themselves. When most organisations of any size run some automation, a team that configures by hand is no longer the default that needs no explanation. It is the exception, and it carries costs that are now visible: slower change, no audit trail beyond memory, and a hiring problem, because the people it wants to hire were examined on the other approach.

Saying the intention has to be written down somewhere is easy. The harder question is what it should be written in, because a text file full of commands has all the same weaknesses as typing them. The answer that the industry converged on is to describe the device with a schema first and generate the commands second, and that is where the five named pieces come in.

The model-driven stack has five parts, and the useful thing about them is that they divide the work cleanly. Each one owns a different kind of failure, so naming the parts is how you turn "the automation is broken" into a question somebody can answer.

YANG, specified in RFC 7950, is the schema. It describes a device's configuration and state as a typed hierarchy: which fields exist, what shape they take, which values are legal, and which ones depend on others. A YANG model is not a config and it is not a script. It is the contract that says what a device will accept, published by the vendor or by an operator group, and readable by a tool before anything is sent. When a change is refused because a field does not exist or a value is out of range, that is a schema failure, and it should be caught long before a device sees it.

NETCONF, specified in RFC 6241, is the transaction protocol. It carries remote procedure calls, which are structured requests that ask the device to do one thing and hand back a result, encoded in XML over a secure session, and it acts on named datastores rather than on a terminal. That word "datastore" is where its value lives. A change can be written into a candidate datastore, examined, then committed to the running configuration as one unit, which means the twelve-line change either lands entirely or does not land at all. NETCONF also defines a confirmed commit: the change applies, and unless the operator confirms it within a time limit the device reverts on its own. If your session dies because the change you just made broke your own path to the device, the device undoes it without you. Failures here are transaction failures, and they look different from schema failures: the change was legal, and something about applying it did not complete.

RESTCONF, specified in RFC 8040, is the same idea with an HTTP face. It exposes the same YANG-defined data over ordinary HTTP methods carrying JSON or XML, so a team whose tooling already speaks HTTP can automate devices without acquiring a NETCONF client. The point worth holding on to is that RESTCONF does not bring its own schema. It reads and writes the same models, which means moving between the two protocols changes the transport and the tooling, not the set of things you are able to configure.

OpenConfiganswers a different problem. Vendors publish YANG models, but each vendor models its own product in its own vocabulary, so a tool that configures a routing policy on one supplier's equipment does not configure the same policy on another's. OpenConfig is a set of vendor-neutral models written by a working group of network operators rather than by any one manufacturer, so a field means the same thing across the estate. It exists because operators grew tired of maintaining a separate automation path per supplier, which tells you exactly how much of the cost of automation is integration rather than engineering.

gNMIis the piece that runs in the other direction. It is an interface, paired with OpenConfig, that lets software read and change configuration and, more importantly here, subscribe to a stream of a device's operational state. Subscription is the change of habit worth noticing: instead of polling every device every five minutes and hoping the interval is short enough, a collector asks once for the values it cares about and the device sends updates as they happen. When a device is configured correctly and the platform still shows nothing, that is a telemetry failure, and it belongs to gNMI rather than to anything on the configuration side.

Read the loop at the top of this page again with those names attached and the shape becomes obvious. YANG models the device, the render step turns the model into a candidate change, validation tests the candidate, NETCONF or RESTCONF pushes it as a transaction, gNMI streams the running state back, and a compare step measures that state against what was declared. The declared state sits in the middle because every step either serves it or reports to it.

That division is what makes the stack teachable. A change that will not validate is a schema problem. A change that will not commit is a transaction problem. A device that reports nothing is a telemetry problem. A change that works on one vendor and not another is a model problem. Four different teams, four different fixes, and the only skill required to route the question correctly is knowing which component owns which job.

The stack describes how a change reaches a device safely. It says nothing about where the change comes from, who reviewed it, or what happens to the description afterwards. Those questions have an answer that networking borrowed wholesale from software teams, and it is the part that catches outages.

Infrastructure as code, the practice Network+ made examinable, means the network you want is described in files that live in version control and are applied by a tool, rather than configured by hand. The description becomes the source of truth, and the devices become the thing that is checked against it. That inversion is the whole idea, and everything useful follows from it.

Four things arrive with version control that a command line session could never provide. There is now a reference copy, so the question "what is this device supposed to hold" has an answer that is not the device. There is a review before the change, because a proposed change is a diff that another engineer can read and argue with while it costs nothing. There is an author and a date on every line, which turns the incident question "when did this rule appear and who asked for it" from an investigation into a lookup. And there is a way back, because the previous description is still there and can be applied again.

What sits between the file and the device is the part that earns the approach its reputation. A continuous integration pipeline takes the proposed change and, before any device is touched, renders the template into a real configuration, validates that configuration against the YANG schema of the devices it is aimed at, diffs it against what those devices are currently running, and runs the organisation's own policy tests over the result. Only a change that survives all of that is pushed, and it is pushed through NETCONF into the candidate datastore with a confirmed commit, so a change that cuts off the device that received it reverts itself.

The board above has two exits, and both matter more than the happy path. The fail route stops the change before any device is touched and returns it to the author, so the mistake costs a pipeline run rather than an outage. The rollback route handles the case where the change was valid, was pushed, and then turned out to be wrong anyway: the unconfirmed commit expires, the device reverts, and the change again goes back to the author. Both routes end in the same place, which is the design point. A pipeline is not there to make changes faster. It is there to make the cost of a bad change a conversation instead of an incident.

This is where the phrase "shift left" means something concrete for networks. The classic bad half hour starts when a change is applied at 22:00, the symptom appears at 22:04, and the diagnosis begins under time pressure with no agreed description of what should have changed. Move the check to the moment the change is proposed and the same defect is a failed pipeline run at 14:30 with the diff on screen, the author present, and nothing in production affected.

Be honest about the limits, because they are where teams get hurt. A pipeline can only test what somebody modelled. A validation suite that checks syntax will happily pass a syntactically perfect outage, such as a correctly formed access rule that denies exactly the traffic the business depends on. Getting real value means writing tests that encode intent rather than form: this prefix must still be reachable from that zone, this policy must not lose its deny-by-default, this change must not reduce the number of advertised routes. Those tests are the actual asset. The pipeline is plumbing.

A pipeline that renders, validates and pushes still stops the moment the change lands. Somebody has to notice if the network drifts away from the description tomorrow, and the last step of the loop at the top of this page is the attempt to hand that noticing to the system itself.

Intent-based networking is the idea that an operator states the outcome the network should deliver, and the system works out the configuration and keeps checking that reality still matches. It is worth being precise about the status of that idea: the IRTF document that defines the vocabulary, RFC 9315, is informational. It gives the field an agreed set of words. It does not specify a protocol anyone can be conformant with, which makes this a direction of travel rather than a settled standard, and that distinction is exactly the kind this stage keeps insisting on.

The difference between a script and a closed loop is not sophistication, it is whether the work ends. A script runs, applies a change, reports success and stops caring. A closed loop declares a state, applies a change towards it, measures what the network actually did, compares the measurement with the declaration, and treats the gap as the next change. That is why the diagram at the top of this page is drawn as a cycle with the declared intent at the hub rather than as a line: the compare step feeds the model step, and the loop only rests when the measurement matches what was asked for.

Each piece you have already met has a place on that cycle. The intent is a declaration of outcome, expressed against models rather than commands. The render and validate steps are the pipeline from the previous section. The push is a NETCONF or RESTCONF transaction. The measurement arriving back is gNMI telemetry. The compare step is the one that most estates do not have, and its absence is what makes the difference between running automation and running a closed loop.

That is the honest caveat, and it needs stating plainly because vendor material tends not to. Most real deployments sit some distance behind the diagram. Four gaps are common. Model coverage is partial, so the declared state describes the parts of the estate the tooling understands and stays quiet about firewalls, load balancers and the two elderly devices nobody wants to touch. Brownfield reality means the running configuration contains years of accumulated exceptions that were never in any description, so the first honest comparison produces a list of differences too long to act on. Verification is the step that gets cut when a project runs late, because pushing changes delivers visible benefit and comparing states delivers a report. And the last gap is not technical at all: allowing a system to apply a corrective change to production without a human deciding is an organisational commitment, and plenty of organisations that bought the technology have not made it.

None of that is an argument against the direction. A loop that measures and reports but waits for a human to approve the correction is still enormously more useful than no loop, because it converts drift from something you discover during an incident into something you read on a Tuesday. The distinction to carry out of this section is between closing the loop and automating the correction. The first is a measurement discipline available to any team that has telemetry and a declared state. The second is a delegation of authority, and it is reasonable to want the first for a long time before granting the second.

The loop, its caveats and the five components are the technical content of this module. What remains is the evidence that this is settled practice rather than one school of thought, and the least arguable evidence available comes from the institutions with the strongest reason to be conservative.

Certification syllabuses are a slow, cautious form of evidence, and that is precisely what makes them useful here. An exam board carries the cost of every change: question banks are rewritten, courseware is reprinted, trainers are retrained, and candidates who prepared for the previous version have to be treated fairly. A body carrying those costs does not add a topic because it is interesting. It adds a topic when employers have been asking about it long enough that leaving it out has become the risk.

Both major entry-level networking certifications moved in 2024. Cisco published CCNA 200-301 version 1.1 in August 2024, adding generative AI, cloud network management and Ansible and Terraform to the examinable topics. CompTIA had launched Network+ N10-009 in June 2024, bringing software-defined networking and SD-WAN into scope along with infrastructure as code and VXLAN, with the previous version, N10-008, retiring in December 2024.

The CompTIA change is worth reading alongside it, because the two bodies added overlapping but not identical things. SD-WAN arriving in Network+ reflects how wide-area decisions moved from static routing policy to per-application policy, which is a change in what a network engineer is asked to design rather than a new protocol to memorise. VXLAN arriving alongside it reflects the overlay networks the practice stage covered, which is what a capture with an outer and an inner header is showing you. The common ground is infrastructure as code, named as a practice by CompTIA and represented by two of its tools, Ansible and Terraform, at Cisco.

Take the two together and the argument of this module is complete. The practice moved first, the survey numbers followed at roughly 44 percent of organisations in 2024 heading towards two thirds by early 2026, and the syllabus bodies ratified it in 2024 with real money behind the decision. An engineer who can describe a device with a schema, put the description in version control, validate it before it ships and read the telemetry that comes back is describing the current entry-level expectation, not a specialism.

One caution about the certifications themselves, since this course is used to prepare for them. A syllabus tells you what will be examined. It does not tell you what is true, and it lags reality by design. Study it as a map of the shared expectation and keep reading the primary sources for the parts that move faster than an exam board can, which is most of them.