Exercise 2: Why a New Server Is Immediately Manageable by Ansible, Not by Puppet/Chef — Possible Solution
====================================================================

Explanation:

Ansible is agentless -- it has no persistent process of its own that
needs to be installed and running on a managed host. As the chapter
describes, all Ansible actually needs to manage a new server is an
SSH connection and a Python interpreter on the other end -- both of
which are typically already present on a freshly provisioned Linux
server by default. The moment SSH access exists, Ansible can connect,
push whatever code a given task requires, run it, and disconnect,
with nothing extra needing to be pre-installed on that server first.

Puppet and Chef both work the opposite way -- they depend on a
persistent AGENT running on every managed node, a daemon that checks
in with a central server on its own schedule. That agent doesn't
exist on a server by default; it has to be deliberately installed and
registered with the central Puppet/Chef server as a separate setup
step BEFORE that server can be managed at all. Until that agent
installation and registration happens, a freshly provisioned server
is simply invisible to Puppet or Chef, no matter how reachable it is
over the network -- there's no agent there yet to report in or
receive instructions.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the difference by tracing exactly what each tool
architecturally depends on to manage a host -- Ansible's own SSH+Python
minimum vs. Puppet/Chef's own persistent agent requirement -- rather
than just restating "Ansible is agentless."