CCNA Network Management Approaches: Device, Cloud, Controller, Automation and Infrastructure as Code

The five network management approaches in CCNA exam topic 5.3 are device-based (configure each device on its own), cloud-based (a vendor-hosted platform manages the devices over the internet), controller-based (a central controller you run manages the devices), automation-based (scripts or tools do the per-device work) and infrastructure as code (the intended configuration lives in version-controlled files that a pipeline deploys). They differ in where the intended configuration is kept, who runs the management platform and how a change reaches the devices.

The approaches are not mutually exclusive. A controller can be driven by scripts through its API, an IaC pipeline can use an automation tool such as Ansible to apply its files, and every approach still leaves the device CLI available for emergencies. What the exam looks for is recognising which approach a scenario describes and which one a set of constraints calls for.

Device-based management, also called traditional or box-by-box management, means each switch, router or access point is configured and monitored on its own, normally through its CLI over SSH or the console port. An engineer who adds a new login banner to three routers by connecting to each one in turn and typing the same lines is using device-based management: the change is identical everywhere, but it is made device by device.

Where it works and where it breaks

• Works: small networks with a handful of devices, lab work, and troubleshooting a single device. It needs no extra servers, subscriptions or licences.
• Breaks at scale: every change is repeated by hand, so it is slow, and people skip devices, mistype values or follow an old procedure. The configurations slowly diverge from each other and from what the team believes is deployed. This is configuration drift.
• No network-wide view: nothing compares one device with another, so inconsistencies (a syslog server that was changed on most routers but not all, a VLAN name that differs between closets) are found only by an audit.

Why per-device habits cannot remove drift

Drift under device-based management is a structural problem: there is no single definition of what every device should look like, so each device is only as correct as the last person who touched it. Good per-device habits, such as saving the configuration, logging commands or using secure management protocols, make each device safer, but they cannot make many devices agree with each other. Consistency needs a central definition that is pushed to every device, which is what the cloud, controller, automation and IaC approaches provide.

Local access never goes away

Under every other approach the device keeps its own CLI. If the central platform is unreachable (for example while it is being upgraded), an engineer can still log in to a router and add an urgent static route; the device accepts it. The cost is that the change now exists only on that device, so the central system may later report it as a deviation, and the team has to bring it back into the central definition.

Cloud-based management means the management platform (configuration, monitoring, alerts, firmware updates, reporting) is hosted and operated by the vendor and reached through a web dashboard, with no management servers on the customer's premises. Cisco Meraki is the best-known example: switches, access points and security appliances are configured from the Meraki dashboard. It suits organisations with many small sites and little or no IT staff at each one.

What goes to the cloud and what does not

Only management data (configuration, status, statistics and logs) passes between the devices and the vendor's platform over the internet. User traffic does not: a branch switch still switches frames locally, and an access point still bridges client traffic to the local LAN. The management path is out of band from the data path.

What happens during a cloud outage

If the vendor's management service is unavailable but the site's own LAN and internet links are fine, devices keep forwarding traffic with their last configuration. Clients keep connecting. What is lost until the service returns is the management plane: making changes and seeing live monitoring through the dashboard. The forwarding behaviour of each device depends on its stored configuration, not on a live connection to the platform.

The data-location row matters most in scenarios: if a regulation or policy says configuration and telemetry must stay within the organisation's own facilities, a vendor-hosted cloud does not meet it, while an on-premises controller does.

How are cloud-managed devices onboarded (zero-touch provisioning)?

A cloud-managed device is onboarded by claiming it into the organisation in the vendor's dashboard (by serial number or order number) and assigning it to a site network; when it is then plugged into an uplink with DHCP and internet access, it obtains an address, connects out to the cloud service and downloads the configuration already assigned to it. All the configuration work happens centrally before the device arrives. This is zero-touch provisioning: the central team prepares everything in advance, and a non-technical person at the site only supplies power and a cable.

1. The administrator claims the serial number and assigns the device to the branch network, with templates or settings for that network.
2. At the site, someone connects power and an uplink.
3. The device gets an IP address, default gateway and DNS server by DHCP (or a configured static address).
4. It opens an outbound, encrypted connection to the vendor's cloud and identifies itself.
5. The cloud recognises the claimed device and sends its configuration and, if needed, firmware.

Why a strict firewall does not block it

The principle is the direction of the connection: the device initiates the management session outbound, and the platform sends its changes back over that already-established session. A stateful firewall that permits sessions started from inside therefore permits cloud management, and the device can use a private address translated by NAT/PAT, because nothing on the internet has to start a connection to it. What the site must provide is outbound reachability: DHCP or a static address, DNS, and a firewall policy that allows the vendor's documented destinations and ports.

