Exercise 2: Why Ansible Doesn't Run Continuously Like Kubernetes — Possible Solution
====================================================================

Explanation:

This comes down to a genuine architectural difference the chapter
names directly, not a missing feature Ansible simply hasn't gotten
around to building. Kubernetes' own reconciliation loop is designed
for managing a LIVE, continuously running system -- pods can crash,
get rescheduled, or drift from their desired replica count at any
moment, and something needs to be constantly watching and correcting
that in real time, with no human involved, for the cluster to stay
healthy. That's the specific problem Kubernetes exists to solve, and
its own architecture (a controller running permanently, always
comparing desired vs. actual state) is built around solving it
continuously.

Ansible is solving a different problem: applying a defined
CONFIGURATION to a set of hosts, typically as a deliberate, reviewed
action -- either run on demand by a person, or on a schedule via CI.
Ansible's own idempotent design means it's SAFE to run repeatedly
without unwanted side effects, but "safe to run repeatedly" is a
different guarantee than "runs constantly and catches drift the
instant it happens." Building Ansible to run continuously in the
background would mean turning it into something closer to an
agent-based tool with a persistent daemon on every managed host --
which is exactly the architecture ansible1-1 already contrasted
Ansible against (Puppet/Chef). Ansible's whole agentless, push-based
design is a deliberate tradeoff: no persistent process anywhere, at
the cost of not catching drift until the next time someone explicitly
runs a playbook.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the difference by connecting it to what each tool was
actually built to manage (a live running cluster vs. a
config-management task run on demand), and ties the "why not run
continuously" question back to ansible1-1's own agentless-vs-agent-based
architecture tradeoff rather than treating it as an arbitrary design
choice.