Exam Objective 5.3: Describe network management approaches (device-based, cloud-based, controller-based, automation-based, and infrastructure as code).
As networks have grown in scale and complexity, the way administrators actually manage and configure devices has evolved through several distinct approaches, each suited to different scales of operation. This objective is descriptive: you need to recognize each of the five management approaches, understand their core characteristics, and know their relative tradeoffs — particularly scalability, consistency, and the degree of manual, per-device effort each one requires.
Device-based management (sometimes called the traditional or legacy approach) means configuring and managing each network device individually, one at a time, typically through its own CLI (console, SSH, or Telnet) or a local web GUI.
Key characteristics:
Every configuration change is made directly on each individual device
No centralized visibility or control across multiple devices — an administrator must log into each device separately to view or change its configuration
Everything covered so far in this study guide (interface configuration, VLANs, OSPF, ACLs, NAT, and so on) has been presented from this device-based CLI perspective
Advantages:
Simple and direct — no additional infrastructure (controllers, orchestration platforms) required
Full, granular control over each individual device's exact configuration
Well suited to small networks with a limited number of devices
Disadvantages:
Does not scale — managing hundreds or thousands of devices individually becomes operationally unmanageable
Prone to configuration drift and inconsistency, since each device is configured independently and nothing automatically enforces that every device follows the same standard
Time-consuming for any change that needs to be applied across many devices simultaneously (a single ACL update needing to be pushed to 200 branch routers, for example)
Exam Alert: Device-based management is the baseline, traditional approach — every other approach in this objective exists specifically to address the scalability and consistency limitations inherent to managing devices one at a time.
Cloud-based management uses a cloud-hosted (SaaS, Software-as-a-Service) platform to centrally manage network devices, with the management/control plane itself hosted off-premises by the vendor rather than on local hardware the organization owns and maintains.
Key characteristics:
The management platform itself lives in the cloud (accessible via a web browser or app from anywhere with internet connectivity), rather than requiring an administrator to be on the local network or VPN'd in to reach an on-premises management server
Devices "phone home" to the cloud platform for configuration, monitoring, and policy updates, typically over an encrypted connection back to the vendor's cloud infrastructure
Common examples in the Cisco ecosystem include Meraki (a fully cloud-managed networking product line) and cloud-hosted monitoring/management dashboards for other product families
Advantages:
Centralized visibility and management across multiple sites without needing to maintain on-premises management server infrastructure at each location
Simplifies management for organizations with many geographically distributed small sites (retail chains, branch offices), since a single cloud dashboard can oversee devices at every location
Automatic platform updates/improvements are handled by the vendor rather than requiring the organization to manage upgrade cycles for the management platform itself
Disadvantages:
Requires reliable internet connectivity for full management functionality, since the management plane itself lives off-site
Introduces dependency on a third-party vendor's cloud infrastructure and its availability/security practices
May raise data sensitivity/data classification considerations (tying back to objective 5.2) regarding what network configuration and telemetry data is being sent to and stored by an external cloud provider
Exam Alert: The defining characteristic of cloud-based management is that the management/control plane itself is hosted off-premises by a third party (typically the vendor), accessed over the internet — distinguishing it clearly from controller-based management, where the controller is more commonly (though not always) deployed on the organization's own premises or private infrastructure.
Controller-based management centralizes configuration and policy management through a dedicated controller platform that communicates with and manages many individual network devices, separating the control plane (decision-making) from the data plane (actual traffic forwarding) on those managed devices.
Key characteristics:
A centralized controller pushes configuration and policy to managed devices, rather than an administrator configuring each device's CLI directly
The controller often provides a graphical interface and/or a northbound API allowing administrators (or other software/automation tools) to define policy once, centrally, which the controller then translates and pushes out to every relevant managed device
Cisco DNA Center (now often referred to as Catalyst Center) and Cisco's Wireless LAN Controller (WLC, already referenced back in objective 2.2 for controller-based access points) are prominent Cisco examples of this approach
Can be deployed on-premises or, increasingly, delivered itself as a cloud-hosted platform — meaning controller-based and cloud-based approaches can overlap in modern deployments rather than being strictly mutually exclusive categories
Advantages:
Centralized policy definition and consistent enforcement across potentially very large numbers of devices, directly addressing device-based management's consistency/drift problem
Simplified large-scale changes — updating a policy once at the controller propagates that change out to every managed device, rather than requiring an administrator to individually touch each device
Often provides richer visibility, analytics, and troubleshooting tools than what's available from any single individual device's own local interface
Disadvantages:
Introduces a new critical piece of infrastructure (the controller itself) that must be available, secured, and maintained — a controller outage can impact the ability to manage or, in some designs, even the operation of managed devices
Generally requires devices that are actually controller-compatible/manageable, which can mean additional licensing or hardware/software requirements compared to simple, standalone device-based management
Exam Alert: Controller-based management is defined by centralizing configuration/policy through a dedicated controller platform, separating control-plane decision-making from the individual managed devices — recognize DNA Center/Catalyst Center and WLC as the Cisco-specific examples most likely referenced.
Automation-based management uses scripts and automation tools to programmatically configure, verify, and manage network devices, rather than an administrator manually typing commands into each device's CLI one at a time.
Key characteristics:
Configuration tasks are defined in a script, playbook, or similar automation artifact, which is then executed against one or many target devices
Ansible is the most commonly referenced automation tool in the CCNA context (also referenced in objective 5.5, covered separately), using human-readable YAML-based "playbooks" to define the desired configuration state and push it out to managed devices
Can be used standalone, or combined with controller-based or cloud-based approaches — for example, using Ansible to programmatically interact with a controller's API rather than directly configuring individual device CLIs
Advantages:
Dramatically faster and more consistent than manually configuring many devices individually, directly addressing device-based management's scalability problem
Reduces human error — the exact same script produces the exact same result every time it's run, rather than being subject to a human's typing mistakes or inconsistent judgment calls across many repetitive manual changes
Changes are repeatable and can be version-controlled (tracked, reviewed, and rolled back using standard software version control practices) when the automation scripts/playbooks themselves are stored in a system like Git
Disadvantages:
Requires an initial investment in building and testing automation scripts/playbooks, along with the skill set to write and maintain them
A flawed script can propagate an error very quickly and very broadly across many devices simultaneously, exactly the same speed and consistency that makes automation powerful also makes a mistake more damaging if not properly tested first
Ties back to objective 5.1's traditional-automation-versus-agentic-AI distinction — automation-based management (in this objective's sense) generally refers to executing a defined, human-written script/playbook, distinct from agentic AI's more autonomous, self-directed reasoning
Exam Alert: Automation-based management is about programmatically executing configuration tasks via scripts/playbooks rather than manual CLI entry — Ansible is the specific tool name most likely to appear directly on the exam in this context (and is covered further in objective 5.5).
Infrastructure as Code takes the automation concept a step further conceptually: rather than just scripting individual configuration tasks, the entire desired state of the network's infrastructure is defined declaratively in code/configuration files, which are then used to actually create, modify, or tear down the infrastructure to match that defined state.
Key characteristics:
The infrastructure's desired end-state is described declaratively (what the final configuration should look like), rather than imperatively (a specific step-by-step sequence of commands to run) — the IaC tool itself figures out what changes are actually needed to bring the real infrastructure into alignment with the declared desired state
Terraform is the most commonly referenced IaC tool in the current CCNA blueprint, alongside Ansible (Terraform replaced older tools like Puppet and Chef in the equivalent automation objective in earlier blueprint versions)
IaC definitions are stored as code/text files, making them naturally suited to version control (Git), peer review, and consistent, repeatable deployment — the same underlying practices used broadly in modern software development, applied to infrastructure
Declarative vs. imperative — a key conceptual distinction:
Imperative (more typical of traditional automation/scripting) — explicitly specifies the exact sequence of steps to perform ("create this VLAN, then assign this interface to it, then configure this IP address")
Declarative (the IaC/Terraform model) — specifies only the desired final state ("this network should have a VLAN 10 with these properties"), and the tool itself determines and executes whatever specific actions are needed to reach that state, including detecting and correcting any drift if the actual state doesn't currently match
Advantages:
Extremely consistent, repeatable, and auditable — the exact desired state is documented directly in code, and changes to that code are tracked with full history
Naturally supports detecting and correcting configuration drift, since the IaC tool can compare actual current state against the declared desired state and reconcile any differences
Enables infrastructure to be treated with the same rigor and collaborative review processes (code review, testing, staged rollout) already standard in modern software development
Disadvantages:
Requires a genuine shift in operational mindset and skill set, moving from direct hands-on device configuration toward writing and maintaining declarative code
Like automation-based management, a flawed declarative definition can propagate incorrect changes broadly and quickly if not properly tested/reviewed first
Exam Alert: The declarative (desired end-state) versus imperative (explicit step-by-step) distinction is the single most important conceptual anchor for IaC, and it's what separates IaC specifically from more general automation-based management, even though the two categories clearly overlap and are frequently used together in practice. Know Terraform as the specific IaC tool name most associated with this concept on the current blueprint.
Device-based: Individual, manual, CLI/GUI per device — simplest, but does not scale and is prone to inconsistency.
Cloud-based: Management plane hosted off-premises by a vendor, accessed via the internet — centralizes multi-site visibility without on-prem management infrastructure, but depends on internet connectivity and a third-party provider.
Controller-based: A centralized controller platform pushes configuration/policy to many managed devices — strong consistency and centralized visibility, but introduces the controller itself as a new critical piece of infrastructure.
Automation-based: Scripts/playbooks (commonly Ansible) programmatically execute configuration tasks — fast, consistent, and repeatable, but requires script development and testing investment.
Infrastructure as Code: Declarative code (commonly Terraform) defines the desired infrastructure state, and the tool reconciles actual state to match — highly consistent, auditable, and drift-correcting, representing the most software-development-like approach of the five.
Exam Alert: These five approaches are not always mutually exclusive in real deployments — a modern network might use a cloud-hosted controller (blending cloud-based and controller-based), managed in turn via Ansible playbooks or Terraform configurations that interact with that controller's API (blending automation-based/IaC with controller-based). The exam is nonetheless likely to test each category's defining characteristic in isolation, so know what specifically distinguishes each one even though real-world deployments often combine them.
When presented with a scenario, ask:
Is the administrator configuring one device directly, one at a time? → Device-based
Is the management platform itself hosted by a vendor off-premises, accessed over the internet? → Cloud-based
Is there a centralized controller pushing policy/configuration to many managed devices, separating control-plane decisions from the devices themselves? → Controller-based
Is a script or playbook (like Ansible) being executed to programmatically carry out a defined sequence of configuration tasks? → Automation-based
Is the desired end-state of the infrastructure being declared in code (like Terraform), with the tool determining and reconciling whatever changes are needed to reach that state? → Infrastructure as Code
Q1. Which network management approach involves an administrator directly configuring each individual device's CLI or local GUI, with no centralized platform involved?
A. Cloud-based
B. Controller-based
C. Device-based
D. Infrastructure as code
Answer: C. Device-based management is the traditional approach where each device is configured and managed individually, typically via its own CLI or local web GUI, without any centralized management platform coordinating changes across multiple devices.
Q2. A large retail chain manages Wi-Fi and switching equipment across hundreds of small store locations using a single vendor-hosted dashboard accessible from any web browser, with no on-premises management server required at any individual store. Which management approach does this best describe?
A. Device-based
B. Cloud-based
C. Automation-based
D. Infrastructure as code
Answer: B. This scenario describes cloud-based management — the management platform itself is hosted off-premises by the vendor and accessed over the internet, allowing centralized visibility and control across many distributed sites without requiring the organization to deploy and maintain its own on-premises management infrastructure at each location.
Q3. Which network management approach is specifically characterized by separating the control plane (centralized decision-making) from the data plane on individual managed devices, using a dedicated centralized platform to push configuration and policy?
A. Device-based
B. Controller-based
C. Cloud-based only
D. There is no such distinction in network management
Answer: B. Controller-based management centralizes configuration and policy decisions through a dedicated controller platform (such as Cisco DNA Center/Catalyst Center or a Wireless LAN Controller), which then pushes that configuration out to many managed devices — separating centralized control-plane decision-making from the devices actually forwarding traffic.
Q4. An administrator writes an Ansible playbook that defines a specific sequence of configuration steps to be executed against 50 branch routers, ensuring the exact same commands run identically on every device. Which management approach does this represent?
A. Cloud-based
B. Infrastructure as code
C. Automation-based
D. Device-based
Answer: C. This describes automation-based management — using a script or playbook (Ansible being the most commonly referenced tool in this context) to programmatically execute a defined sequence of configuration tasks across many devices, rather than manually configuring each device's CLI individually.
Q5. Which statement correctly distinguishes the declarative approach used in Infrastructure as Code from a more traditional imperative automation script?
A. Declarative IaC specifies an exact step-by-step sequence of commands to run, while imperative automation only specifies the desired end-state
B. Declarative IaC specifies only the desired end-state of the infrastructure, and the tool determines what actions are needed to reach it, while imperative automation explicitly specifies the exact sequence of steps to perform
C. There is no meaningful difference between declarative and imperative approaches
D. Declarative IaC cannot be version-controlled, while imperative scripts can
Answer: B. In the declarative IaC model (associated with tools like Terraform), the desired final state of the infrastructure is defined, and the tool itself figures out and executes whatever specific changes are needed to bring the actual infrastructure into alignment with that declared state. Imperative automation, by contrast, explicitly specifies the exact sequence of steps to carry out, without the tool independently reasoning about the current-versus-desired state gap.
Q6. Which of the following is a disadvantage shared by both automation-based management and Infrastructure as Code, as compared to simple device-based management?
A. Both require devices to be manually configured one at a time
B. Both require an initial investment in developing and properly testing scripts or declarative definitions, and a flawed script/definition can propagate errors broadly and quickly across many devices
C. Neither approach can be used at any scale larger than a single device
D. Both approaches eliminate the need for any network devices at all
Answer: B. Both automation-based management and Infrastructure as Code require upfront investment in building and testing the scripts, playbooks, or declarative definitions used to drive configuration changes. Because both approaches can apply changes quickly and consistently across many devices simultaneously, an error in the underlying script or definition can also propagate broadly and quickly if it wasn't properly tested and reviewed beforehand — a risk not present in the same way with manual, one-device-at-a-time device-based management.