Configuration management tools like Puppet and Chef are transforming how network engineers manage device configurations at scale. For the CCNA 200-301 exam, objective 6.5 expects you to understand the basic concepts and differences between these tools, even though you won't need to write full manifests or recipes. In real networks, automating repetitive tasks with Puppet or Chef reduces human error and speeds up deployments, making this knowledge essential for modern network engineering.
Jump to a section
Imagine you manage a chain of 100 hotels, and you need to renovate the kitchen in every one. You could send a team to each hotel with a blueprint and let them install cabinets, counters, and appliances manually. But every team might interpret the blueprint slightly differently—some might paint the walls eggshell instead of white, or install a different model of refrigerator. That's like configuring network devices by hand: inconsistent and error-prone. Instead, you create a detailed specification document that lists every item and its exact specifications: paint color code, refrigerator model number, cabinet dimensions. You then hire a central contractor who reads that spec and sends the same instructions to each hotel's local crew. The local crew simply follows the instructions exactly, without making decisions. This is how Puppet and Chef work: you define a desired state (the spec), and the tool ensures every device matches that state. Puppet uses a master-agent model where the master holds the spec and agents pull it periodically. Chef uses a similar model but with a different architecture—cookbooks and recipes are pushed to nodes. Both ensure consistency, auditability, and scalability, just like your hotel renovation project.
What Are Puppet and Chef?
Puppet and Chef are configuration management tools originally designed for servers but now widely used for network automation. They allow you to define the desired configuration of network devices (such as IOS version, interface settings, VLANs, ACLs) in code, and then enforce that configuration across many devices automatically. This approach is part of the Infrastructure as Code (IaC) movement, where network configurations are treated like software—versioned, tested, and deployed systematically.
How They Work: The Pull Model
Both Puppet and Chef typically operate on a pull model. A central server (Puppet master or Chef server) holds the desired configuration. Each managed device runs an agent (Puppet agent or Chef client) that periodically connects to the server, downloads its configuration instructions, and applies them locally. This ensures devices converge to the desired state without manual intervention. - Puppet uses a declarative language: you define the "what" (e.g., "ensure interface GigabitEthernet0/1 has IP address 10.1.1.1"), not the "how". The agent figures out the steps. - Chef uses a procedural language (Ruby-based DSL): you write recipes that describe the steps to achieve the desired state. Chef is more imperative, giving you finer control over the order of operations.
Puppet Architecture
Puppet has a master-agent architecture:
- Puppet master: A server that stores the configuration code (called manifests) in modules. It compiles a catalog for each node.
- Puppet agent: Runs on the managed device. It sends facts (system information like OS, hostname) to the master and requests a catalog. The agent then applies the catalog to the device.
- Facts: Key-value pairs about the device (e.g., operatingsystem => 'IOS', ipaddress => '192.168.1.1'). Agents send facts to the master.
- Catalog: A compiled document that tells the agent exactly what resources to manage and their desired state.
- Resources: The basic units of configuration, like file, service, package, or for network devices, cisco_interface, cisco_vlan, etc.
- Modules: Collections of manifests and other files organized by function (e.g., a cisco module for Cisco-specific resources).
Chef Architecture
Chef also uses a client-server model: - Chef server: Stores cookbooks (collections of recipes), node data, and policies. - Chef client (node): Runs on the managed device. It authenticates with the server, downloads its run list (list of recipes to apply), and executes them. - Cookbooks: The fundamental unit of configuration. A cookbook contains recipes, attributes, templates, and files. - Recipes: Written in Ruby DSL, recipes describe the steps to configure a device. For example, a recipe might include commands to set hostname, configure NTP, and apply ACLs. - Attributes: Details about the node (similar to Puppet facts) that can be used in recipes. - Ohai: A tool that collects node attributes (like OS, network interfaces) and sends them to the Chef server.
Interaction with Network Devices
Cisco devices can be managed by Puppet and Chef through various methods:
- Puppet: Cisco provides a cisco module that uses puppet device to manage IOS devices via SSH or NX-API. The device runs a proxy agent that translates Puppet resources into IOS commands.
- Chef: Cisco also offers ciscopuppet cookbook that works with the puppet device module, or you can use the cisco_ios cookbook that leverages SSH or RESTCONF. Chef client can be installed on the device itself (if it supports it, like IOS-XE) or run remotely via a proxy.
Key Differences at a Glance
Language: Puppet uses its own declarative DSL; Chef uses Ruby DSL (more procedural).
Architecture: Puppet uses a master-agent model with a compile master; Chef uses a server-client model with a Chef server.
Desired state vs. steps: Puppet focuses on the desired state; Chef focuses on the steps to achieve it.
Resource model: Puppet has a built-in resource abstraction layer; Chef requires explicit resource definitions.
Community modules: Both have extensive community modules, but Puppet's Forge and Chef's Supermarket are the repositories.
Verification Commands
On the Puppet master, you can check node status:
puppet cert list --all
puppet statusOn a managed device (if running Puppet agent), you can run:
puppet agent --testFor Chef, you can use:
chef-client --local-mode # runs locally without serverBut for CCNA, you won't need to memorize these commands. Focus on understanding the concepts.
Exam Relevance
For CCNA 200-301, you need to know:
The basic purpose of configuration management tools (Puppet, Chef, Ansible, SaltStack).
The difference between push (Ansible) and pull (Puppet, Chef) models.
That Puppet uses a declarative DSL and Chef uses a Ruby-based DSL.
That both use a master-agent (or server-client) architecture for pull-based automation.
The terms: manifest (Puppet), recipe (Chef), cookbook (Chef), module (Puppet), fact (Puppet), attribute (Chef).
You will NOT be asked to write Puppet code or Chef recipes. You will see conceptual questions about how these tools work and their benefits.
Define desired state in code
In Puppet, you write manifests (files with .pp extension) that declare the desired state of resources. For example, a manifest might specify that interface GigabitEthernet0/1 should have IP address 10.1.1.1/24 and be in VLAN 10. The manifest uses Puppet's declarative language, so you don't specify the order of commands—you just say what the final result should be. In Chef, you write recipes in Ruby DSL that define the steps to achieve the desired configuration. For example, a recipe might include a `cisco_interface` resource with properties like `ip_address` and `vlan`. The key is that both tools allow you to version-control this code, test it, and apply it consistently.
Store code on central server
Puppet stores manifests in modules on the Puppet master server. Each module is a directory containing manifests, templates, and files. The master compiles a catalog for each node based on the node's facts and the code in the modules. Chef stores cookbooks on the Chef server. A cookbook contains recipes, attributes, and other files. The Chef server also stores node data and policies. The central server acts as the single source of truth for configuration. In both cases, the server is typically a Linux server running the Puppet or Chef software. For CCNA, you just need to know that the server holds the configuration code.
Agent connects and pulls configuration
The Puppet agent or Chef client runs on the managed network device (or a proxy). On a regular interval (default every 30 minutes for Puppet, every 30 minutes for Chef), the agent connects to the server over HTTPS. It sends its identity and facts (Puppet) or attributes (Chef). The server then compiles a catalog or run list for that specific node. The agent downloads this catalog/run list and applies it locally. This pull model ensures that even if devices are behind firewalls or have dynamic IPs, they can still get their configuration. The agent only pulls when it is ready, so the server doesn't need to initiate connections.
Apply configuration locally
Once the agent receives the catalog (Puppet) or run list (Chef), it begins applying the configuration. For Puppet, the agent uses providers that translate resource declarations into actual IOS commands. For example, a `cisco_interface` resource might be translated into `interface GigabitEthernet0/1`, `ip address 10.1.1.1 255.255.255.0`, `switchport access vlan 10`. The agent applies these commands via SSH or API (like NX-API or RESTCONF). Chef does similarly, executing the steps in the recipe. The agent reports back to the server with the results (success, failure, changes made). This feedback loop allows the server to track compliance.
Report and enforce compliance
After applying the configuration, the agent sends a report to the server. Puppet stores reports on the master, and Chef stores them on the Chef server. These reports include details like what resources were changed, what errors occurred, and whether the node is now compliant. The server can then generate dashboards or alerts. If a device drifts from the desired state (e.g., someone manually changes an interface IP), the agent will correct it on the next pull. This is called "convergence" — the device automatically returns to the desired state. This is a key benefit of configuration management: it enforces consistency and prevents configuration drift.
Manage updates and scaling
As your network grows, you can scale Puppet or Chef by adding more masters (Puppet) or using Chef's tiered architecture. Both tools support environments (e.g., development, testing, production) so you can test changes before rolling them out. For CCNA, you should understand that these tools are designed for large-scale automation. For example, if you need to add a new VLAN to 100 switches, you update the code on the server once, and all switches will pull the change within their next interval. This is far more efficient than logging into each switch individually.
In a typical enterprise with hundreds of Cisco switches and routers, manually configuring each device is error-prone and time-consuming. Consider a scenario where a company needs to deploy a new security policy: all access ports should have port security enabled, and all trunk ports should have allowed VLANs restricted. Without automation, an engineer would have to SSH into every switch, enter configuration mode, and apply the changes. With Puppet or Chef, the engineer writes a manifest or recipe that describes the desired state for all switches: "For every interface that is an access port, ensure port security is enabled with maximum MAC addresses of 5. For every trunk port, ensure allowed VLANs are only VLAN 10, 20, and 30." This code is stored in a version-controlled repository, tested in a lab environment, and then promoted to production. The Puppet master or Chef server distributes this configuration to all switches. Within 30 minutes, every switch converges to the new state. If a switch is offline, it will get the update when it comes back.
Another use case is compliance auditing. Many enterprises must comply with standards like PCI-DSS or HIPAA. Configuration management tools provide a centralized view of device configurations and can generate reports showing which devices are non-compliant. For example, if a regulation requires that all unused ports be shut down, an engineer can create a Puppet manifest that checks every interface and shuts down those not connected to a device. The tool will automatically correct any violations on each pull.
Performance considerations: Puppet and Chef agents run on the device or a proxy. On low-end switches, running an agent may consume CPU and memory. Some organizations use a proxy (like a Linux server) that manages multiple devices via SSH, reducing the load on the network devices. Also, the pull interval can be adjusted; for critical changes, you can trigger an immediate pull (e.g., via a webhook or manual command). If misconfigured, a bad manifest or recipe could break device connectivity. For example, if you accidentally set the management interface IP to 0.0.0.0, the agent might lose connectivity and be unable to correct itself. Best practices include testing in a lab, using canary deployments (apply to a small set of devices first), and having out-of-band management access as a safety net.
The CCNA 200-301 exam objective 6.5 states: "Explain the benefits of network automation and the tools used for it, including Puppet, Chef, Ansible, and SaltStack." This is a conceptual topic—you will not be asked to write code or configure these tools. Instead, expect multiple-choice questions that test your understanding of:
The pull model used by Puppet and Chef (vs. push model of Ansible).
The declarative nature of Puppet vs. procedural nature of Chef.
Key terms: manifest (Puppet), recipe/cookbook (Chef), facts (Puppet), attributes (Chef).
That both tools use a master-agent (or server-client) architecture.
That they are used for configuration management and enforcing desired state.
Common wrong answers: 1. "Puppet uses a push model" — This is wrong because Puppet uses a pull model. Ansible uses push. Candidates often confuse them. 2. "Chef uses declarative language" — Chef uses a procedural Ruby DSL, not declarative. Puppet is declarative. 3. "Puppet and Chef are used for monitoring" — They are for configuration management, not monitoring. Tools like Nagios or SNMP are for monitoring. 4. "Puppet uses recipes and Chef uses manifests" — It's the opposite: Puppet uses manifests, Chef uses recipes.
Exam traps:
If the question asks about "desired state" vs "steps to achieve state", Puppet is desired state, Chef is steps.
If the question asks about "agent pulls from server", that's Puppet/Chef; if it asks about "server pushes to agent", that's Ansible.
Terms like "cookbook" belong to Chef, "module" to Puppet.
Elimination strategy: For scenario questions asking which tool to use for a given situation, identify whether a push or pull model is needed. If devices are behind NAT or have dynamic IPs, pull is better (Puppet/Chef). If you need immediate execution and have direct connectivity, push (Ansible) may be simpler. Also, if the question emphasizes "declarative" or "desired state", lean toward Puppet; if it mentions "Ruby" or "procedural", lean toward Chef.
Puppet and Chef use a pull model: agents connect to a central server to download configuration.
Puppet uses a declarative language (manifests) to define desired state; Chef uses a procedural Ruby DSL (recipes).
Key Puppet terms: manifest, module, fact, catalog, resource.
Key Chef terms: recipe, cookbook, attribute, node, run list.
Both tools enforce desired state and correct configuration drift automatically.
Puppet and Chef are for configuration management, not monitoring or orchestration (though they can integrate with other tools).
CCNA tests conceptual understanding: differences between push/pull, declarative/procedural, and key terminology.
These come up on the exam all the time. Here's how to tell them apart.
Puppet
Declarative DSL (desired state)
Uses manifests and modules
Master-agent pull model
Facts (system information) sent to master
Catalog compiled by master
Chef
Procedural Ruby DSL (steps)
Uses recipes and cookbooks
Server-client pull model
Attributes collected by Ohai
Run list executed by client
Mistake
Puppet uses a push model like Ansible.
Correct
Puppet uses a pull model: agents periodically connect to the Puppet master to fetch their catalog and apply it.
Candidates often group all automation tools together and forget that Puppet and Chef pull while Ansible pushes.
Mistake
Chef uses a declarative language.
Correct
Chef uses a procedural Ruby DSL. You define the steps to achieve the desired state, not just the end state.
The term 'declarative' is commonly associated with configuration management, but Chef is actually procedural.
Mistake
Puppet and Chef are primarily used for network monitoring.
Correct
They are configuration management tools for automating device setup and enforcing desired state, not for monitoring performance or faults.
Students sometimes confuse automation with monitoring because both are part of network management.
Mistake
Puppet uses recipes and Chef uses manifests.
Correct
Puppet uses manifests (files with .pp extension) and Chef uses recipes (part of cookbooks).
The terminology is easily swapped because both tools have similar concepts with different names.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
In a push model (used by Ansible), the automation server initiates an SSH connection to each device and sends configuration commands. In a pull model (used by Puppet and Chef), an agent on each device periodically connects to the server to retrieve its desired configuration and applies it locally. Push is simpler for small networks with direct connectivity; pull is better for large or dynamic networks where devices may not be reachable from the server.
No. The CCNA 200-301 exam only tests conceptual understanding of automation tools, not hands-on coding. You should know the purpose, architecture, and key terminology of Puppet and Chef, but you will not be asked to write or interpret code.
Facts (Puppet) and attributes (Chef) are key-value pairs that describe the state of a managed node, such as OS, hostname, IP address, and interfaces. They are collected by the agent and sent to the server to help compile a node-specific configuration.
Yes. Both tools are platform-agnostic and can manage any device that supports SSH or an API. For network devices, there are community and vendor modules/cookbooks for many vendors including Cisco, Juniper, Arista, and others.
Puppet agent runs periodically (default every 30 minutes). It sends facts to the master, receives a catalog, and applies it. If a resource is not in the desired state, the agent makes the necessary changes. This process repeats on each run, so even if someone manually changes a configuration, Puppet will correct it on the next run.
The Puppet master stores manifests and modules, compiles catalogs for nodes, and serves them to agents. The Chef server stores cookbooks, node data, and policies, and provides run lists to clients. Both act as the central repository of desired configurations.
Yes, you can run Puppet in apply mode (puppet apply) or Chef in local mode (chef-client --local-mode) to apply a manifest or recipe directly on a device without a server. This is useful for testing or managing a small number of devices.
You've just covered Puppet and Chef for Network Automation — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?