Controller-based management means a central controller that your team runs discovers the network devices, holds the intended configuration and policy for all of them, pushes that configuration to the devices and collects their state for monitoring. Cisco Catalyst Center (formerly Cisco DNA Center) is the campus example; Cisco Catalyst SD-WAN Manager is another management controller you meet in Cisco networks. (A Wireless LAN Controller is a different kind of controller: it also carries control functions for its access points, see below.)

What a controller does

• Discovery and inventory: it finds devices (for example by IP range or CDP/LLDP) and keeps a network-wide inventory and topology.
• Templates and provisioning: one configuration template is deployed to hundreds of devices at once, with per-device variables such as hostname or management IP.
• Policy (intent): the administrator states what should happen, for example that guest devices may reach only the internet, and the controller translates that intent into the device configuration needed on every switch. The administrator does not log into each switch.
• Assurance: health scores for devices, clients and applications, built from the telemetry the controller collects, with issues and suggested actions in one view.
• Compliance: it compares devices with their intended configuration and flags deviations, such as a change made directly on the CLI.

Centralised management, not centralised forwarding

A management controller such as Catalyst Center centralises management, not packet forwarding. Each switch still forwards user traffic locally with its own data plane, under device-based and controller-based management alike; user packets do not pass through Catalyst Center. The switches also keep their local configuration, so they keep working if the controller is down, and console and SSH access to them remains available.

Wireless is the exception to remember. With a Cisco Wireless LAN Controller and lightweight access points in the default local mode, client data is tunnelled from each AP to the WLC inside CAPWAP and switched centrally there, so the WLC does sit in the data path. In FlexConnect mode with local switching, the AP bridges client traffic onto its own LAN instead. The general rule (the controller manages, the devices forward) is about management controllers such as Catalyst Center.

Changes made around the controller

The controller's templates are its definition of what devices should run; a device's running configuration does not flow back into them. So a line typed directly on one access switch, say an extra port description added during a cabling job, stays on that switch only, and the controller's compliance check is likely to flag the device as differing from its intended configuration. The team then decides: add the change to the controller's template so every device gets it, or remove it from the device.

When an on-premises controller fits

An on-premises controller fits a large campus that wants central templates, network-wide policy and assurance in one interface while keeping configuration and telemetry inside its own facilities. The deciding factors are the combination of a single interface for templates, policy and assurance with the data-location requirement.

A controller's northbound interface is the one that applications, scripts and people use to talk to the controller, typically a REST API (plus the web GUI); its southbound interfaces are the ones the controller uses to talk to the network devices, such as NETCONF, RESTCONF, SSH/CLI and SNMP. Picture the controller in the middle: applications sit above it (north), devices sit below it (south).

Recognising a northbound call

Catalyst Center's northbound REST API is called the Intent API. A client first requests a token from the controller (POST /dna/system/api/v1/auth/token) and then sends it in the X-Auth-Token header on each request to a path under /dna/intent/api/. For example, a reporting tool might request overall site health:

GET https://catalyst-center.example.com/dna/intent/api/v1/site-health
X-Auth-Token: <token>
Accept: application/json

The request is addressed to the controller, so it is northbound, even though the answer describes devices and clients. The controller answers from data it gathered earlier by talking southbound to the devices. The way to classify any interface is who is being called: the controller (northbound) or a network device (southbound). Transport and format do not decide it, because both directions can use HTTPS and JSON: RESTCONF, for example, is a device-side protocol under a /restconf/ path on the device itself, with YANG-modelled data, and NETCONF likewise runs on the device.

Automation-based management means software, rather than a person at a keyboard, does the per-device work: a script or tool reads a list of devices, connects to each one and applies the same change or collects the same data. A script that reads a spreadsheet of access switches, logs in to each one, adds the same voice VLAN and saves a report of which devices succeeded is automation-based management, and so is running an Ansible playbook against an inventory (Ansible itself is covered in its own lesson).

Benefits

• Consistency: every device receives exactly the same change, from the same template.
• Speed and scale: hundreds of devices are changed in minutes, and the same job can be re-run later.
• Repeatable records: the script and its output show what was sent where.

Mistakes scale too

The consistency that makes automation useful also spreads errors: a template with a typo in an uplink's trunk allowed-VLAN list breaks that uplink on every switch the job touches, in minutes. The answer is not less automation but controlled blast radius: prove the change before it reaches production, then expose it to a small group of devices first, so a mistake is caught while it affects few. The practices that do this are:

