Configuration management is one of the simpler topics in DevOps, and the clearest way to understand it is to watch the problem it grew out of.

Imagine you are a system administrator, back before DevOps existed as a role, and your company runs its own on-premises data centre with a hundred servers — say fifty on one Linux distribution, twenty-five on CentOS, and twenty-five on Ubuntu. Managing your own servers means constantly doing three kinds of work: applying upgrades (when CentOS moves from version 9 to 10, you have to move with it), applying security patches (just as you update your phone the moment a vulnerability is found), and making default installations (perhaps every server should come with Git or a database already installed, to save the developers time).

Now do those three things across a hundred servers with a team of five. Each person gets twenty servers, and they have to log into every one — over SSH for Linux, or a remote protocol for Windows — and run the commands by hand. The old way to cope was to write scripts: a shell script for Linux, a PowerShell script for Windows. But this was fragile for two reasons. First, you had to write in several languages. Second, and worse, the commands differed by distribution — a script written for Ubuntu might not work on CentOS or Alpine — so a script could work on some servers and silently fail on others.

Then the cloud made it far worse. With the move to the cloud and to microservices, the number of servers went up roughly tenfold while each server got smaller. Where you once had a thousand large servers, you now had ten thousand small ones. The by-hand-and-scripts approach that was already painful became impossible. That pressure created the need for a proper solution — a concept, configuration management, and the tools that implement it. Configuration management aims to solve exactly one thing: managing the configuration of many servers at once, which every organisation of any size now needs.

Configuration management has several well-known tools. Knowing which one to learn — and why — is the practical question.

The popular tools are Puppet, Chef, Ansible, and Salt. Historically, engineers started with Puppet or Chef, which were the first to implement configuration management six or seven years ago. Ansible gained real popularity around 2016 and 2017, and after Red Hat acquired it (around 2018–2019) it has been constantly developed — which is why you often hear it called Red Hat Ansible. Today it is the go-to tool for configuration management.

So the practical advice is simple: if you are confused about where to start, start with Ansible. There is roughly a 90% chance that the organisation you join will be using it. That is not to say nobody uses Puppet, Chef, or Salt — some do — but the majority use Ansible, and it is always better to learn the tool that is most widely used, because that is what gets you into a job. Once you know Ansible well, and if you still have time, you can look at the others.

"When you have Puppet and Ansible, why did you choose Ansible?" is one of the most common interview questions. The answer is four architectural differences, and you should be able to give all four.

1. Push versus pull. Puppet uses a pull model; Ansible uses a push model. With Ansible, you write your playbook in one place — your laptop or a control node — and push the configuration out to all your servers by running the playbook. You do not wait for each server to pull the config down for itself.
2. Agentless versus master–slave. This is the big one. Puppet follows a master–slave (master–agent) architecture: you install an agent on every server and register it with the master using tokens and certificates before anything works. Ansible is agentless — there is nothing to install on the servers you manage. You simply list their IP addresses (or DNS names) in an inventory file and set up passwordless SSH authentication, and Ansible can configure them. This matters enormously in a dynamic environment where servers are created and torn down constantly: to manage a new server you just add its IP to the inventory. Ansible can even do this automatically with dynamic inventory, where it auto-detects new servers (for example, any new EC2 instance in a given region) and manages them without you editing the file at all.
3. Good support for both Windows and Linux. Ansible has strong modules for both operating systems, and especially after Red Hat's involvement its Windows support improved a lot — which is often trickier with Puppet or Chef. Its Linux support is excellent.
4. Simple YAML instead of a custom language. Puppet makes you learn its own Puppet language. Ansible playbooks are written in plain YAML — a format engineers already know from Kubernetes and elsewhere — so there is no new language to learn.

You need two servers: a control node (where Ansible runs) and at least one target to configure. Create two Ubuntu EC2 instances, and on the control node install Ansible with the package manager — it is the easiest route, and it adds Ansible to your path automatically:

bashsudo apt update
sudo apt install -y ansible        # on Mac: brew install ansible · on Windows: choco install ansible
ansible --version                  # verify it installed (under the hood it uses Python + pip)

The one prerequisite Ansible has is passwordless SSH: the control node must be able to connect to the targets without a password. Set that up by generating a key pair on the control node and copying its public key into the target's authorized keys. The private key never leaves the control node and is never shared:

bash# on the CONTROL node
ssh-keygen                         # creates ~/.ssh/id_rsa (private) and id_rsa.pub (public)
cat ~/.ssh/id_rsa.pub              # copy this public key

