What Can Network Automation Automate?

The pattern behind all of it

By now the shape should feel familiar: connect to a device, do something well-defined, look at the result — repeated across more than one device. Once you can see that pattern, a surprising amount of everyday network engineering work fits it.

That's really the whole test. A task is a strong automation candidate when it's:

• Repetitive — you do it more than once
• Well-defined — the steps are the same every time, with a clear right answer
• Multi-device — it happens across more than one switch, router, or other device

The categories, with real examples

Configuration changes

Pushing the same config change across many devices — for example, adding a new NTP server to every switch's config after decommissioning an old time source. The change itself (ntp server 10.0.0.5) is identical everywhere; only the device changes.

Configuration backup

Pulling and storing show running-config from every device on a schedule, so there's always a known-good copy to roll back to before and after any change window.

Compliance checking

Comparing a device's actual configuration against what it's supposed to be — like confirming every switch's show interfaces trunk output still lists the correct allowed VLANs after a firmware upgrade, or that show run | include tacacs matches the security baseline on every access switch.

Device inventory

Keeping an accurate, current list of what's actually on the network — model, software version, serial number, location — usually by running show version and show inventory across the estate and recording what comes back, rather than trusting a spreadsheet no one's updated in a year.

Monitoring

Regularly checking device or interface state — for example, running show interfaces across core switches on a schedule to catch a link with climbing CRC errors before it becomes an outage.

Reporting

Turning raw command output into something a person can actually act on — the "58 synced, 2 out of sync: SW-14, SW-27" summary from earlier, instead of 60 raw show ntp status transcripts.

Validation

Confirming a change did what it was supposed to do — after pushing a new VLAN, checking that it actually shows up in show vlan brief on every switch it was pushed to, not just assuming the push succeeded.

Provisioning

Bringing a new device into service with standard config applied automatically — hostname, management IP, AAA, NTP, baseline VLANs — instead of typing the same onboarding checklist by hand for every new switch during a refresh.

Troubleshooting assistance

Gathering diagnostic output from many devices at once during an incident — show ip interface brief, show logging, show cdp neighbors pulled from thirty branch routers in the time it would take to manually check two.

Not every repetitive task qualifies

It's worth being honest about the limits here, since the next lesson goes deeper on this: repetition alone isn't the whole test. A task that's repetitive but not well-defined — like "look into whatever seems off today" — doesn't automate cleanly, because there's no consistent procedure to encode. That kind of investigative work is exactly the sort of thing automation should be freeing up time for, not replacing.