CCNP 350-401 ENCOR: Agent vs. Agentless Orchestration Tools—Chef, Puppet, Ansible, and SaltStack Compared

1. Why This Topic Actually Matters for CCNP ENCOR

For ENCOR, you really don’t need to know how to deploy Chef, Puppet, Ansible, or SaltStack end to end. What you do need is a solid grip on the architecture behind them—agent-based versus agentless operation, push versus pull behavior, declarative versus procedural workflows, and, honestly, why those differences matter in real Cisco enterprise networks. I’d treat these tools as examples of automation and configuration-management models, not as some Cisco-approved shopping list.

That distinction matters because enterprise networks are getting automated more and more through APIs, controllers, and model-driven interfaces like NETCONF and RESTCONF. ENCOR expects you to recognize where direct device automation fits, where controller-based automation fits, and why network teams often choose different tooling than server teams.

2. Core Concepts You Must Separate

Automation is any software-driven reduction of manual effort. Orchestration is coordinated automation across multiple systems or steps to achieve an end-to-end outcome. Configuration management focuses on keeping systems in a known state over time.

A few terms are really worth keeping straight:

• Desired state: the intended end condition.
• Idempotency: running the same automation repeatedly should not create unintended changes.
• Configuration drift: actual state no longer matches approved state.
• Push model: a controller or control node initiates actions toward endpoints.
• Pull/check-in model: endpoints periodically retrieve or maintain policy communication with a central system.
• Declarative: define what state should exist.
• Procedural/imperative: define the exact steps to execute.

For ENCOR, it helps to connect this to Cisco programmability too. YANG is the structure behind the data, NETCONF usually runs over SSH, and RESTCONF usually uses HTTP or HTTPS. Those model-driven interfaces are much more structured than just scraping CLI output, and honestly, they usually make automation safer and a lot more predictable in real environments.

3. Agent-Based vs. Agentless: What’s Really Happening Under the Hood

An agent-based model installs software on the managed endpoint. That local agent then checks in with a central server, pulls down policy, and often keeps nudging the system back to the desired state either all the time or on a regular schedule. Agentless means there is no persistent third-party management agent on the endpoint; a control node connects remotely using SSH, WinRM, secure web APIs, NETCONF, or RESTCONF.

The usual exam shortcut is: agent-based tools often align with server configuration management, while agentless tools align well with network automation. That is directionally correct, but not absolute. Now, here’s the catch: agent-based doesn’t always mean pure pull, and agentless doesn’t always mean someone manually pushing every change. Schedulers, webhooks, controllers, and event triggers can blur that line pretty quickly.

Operationally, you’ll notice the differences in a few very practical areas:

• Trust model: agent-based systems rely on agent registration, keys, or certificates. Agentless systems rely on SSH keys, API tokens, WinRM authentication, or similar remote access methods.
• Endpoint requirements: agent-based needs installable software. Agentless avoids a persistent agent, but may still require platform support such as Python on many Linux hosts, PowerShell and WinRM on Windows, or NETCONF and API enablement on network devices.
• Controller outage behavior: agent-based nodes may continue local enforcement for some tasks or resume when communication returns. Agentless systems usually depend on the control node or scheduler being available when execution is needed.
• Drift handling: agent-based platforms are often stronger at continuous remediation. Agentless workflows commonly do scheduled checks, triggered validation, or controlled remediation runs.

In Cisco environments, the big practical reason network teams lean agentless is pretty simple: most routers, switches, firewalls, and controllers just aren’t built to host general-purpose third-party agents. That makes remote automation over CLI or APIs the natural fit.

4. Agentless Does Not Mean CLI-Only

A common exam trap is assuming agentless automation means only SSH command pushing. Not true. In Cisco environments, agentless automation can use:

• SSH CLI for command execution and show-command validation
• NETCONF over SSH for structured configuration and retrieval
• RESTCONF over HTTPS for RESTful access to YANG-modeled data
• Controller northbound APIs such as Cisco Catalyst Center or SD-WAN Manager APIs