# on the TARGET server, paste the control node's public key into:
~/.ssh/authorized_keys             # (ssh-copy-id <target-ip> does this in one step, when it has permission)

# back on the control node — now this connects with no password:
ssh <target-private-ip>

Once ssh <target> connects without asking for a password, the prerequisite is met — for that server and any others you add the public key to. Use the private IP when the servers are in the same VPC. In one line: passwordless SSH is just the control node's public key sitting in the target's authorized_keys.

The inventory file is where you list the servers Ansible manages. Ansible's default is /etc/ansible/hosts, but it is more convenient to keep your own file next to your playbooks and point Ansible at it. You can also group servers with bracket headers and target a group by name:

text# inventory
172.31.6.228

[webservers]
172.31.62.100

[dbservers]
172.31.62.200

You do not always need a playbook. For a one-off task — "create a file on a hundred servers" — an ad-hoc command is simpler, exactly as you would run a single shell command rather than write a whole script. The form is ansible -i <inventory> <hosts> -m <module> -a "<args>", where -m is the module and -a is its arguments:

bashansible -i inventory all -m shell -a "touch devops-class"   # run on every host in the inventory
ansible -i inventory webservers -m shell -a "nproc"         # run only on the webservers group
ansible -i inventory all -m copy -a "src=./x dest=/tmp/x"   # modules other than shell, e.g. copy

A yellow line means something changed and all is well; a red line means an error. Which module to use, and its arguments, you look up in the Ansible module documentation — there are thousands of modules and nobody memorises them all. The rule of thumb, and a common interview question, is: use an ad-hoc command for one or two tasks, and write a playbook when you have many.

A playbook is just an Ansible file — the equivalent of a shell script — written in YAML, used when you want to run several tasks. Here is one that installs and starts nginx:

yaml---
- name: install and start nginx
  hosts: all                       # every server in the inventory
  become: true                     # run as root, like sudo (package installs need it)
  tasks:
    - name: install nginx
      apt:                         # the apt module — equivalent to "shell: apt install nginx", but sturdier
        name: nginx
        state: present             # present = installed
    - name: start nginx
      service:                     # the service module
        name: nginx
        state: started

Run it with ansible-playbook (the ansible command runs ad-hoc commands; ansible-playbook runs playbook files):

bashansible-playbook -i inventory first-playbook.yaml
# the first task is always "Gathering Facts" — Ansible checks the auth and collects info about the target
ansible-playbook -i inventory first-playbook.yaml -vvv   # add -v / -vvv for verbose debug output

Every playbook begins with a Gathering Facts step, where Ansible confirms it can authenticate and collects details about the target, before running your tasks. Two habits worth forming: prefer a purpose-built module (apt, service) over a raw shell command, because the module is more robust if the underlying command changes; and use -vvv when you want to see, step by step, exactly what Ansible is doing on the target — how it establishes the SSH connection, what it gathers, and the result of each task.

A two-task playbook fits in one file. A real one does not — and that is what roles are for.

Consider a realistic task: configure a Kubernetes cluster with Ansible, setting one server up as the master and two as workers. (In practice you would create the servers with Terraform — the right tool for provisioning infrastructure — and then configure them with Ansible.) A playbook like that has fifty or sixty tasks, plus variables, certificates, and secrets. Put all of that in one playbook.yaml and it becomes impossible to read. The answer is an Ansible role: an efficient, structured way to write a complex playbook. You create one with ansible-galaxy:

bashansible-galaxy role init kubernetes    # scaffolds a folder of standard directories

That scaffolds a tidy folder structure. Instead of one giant file, each concern lives in its own directory, and a small parent playbook simply names the hosts and points to the role:

• tasks/ — the actual steps (what used to be the tasks: block in your single playbook).
• handlers/ — actions triggered by a change, and a place to handle problems (for example, if nginx fails to start, notify someone or roll the change back).
• templates/ — Jinja2 templates for config files that need values filled in.
• files/ — static files to copy to the targets, such as an index.html or a certificate.
• vars/ and defaults/ — variables, where defaults/ holds the lowest-precedence values that can be overridden.
• meta/ — metadata and licensing, used when you share the role via Ansible Galaxy; and tests/ plus a README.

The pattern to remember for interviews: you write simple things directly in a playbook, and when a playbook grows complex — many tasks, variables, certificates, secrets — you turn it into a role so it stays structured and readable, and can be shared through Ansible Galaxy.