• Test first in a lab or virtual environment that mirrors production.
• Roll out in stages: a pilot group of devices, check the result, then the rest in batches, stopping if something fails.
• Validate before and after: pre-checks (is the device in the expected state?) and post-checks (is the route, neighbour or interface still up?).
• Dry runs: many tools offer a check mode that reports what would change without changing it.

Infrastructure as code (IaC) means the intended configuration of the network is written in definition files, kept in a version-control repository such as Git, changed through reviewed commits and deployed to the devices by an automated pipeline. The repository becomes the source of truth: what is in it is what should be on the devices.

The IaC workflow

1. An engineer edits a definition file (for example YAML data or a template) on a branch.
2. They open a pull request (merge request). Automated checks validate the syntax and policy, and a colleague reviews and approves the change.
3. The change is merged, and a pipeline (CI/CD) applies it to the devices, often with an automation tool such as Ansible doing the device work.

What version control adds

• History and diff: every change has an author, a time, a reason and an exact difference from the previous version.
• Peer review before anything reaches a device.
• Rollback by revert: because the pipeline deploys whatever the repository says, the way back is to change the repository. Reverting the bad commit restores the previous, known-good definition, and the pipeline applies it to every affected device in one run, while the history shows exactly what the bad change was. A pipeline has no judgement of its own: it applies the current repository content, good or bad.

When IaC fits

IaC fits a team that wants consistent configuration, peer review of every change before deployment and the ability to return to any earlier version, and it works with multivendor devices without buying a vendor management platform. The tooling (a Git server and a pipeline runner) is general purpose rather than a vendor product, which is why IaC is the usual answer when review, versioned rollback and a multivendor estate appear together.

A declarative definition states the desired end state (what the configuration should be) and leaves a tool to work out the commands; an imperative definition lists the exact steps or commands to run, in order (how to get there). An idempotent operation gives the same result however many times it is run: applying it to a device that is already correct changes nothing.

Both methods can end with the switch receiving CLI commands and with the same port configuration; the classification is about what the author writes, not what the device receives.

Idempotent desired-state apply

A desired-state tool reads each device's current configuration, compares it with the definition and sends only the commands needed to close the difference. That makes it safe to run on a schedule: devices that already match receive no configuration commands, and a device that has drifted is put back in line automatically. Keep two capabilities apart when you read a requirement: detecting a difference (dry runs, compliance checks and reports do this) and correcting it (an apply run does this). Idempotence is what lets an apply run be repeated freely, because it touches only what differs.

You prevent configuration drift by making one place the source of truth, routing every change through it, and continuously comparing the devices with it. Drift is any difference between the intended configuration and what is actually running, usually caused by out-of-band changes: someone changes a device directly over SSH or the console instead of through the repository, controller or dashboard.

Practices that keep the source of truth trustworthy

• Back-port emergency changes: engineers may still need SSH for emergencies, but any change made that way is committed to the repository afterwards and redeployed through the pipeline, so the repository and the device agree again.
• Detect drift continuously: the pipeline or a scheduled job compares each device's running configuration with the repository and either reports or automatically corrects the differences.
• One shared repository: every template and variable file lives in the shared repository and goes through the same review, so there is only one version of the truth.

The direction matters: changes flow from the repository to the devices. A source of truth describes what should be deployed; if it were refreshed from whatever the devices currently run, it would absorb mistakes and unreviewed changes and stop being a reference at all. Device backups are useful for recovery, but they are not the intended state.

What an enforcing pipeline does to an uncommitted change

An enforcing pipeline treats the repository as the complete intended configuration for the parts it manages: anything there that is not in the repository is drift and is removed on the next run. Suppose the repository defines a router's DNS servers as ip name-server 192.0.2.53 and an engineer adds a second name server over SSH while troubleshooting. The next run removes the added line, because only the repository defines what belongs there; the router's running or startup configuration has no say. To keep a change, commit it to the repository and let the pipeline deploy it.

You choose a network management approach by matching the scenario's constraints (number of sites and devices, staff on site, where data may be stored, vendor mix, budget and the need for review and rollback) to what each approach provides. Read the stated constraints first; they usually rule out all but one option.

In practice the approaches combine: a controller exposes a northbound API so that scripts or an IaC pipeline can drive it, and an IaC pipeline is itself a form of automation. Whichever is chosen, local CLI access remains for emergencies, and every change made that way has to be brought back into the central definition.