Exercise 2: An Identical changed=2 on a Second Run — Possible Solution
====================================================================

-- What this tells you --
--
-- Per the chapter's own compare-table, a second run reporting
-- changed>0 -- especially an amount IDENTICAL to the first run --
-- is a genuine idempotency bug, not just noise or bad luck. A
-- properly idempotent playbook run against a host that hasn't been
-- touched since the previous run should report changed=0 the second
-- time, since every task's own desired state should already be
-- satisfied. Two tasks reporting changed again, with the same count
-- as before, strongly suggests those specific two tasks are doing
-- SOMETHING unconditionally on every single run, rather than
-- checking current state first the way an idempotent module does --
-- exactly the command/shell trap from ansible1-4 the chapter directly
-- names as the most common cause.

-- The specific next step to investigate --
--
-- Identify which two tasks are the ones reporting changed (the
-- per-task output above the PLAY RECAP names them directly), and
-- check whether either of them uses command or shell without a
-- creates/removes argument or a changed_when: clause -- the exact
-- non-idempotent pattern ansible1-4 described and this chapter's own
-- "concrete idempotency bug" example walked through. If either task
-- is a command/shell task lacking that safeguard, that's almost
-- certainly the root cause, and the fix is the same one ansible1-4
-- applied: add changed_when (and/or creates/removes) so the task
-- only reports changed when a real change genuinely occurred.

WHY THIS WORKS AS AN ANSWER
------------------------------
This interprets the symptom using the chapter's own stated
interpretation table, then names a specific, actionable next
step (checking the flagged tasks for the exact command/shell pattern
ansible1-4 already diagnosed) rather than a vague "investigate
further."