Network Automation Fundamentals
Configuration vs State
What you'll learn
- The difference between configuration and operational state
- The difference between desired state and actual state
- Why these distinctions matter for NTP, VLANs, interfaces, and routing
- The desired state → apply/check → actual state → validate pattern behind most automation
- Why a device can be 'configured correctly' and still not be in the state you expect
Listen to a guided explanation of this lesson.
Spoken narration isn't supported in this browser.
Two different questions about the same device
"Is this switch configured for NTP?" and "is this switch actually synced to NTP?" sound like almost the same question. They're not, and the gap between them is one of the most important ideas in this whole module.
Configuration is what you've told the device to do — the lines sitting in show running-config: ntp server 10.0.0.5. It's intent, written down.
Operational state is what the device is actually doing right now — the live, current condition of the device, which you see with commands like show ntp status, show ip interface brief, or show vlan brief. It's reality, as of this moment.
A switch can have a perfectly correct NTP server configured and still not be synced — maybe the server is unreachable, maybe the clock hasn't converged yet. The config line existing and the switch actually being synced are two different facts, and only one of them is visible in show running-config.
A useful pair of questions
For almost anything on a network device, you can ask "what is it configured to do?" and "what is it actually doing?" separately — and network automation cares about both, not just the first one.
The same split, across common examples
- NTP — configuration:
ntp server 10.0.0.5in the config. Operational state:show ntp status— is it actually synced? - Hostname — configuration:
hostname SW-EDGE-01in the config. Operational state: what the device currently reports itself as. - VLAN — configuration:
vlan 20defined, interface assigned to it. Operational state:show vlan brief— is the port actually in VLAN 20 right now? - Interface — configuration:
no shutdown, speed/duplex set. Operational state:show interfaces— is the link actually up, at the expected speed? - Routing — configuration: a static route or routing protocol configured. Operational state:
show ip route— is that route actually present in the table right now?
Every example makes the same point: configuration is what you asked for. Operational state is what's true. Automation that only checks configuration can be confidently wrong about state.
Desired state vs. actual state
Zoom out from a single device and the same split shows up at the level of "what should be true across the network" versus "what is true right now":
- Desired state — what you want to be true. "Every access switch should have VLAN 20 trunked on its uplink." This is usually written down somewhere (a template, a standard, or, more formally, a source of truth).
- Actual state — what's really configured and running on the devices, right now, today.
Automation exists to close the gap between these two — and closing that gap is a repeating four-part pattern:
- Desired statewhat you want to be true
- Apply / checkpush the config, or just inspect what's there
- Actual statewhat's really on the device now
- Validatedoes actual state match desired state?
Notice this pattern covers both making a change and just checking one. If you're pushing a new VLAN, "apply" means sending the config. If you're running a compliance check, "apply" is skipped — you go straight from desired state to inspecting actual state, then validate the two match. Same shape, whether or not anything gets changed.
Why "configured correctly" isn't the finish line
It's worth sitting with why this distinction matters in practice, not just in theory. Picture a script that pushes VLAN 20 to fifty switch ports and, immediately after, checks show running-config on each one to confirm the line is there. Every switch shows the VLAN assignment in its config. Success — right?
Not necessarily. show vlan brief might show three of those ports still showing the old VLAN, because the interface needed a shutdown/no shutdown cycle to pick up the change, or because the port is actually down and hasn't applied anything yet. The configuration is correct on every switch. The operational state isn't, on three of them. A script that only checked configuration would report a clean success and miss all three.
Configuration confirms intent; state confirms reality
Checking that a config line exists proves you asked for something. It doesn't prove the device is actually doing it. Good automation validates against operational state — actual state — not just against the configuration it just pushed.
Where this leads next
This desired-state → actual-state pattern raises an obvious question: if a script re-checks a device that's already correct, what should happen? The next lesson — idempotency — is entirely about answering that.
Key takeaways
- Configuration is what a device is told to do; operational state is what it's actually doing right now — they're related but different facts.
- The same split applies across NTP, hostname, VLANs, interfaces, and routing: intent (config) vs. reality (state).
- Automation follows a repeating pattern: desired state → apply/check → actual state → validate — whether or not a change is actually being made.
- A config line existing proves intent, not outcome. Good validation checks operational state, not just configuration.
- Assuming configuration and state always match is exactly how automation ends up confidently reporting success on a change that didn't fully take effect.