The Configuration Management Problem
Imagine you need to configure 200 servers identically — install the same packages, create the same users, deploy the same config files. Doing this by hand over SSH is error-prone and doesn't scale. Shell scripts help, but they're fragile: run them twice and they might fail because a user already exists or a directory was already created. What you need is a tool that understands desired state, not just sequential commands.
Ansible is that tool. It lets you describe what your infrastructure should look like, and it figures out how to make reality match that description — safely, repeatably, and without installing anything on the servers you're managing.
The "Agentless" Architecture
Before Ansible, configuration management tools like Puppet and Chef required you to install special software agents on every server you wanted to manage. These agents would "phone home" to a central server, receive instructions, and apply them. This created a bootstrapping problem: how do you configure a server before the agent is installed? It also introduced a persistent maintenance burden — the agents themselves needed to be kept updated and secured.
Ansible eliminated this entirely. It runs on a single control node (your laptop, a CI/CD runner, or a dedicated automation server) and connects to managed nodes using standard SSH (for Linux/macOS) or WinRM (for Windows). No agent software is installed on the managed nodes. If you can SSH into a server, Ansible can manage it — immediately, with zero pre-configuration.
The control node needs Python and the ansible package. The managed nodes need only Python (version 2.7+ or 3.5+) and an SSH server, both of which are present on virtually every Linux distribution by default.
Declarative vs. Procedural Thinking
There are two ways to automate a task. The procedural approach describes the steps: "Run apt-get install nginx, then check if the service is running, then start it if it isn't." The declarative approach describes the goal: "Nginx should be installed and running."
Ansible is declarative. You describe the desired end state, and Ansible determines what actions — if any — are needed to reach it. This property is called idempotency: running the same Ansible playbook ten times produces the same result as running it once. If the server is already in the desired state, Ansible does nothing and reports ok. If a change is needed, it makes the change and reports changed.
This is the fundamental shift that makes Ansible safe to run repeatedly — in CI/CD pipelines, on a schedule, or after an incident — without fear of breaking things that are already correct.
Interviewers frequently ask: "What does idempotency mean in the context of Ansible, and why does it matter?" The strong answer connects idempotency to operational safety: "Idempotency means running a playbook multiple times produces the same outcome as running it once. This matters because it makes automation safe to re-run after partial failures, in CI/CD pipelines, and during incident recovery — you never have to worry about a task breaking something that was already correctly configured."