This matters because direct CLI automation is often less inherently idempotent than model-driven automation. A raw command like ntp server 10.10.10.10 may work, but structured modules and APIs are usually better at comparing intended state to actual state and avoiding duplicate or misordered commands.

5. Tool Summaries

Chef is traditionally a primarily agent-based configuration-management platform. Chef Infra Client runs on the node itself, pulls policy, and then converges the system toward the desired state. Core concepts include cookbooks, recipes, resources, attributes, and run lists. Chef is powerful in server and cloud environments, but less common for direct network device management because most network devices do not host that kind of agent. ENCOR takeaway: think agent-based, desired state, server and cloud orientation, Ruby DSL.

Puppet is also traditionally primarily agent-based and strongly associated with declarative configuration management. A Puppet agent authenticates to Puppet Server, gets its compiled catalog, and applies that locally on the node. The main Puppet terms you’ll hear a lot are manifests, classes, modules, Facter facts, Hiera data, and certificate-based trust relationships. Puppet’s well known for keeping server fleets on baseline and for cleaning up drift when systems wander away from the standard. For ENCOR, think agent-based, declarative, compliance-friendly, and strong on drift control. Also remember that Puppet has adjacent agentless task tooling such as Bolt, but its classic model is agent-based.

Ansible is primarily agentless. A control node executes playbooks written in YAML and connects to targets using SSH, WinRM, APIs, network_cli, httpapi, or netconf. For many Linux modules, Python is needed on the managed host, but that is not a persistent Ansible agent. For network devices, a lot of modules run from the control node and don’t require Python on the device itself. The key Ansible concepts are inventory, groups, variables, roles, collections, facts, privilege escalation, check mode, and diff mode. ENCOR takeaway: think agentless, push-oriented, network-friendly, broad API integration.

SaltStack is the hybrid option. In master/minion mode, minions maintain communication with the master and support very fast remote execution and event-driven workflows. Salt also includes Salt SSH for agentless operation. Important concepts include states, grains, pillars, top files, runners, beacons, reactors, and the event bus. For ENCOR, think hybrid, event-driven, flexible, and useful in mixed estates.

6. A More Cisco-Realistic Ansible Example

In network automation, you’ll usually put the connection details right into the inventory so the tool knows how to reach each device. A Cisco IOS XE inventory example might look something like this:

[iosxe]
dist-sw1 ansible_host=192.0.2.10
dist-sw2 ansible_host=192.0.2.11 [iosxe:vars]
ansible_connection=ansible.netcommon.network_cli
ansible_network_os=cisco.ios.ios
ansible_user=automation
ansible_password=!vault...
ansible_become=yes
ansible_become_method=enable

- name: Configure NTP servers on IOS XE hosts: iosxe gather_facts: no tasks: - name: Ensure NTP server is present cisco.ios.ios_ntp_global: config: servers: - server: 10.10.10.10 state: merged - name: Verify NTP configuration cisco.ios.ios_command: commands: - show run | section ^ntp

This is more precise than a generic “Cisco devices” example. It assumes the correct collection is installed, uses servers rather than peers, and reflects common network inventory settings. For API-based workflows, Ansible may instead use httpapi or netconf.

7. Comparison Matrix

Key takeaway: for Cisco routers and switches, Ansible is usually the most natural comparison answer because the devices are commonly managed remotely rather than through installed agents. Salt is the hybrid exception. Puppet and Chef are more naturally associated with server baselines and continuous compliance.

8. Cisco-Specific Automation Context

ENCOR is not just about tool names. It is also about recognizing automation methods in Cisco environments:

