What's the best way to configure a hundred identical switches without spending three days typing the same commands over and over? Data centre automation solves this problem by using software to manage network devices, servers, and applications in a standardised, repeatable way — essential for the 350-601 exam because it tests your ability to describe how tools like Ansible, Puppet, and Chef reduce human error and speed up operations in modern data centres.
Jump to a section
A simple way to picture Data Center Automation Fundamentals
Have you ever watched a professional kitchen during a dinner rush and wondered how they manage to serve dozens of different dishes, all perfectly timed, without chaos?
In a busy restaurant, the head chef doesn't run back and forth shouting orders at each cook individually. Instead, they use a structured system: the ticket printer. Every order comes in as a printed ticket, which lists exactly what each station needs to prepare. The grill cook sees 'steak, medium-rare', the sauté cook sees 'pasta with marinara', and the pastry chef sees 'chocolate mousse'. Everyone knows exactly what to do, when to do it, and how to coordinate with each other. If the restaurant has a new menu item, the head chef updates the ticket template once, and all future orders automatically reflect the change. No one has to memorise a new recipe or guess the steps.
This is precisely how data centre automation works. The 'ticket printer' is an automation tool like Ansible, Puppet, or Chef. The 'cooks' are the servers, switches, and storage devices in a data centre. The 'recipes' are playbooks or manifests — sets of instructions written in a standardised language. Instead of a human logging into each device one by one to type commands (like a head chef shouting at each cook individually), the automation tool sends a single set of instructions to all the right devices simultaneously. It ensures every server gets the exact same configuration, every time, without human error or forgetfulness. And when a business needs to change something — like adding a security rule to 500 servers — the IT team updates the 'recipe' once and pushes it out. The kitchen runs smoothly, no shouting required.
Data centre automation is the practice of using software to handle repetitive, manual IT tasks — like configuring a network switch, deploying a server operating system, or updating security rules — without a human typing commands into each device one at a time. Think of it as the difference between handwriting a hundred letters by hand versus printing them from a template: the result is identical, the process is faster, and the chance of a typo is nearly zero.
Before automation, IT professionals relied on 'snowflake servers' — every machine was configured manually, often with slight differences that caused mysterious bugs. If a server failed, rebuilding it exactly as it was took hours or days. Automation changes this by treating infrastructure as code: the desired state of every device is written in text files that can be version-controlled (like saving drafts of a document) and reapplied instantly.
The three main tools mentioned in the 350-601 exam objectives are Ansible, Puppet, and Chef. Each solves the same core problem — consistent configuration across many devices — but they approach it differently.
Ansible uses a 'push' model. The administrator installs Ansible on a control node (a dedicated computer that orchestrates everything). On the control node, they write playbooks, which are YAML files (a human-readable data format) listing the desired configuration steps. For example, a playbook might say: 'ensure the web server package is installed, ensure the firewall port 443 is open, ensure the service is running'. When executed, Ansible pushes these instructions over SSH (a secure network protocol) to the target devices — which can be switches, routers, servers, or virtual machines. No permanent agent software is needed on the target; the target only needs SSH access. This makes Ansible lightweight and easy to start with. The 350-601 exam expects you to know that Ansible is agentless, push-based, and that playbooks are written in YAML.
Puppet uses a 'pull' model. A central Puppet server holds the desired configuration, called 'manifests', written in Puppet's own declarative language. Each target device runs a Puppet agent, a small program that regularly checks in with the server — typically every 30 minutes. The agent says, 'What state should I be in?' The server responds with a catalog of resources and their desired state, and the agent configures itself to match. The exam wants you to recall that Puppet is agent-based, pull-based, and uses its own Domain Specific Language (DSL).
Chef also uses a pull model. A Chef server stores recipes (configuration instructions) and cookbooks (collections of recipes). Each target machine runs a Chef client (similar to an agent), which pulls the recipes from the server and applies them. Chef uses a 'Ruby DSL' — meaning the recipes are written in a Ruby-based language. The exam distinguishes Chef as also having a strong 'infrastructure as code' philosophy, where the entire system's configuration is treated as reusable, testable code.
Regardless of which tool is used, the fundamental benefits are the same:
Consistency: Every device configured by the same playbook or manifest ends up identical. No drift between servers that were set up on different days by different people.
Speed: Tasks that took a human hours — like updating firewall rules across 200 switches — can be done in seconds.
Version control: Configuration files can be stored in Git (a version control system). If a change breaks something, you can revert to the previous version immediately.
Auditability: You can review the version history of a configuration to see exactly who changed what and when — crucial for compliance with standards like PCI-DSS (Payment Card Industry Data Security Standard).
The exam will not ask you to write playbooks or manifests, but you must be able to compare the tools based on whether they are agentless (Ansible) or agent-based (Puppet, Chef), push or pull, and their configuration language. You also need to know that automation is a key part of DevOps (a culture combining development and operations for faster, more reliable software delivery) and that it directly supports the '5 pillars of the Cisco Data Center Architecture': automation, programmability, security, visibility, and compliance.
In summary, automation is not a 'nice to have' — it is essential for modern data centres with hundreds or thousands of devices. Manually configuring each one would introduce errors, take too long, and be impossible to scale. Automation tools like Ansible, Puppet, and Chef provide the structure to manage that complexity reliably.
Define the Desired State
Write a configuration file (playbook, manifest, or recipe) that specifies exactly how each device should be configured. For example, 'install Nginx version 1.24, start the service, open port 80'. This file becomes the single source of truth.
Set Up an Inventory
Create a list of target devices (IP addresses, hostnames, credentials) that the automation tool will manage. In Ansible, this is typically a simple text file called 'hosts'. Organising devices into groups (e.g., 'webservers', 'switches') simplifies targeting.
Establish Connectivity
Ensure the automation tool can reach each device. For Ansible, this means SSH access and a valid user account. For Puppet/Chef, the agent must be installed and registered with the central server. Without connectivity, automation cannot execute.
Execute the Automation Run
Run the configuration file against the inventory. Ansible executes tasks in the order written, pushing changes. Puppet/Chef agents check in with their server and pull the manifest or recipe. The tool compares the current state to the desired state and makes only the necessary changes.
Verify and Audit
Review logs and reports generated by the tool to confirm all devices reached the desired state. Ansible outputs a summary per device (OK, changed, failed). Puppet and Chef produce detailed reports. Store these logs for compliance audits.
Iterate and Version Control
When a change is needed, update the configuration file, commit it to a version control system (like Git), and re-run the automation. This creates a historical trail of all changes and allows instant rollback to any prior version.
You work as a junior network engineer for a mid-sized e-commerce company. The data centre contains 150 servers, 20 switches, and 10 firewalls. Every month, the security team issues a new vulnerability scan report, and you need to apply changes — for example, disabling insecure TLS (Transport Layer Security) versions on every device. Doing this manually would mean logging into each switch and firewall via SSH, typing 'no tls-version 1.0', verifying the change, and repeating 30 times. It would take the entire day and leave room for typos.
Instead, your senior colleague shows you how the team uses Ansible. Here is what happens step by step:
First, your team writes a playbook called 'disable_tls10.yml' on the Ansible control node. The playbook lists the switches and firewalls in an inventory file (a simple text file listing device IP addresses and login credentials). The playbook contains a task: 'ensure that TLS 1.0 is disabled on all interfaces'. The playbook is written in YAML, so it looks almost like a checklist.
Second, the team runs the playbook with the command 'ansible-playbook disable_tls10.yml'. Ansible opens SSH connections to each device listed in the inventory, reads the current configuration, compares it to the desired state, and issues the necessary CLI (command line interface) commands to make the change. On each device, the change is logged in the local syslog (system logging).
Third, the playbook finishes in about 2 minutes. The team now has 30 devices all consistently updated. They store the playbook in a Git repository. Next month, when the security team asks for a similar change, the team simply edits the existing playbook — changing the command from 'disable TLS 1.0' to 'disable TLS 1.1' — and runs it again.
In another scenario, suppose Puppet is used for server configuration. A new web server needs to be deployed. The operations team creates a Puppet manifest that defines the desired state:
The 'httpd' package must be installed.
The 'httpd' service must be running.
The firewall must permit TCP ports 80 and 443.
The file '/etc/httpd/conf/httpd.conf' must contain specific content from a template.
When the server boots for the first time, the Puppet agent contacts the Puppet server and pulls this manifest. The agent then installs the package, starts the service, opens the ports, and writes the configuration file — all without any human intervention. If someone later manually stops the 'httpd' service, the Puppet agent, during its next check-in (typically 30 minutes later), detects the drift and restarts the service. This 'self-healing' capability is a major advantage of pull-based systems like Puppet and Chef.
In practice, many organisations use a mix: Ansible for network devices (because switches often cannot run an agent), and Puppet or Chef for servers (where an agent is easy to install and the self-healing feature is valuable). The 350-601 exam expects you to recognise these use-case distinctions.
The 350-601 exam devotes a specific section (5.1) to automation tools, and the questions are highly predictable. You will not be asked to write playbooks or debug errors. Instead, the exam tests your ability to compare and contrast Ansible, Puppet, and Chef across three dimensions: agent requirement (agentless vs agent-based), communication model (push vs pull), and configuration language (YAML, Puppet DSL, Ruby DSL).
Here are the exact patterns you will encounter:
Multiple-choice questions: 'Which automation tool uses a push model and is agentless?' The answer is Ansible. The trap answer is Puppet or Chef, which both use agents and pull models.
True/false questions: 'Ansible requires an agent to be installed on each managed device.' This is false. The exam loves testing this point.
Scenario-based questions: 'A network team needs to configure 100 switches simultaneously without installing software on the switches. Which tool is most suitable?' Again, Ansible, because switches cannot run Puppet or Chef agents easily.
Comparison questions: 'Which statement correctly describes Chef?' Correct answer: 'Chef uses a pull model and requires a client installed on each target node.' The traps may state 'Chef uses a push model' or 'Chef requires no client'.
Key traps to watch for:
'Idempotency' — this is a critical concept, though not unique to any one tool. An idempotent operation means running the same playbook multiple times produces the same result. Beginners often confuse idempotency with 'push vs pull'. Memorise the definition: if the configuration is already correct, running the playbook again makes no changes.
'Cisco NX-OS and Ansible' — the exam may ask which modules Ansible uses to interface with Cisco NX-OS switches. The answer is 'cisco.nxos' modules (part of Ansible's collection of network modules). They may present a question like 'Which Ansible module connects to a Cisco Nexus switch?' with options like 'ios_config', 'nxos_config', 'junos_config'. Correct: 'nxos_config'.
'YAML vs DSL' — the exam expects you to know that Ansible uses YAML, which is a data-serialisation language (human-readable structured data), whereas Puppet and Chef use domain-specific languages (DSL) — custom programming languages designed for configuration tasks. A common trap is saying 'Ansible uses Ruby' or 'Puppet uses YAML' — both are false.
'Idempotency in Puppet and Chef' — the exam may ask: 'What is the difference between the declarative model of Puppet and Chef versus Ansible?' Correct answer: Puppet and Chef are natively declarative — you state the desired end state, and the tool figures out the steps. Ansible is also declarative (you write what you want, not how to get there) but executes as a series of ordered tasks. The nuance is subtle but tested.
List of key definitions to memorise for the exam:
Agentless: No permanent software on the target device; the automation tool communicates via SSH or API (Application Programming Interface) over the network.
Agent-based: A small program (agent) runs on each target device, usually pulling configurations from a central server.
Push model: The automation tool initiates all actions from a central control node without the target requesting configuration.
Pull model: The target device's agent periodically checks a central server and applies the configuration it receives.
Playbook: Ansible's configuration file, written in YAML.
Manifest: Puppet's configuration file, written in Puppet DSL.
Recipe / Cookbook: Chef's configuration units, written in Ruby DSL.
Idempotency: Running the same configuration multiple times results in the same outcome; no unintended changes occur.
Infrastructure as Code (IaC): Managing infrastructure (servers, networks, storage) using version-controlled configuration files, treating them like application code.
The exam will also link automation to broader Cisco data centre concepts like Application Centric Infrastructure (ACI), where policies are applied via an API, and Cisco Intersight, a cloud-based management platform that integrates with automation tools. However, within section 5.1, the focus remains on comparing Ansible, Puppet, and Chef.
Ansible uses a push model and is agentless, communicating via SSH or API — perfect for network devices that cannot run custom agents.
Puppet and Chef use a pull model where an agent on each device requests configuration from a central server on a regular schedule.
Ansible playbooks are written in YAML, Puppet manifests use Puppet DSL, and Chef recipes use Ruby DSL — they are not interchangeable.
Idempotency means applying the same configuration multiple times yields the same result without errors or duplication.
Infrastructure as Code (IaC) treats server and network configurations as version-controlled code, enabling rollbacks and audit trails.
Cisco NX-OS switches are managed via Ansible's 'nxos_config' module, not generic CLI modules like 'ios_config'.
These come up on the exam all the time. Here's how to tell them apart.
Ansible
Agentless: no software on managed devices
Push model: controller initiates all communication
Playbooks written in YAML
Puppet
Agent-based: requires Puppet agent on each device
Pull model: agents request configuration from master
Manifests written in Puppet DSL
Ansible
Declarative via YAML playbooks
Push-based communication model
No separate server required (can run from any machine)
Chef
Uses Ruby DSL for recipes and cookbooks
Pull-based: Chef client polls Chef server
Requires Chef server, Chef client, and workstations
Puppet
Uses Puppet DSL (declarative)
Resource abstraction: defines state of system resources
Puppet Server (Ruby) with PuppetDB
Chef
Uses Ruby DSL (procedural/declarative hybrid)
Node definitions are written as recipes
Chef Server (Erlang/Elixir) with Chef Infra Client
Push Model (Ansible)
Configuration changes are immediate when the playbook runs
No agent needed on the target device
Less network overhead (no periodic polling)
Pull Model (Puppet/Chef)
Changes occur on the agent's check-in schedule (e.g., every 30 minutes)
Self-healing: agent detects and corrects drift automatically
Scalable for large deployments without overwhelming the controller
Mistake
Ansible requires an agent on every managed device.
Correct
Ansible is agentless — it uses SSH or API calls to connect to devices, so no software needs to be installed on the targets.
People often assume all automation tools need agents because they've heard of Puppet and Chef agents first.
Mistake
Puppet and Chef are push-based tools.
Correct
Puppet and Chef use a pull model: the agent on each device requests configuration from the server on a schedule.
The term 'client-server' is familiar from web applications, where the client (browser) requests data — but people confuse 'request' with 'push'.
Mistake
All three tools use the same configuration language (YAML).
Correct
Only Ansible uses YAML. Puppet uses its own DSL, Chef uses a Ruby DSL. They are not interchangeable.
YAML is widely used in other contexts (e.g., Docker, Kubernetes), so beginners assume it's universal.
Mistake
Automation tools can configure any device without any special preparation.
Correct
Devices need either SSH access (for Ansible) or an installed agent (Puppet/Chef). Some devices like certain network switches may require API support or a specific Ansible version.
Marketing materials emphasise ease of use, but beginners overlook the prerequisite connectivity requirements.
Mistake
Automation means you never need to touch a device manually again.
Correct
Automation handles configuration, but initial setup (installing agents, enabling SSH) still requires manual steps. Also, troubleshooting outliers often requires manual intervention.
The promise of 'full automation' leads to unrealistic expectations; IT professionals still do hands-on work for debugging.
Mistake
Chef is the same as Puppet because both use agents and pull model.
Correct
Chef uses Ruby DSL for recipes, Puppet uses its own DSL. Chef's architecture also has a unique 'Chef Server' and 'Chef Client' relationship, while Puppet has a 'Puppet Master' and 'Puppet Agent'. They are different products.
Surface-level similarities (agent-based, pull model) cause people to think they are identical.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. The exam tests your ability to describe and compare the tools, not to write code. Focus on understanding agent vs agentless, push vs pull, and the configuration language each uses.
No. The 350-601 exam objective 5.1 explicitly covers Ansible, Puppet, and Chef. You must know the differences between all three, though Ansible is emphasised due to its popularity in Cisco environments.
If you run the same configuration file multiple times, the result is the same as running it once. It won't create duplicate configurations or cause errors — it just ensures the system matches the desired state.
Yes. Ansible has dedicated modules for Cisco devices, such as 'ios_config' for IOS devices and 'nxos_config' for NX-OS (Nexus) switches. These modules handle the CLI translation automatically.
Chef provides a more robust 'infrastructure as code' environment with a Ruby DSL, allowing complex logic (loops, conditionals) that can be harder to express in YAML. It also supports self-healing via its pull-based agent model.
The switch will not receive the configuration. Ansible will report an 'unreachable' error. After the switch reboots, you can run the playbook again; it will reapply the complete desired state, including any changes that were lost.
You've finished Data Center Automation Fundamentals. Continue through the 350-601 study guide to build a complete picture of the exam.
Done with this chapter?