• Direct device automation: a tool connects straight to IOS XE, NX-OS, IOS XR, ASA, or another platform using CLI or APIs.
• Controller-based automation: automation interacts with a controller such as Catalyst Center, which then manages devices through its own workflows and abstractions.
• Model-driven programmability: using YANG-modeled interfaces through NETCONF or RESTCONF instead of depending only on CLI parsing.

Don’t assume every Cisco platform is equally mature when it comes to APIs, because that varies quite a bit by platform and software release. Support varies by platform, software release, and module or provider quality. That version caveat matters in real operations and is fair game conceptually on the exam.

9. Security, Drift, and Scale

Security differs by model. Agentless automation needs strong credential and secret handling: SSH key management, API token scoping, vaulting, RBAC, AAA integration, and audit logging. Agent-based systems still need secure bootstrap and certificate lifecycle ownership; they do not eliminate secret-management problems, they shift them.

Drift remediation also differs. Agent-based tools are typically better at continuous local enforcement. Agentless network automation often relies on scheduled checks, post-change validation, or event-driven remediation. On network devices, full declarative reconciliation can be harder than on servers because command order, feature dependencies, and disruptive changes matter.

At scale, success depends on more than tool choice. You must consider controller sizing, control-node CPU and memory, API rate limits, device session limits, batching, serial execution, and rollback boundaries. A safe pattern for network changes is canary first, then small batches, then broader rollout.

10. Troubleshooting by Failure Domain

A compact troubleshooting model works well for ENCOR and real life:

• Inventory/targeting: wrong host group, stale source of truth, bad variables.
• Reachability: SSH, HTTPS, WinRM, or NETCONF not reachable.
• Authentication: bad password, expired token, SSH key mismatch, certificate trust issue.
• Authorization: TACACS+ command authorization, missing enable privileges, RBAC denial.
• Transport/protocol: NETCONF not enabled, API version mismatch, prompt parsing failure.
• Module/platform support: unsupported OS version, wrong collection or provider, schema mismatch.
• Validation/rollback: change applied but state not as intended, backup missing, post-check failed.

Typical examples: Ansible to Cisco may fail because the account lacks enable privileges; NETCONF may fail because netconf-yang is not enabled; Puppet may fail at certificate signing; Salt minion registration may fail because keys were not accepted on the master.

11. Practical Use-Case Mapping: How I’d Think About It

12. ENCOR Exam Tips and Traps

What ENCOR is likely to test is comparison-level understanding:

• Which tools are primarily agent-based, agentless, or hybrid
• Why network devices usually align with agentless approaches
• How NETCONF, RESTCONF, and YANG all work together in model-driven programmability
• The difference between configuration management and orchestration, which people mix up all the time

Common traps:

• Trap: agentless means only SSH CLI. Correction: it can also mean APIs, NETCONF, and RESTCONF.
• Trap: desired state always means agent-based. Correction: agentless tools can support desired-state workflows depending on modules and APIs.
• Trap: controller-based automation equals Ansible. Correction: controllers and orchestration tools are different, though they can integrate.
• Trap: NETCONF and RESTCONF are interchangeable. Correction: both may use YANG data models, but NETCONF typically uses SSH and RESTCONF uses HTTP or HTTPS.

Memory aids:

• Ansible: agentless, push-oriented, network-friendly.
• Puppet: agent-based, declarative, compliance-focused.
• Chef: agent-based, Ruby DSL, server and cloud oriented.
• SaltStack: hybrid, fast, event-driven.

13. Conclusion

The cleanest way to answer ENCOR questions here is to start with the endpoint and the operational goal. If the endpoint is a Cisco router or switch that can’t host a third-party agent, agentless automation is usually the right conceptual answer. If the goal is continuous local enforcement on Linux or Windows servers, agent-based configuration management is often the stronger fit. If the environment is mixed and event-driven, SaltStack becomes a very plausible hybrid answer.

So the final exam takeaway is simple: match the automation model to endpoint capability, trust model, and compliance requirement. That is both the right ENCOR answer and the right real-world design habit.