Exercise 3: Why Repeated kubectl apply Is Safe — Possible Solution
====================================================================

The property that makes this safe: IDEMPOTENCY.

Per the chapter, `kubectl apply` is idempotent -- "running it twice
with no changes produces the same result as running it once, with no
errors or duplicate resources." This is a direct consequence of HOW
apply actually works: rather than blindly executing a "create this
resource" command every single time it's run (which would fail or
create a duplicate the second time), apply works by comparing the
manifest's DESIRED STATE against the last-applied configuration and
the resource's CURRENT actual state, and only takes action if there's
an actual DIFFERENCE between them.

Walking through what happens on a second, unchanged run:

1. `kubectl apply -f manifest.yaml` is run a first time. The resource
   doesn't exist yet, so apply CREATES it, matching the manifest's
   desired state.

2. The same command is run again, with the file completely unchanged.
   Apply compares the manifest's desired state against what's
   currently actually running -- and finds they already match exactly.

3. Because there's no difference to reconcile, apply takes NO
   ACTION at all -- it doesn't recreate the resource, doesn't error
   out complaining the resource already exists, and doesn't produce
   any duplicate. It simply confirms the current state already matches
   what was requested.

This is exactly the same underlying diff-and-reconcile mechanism
described for Kubernetes' own reconciliation loop in Chapter 2 --
apply itself behaves according to the same "observe, compare, act (or
don't, if nothing to reconcile)" pattern that controllers use
continuously in the background.

Why this matters practically: it means a YAML manifest can be
re-applied confidently at any time -- as a way to confirm a resource
still matches its intended configuration, to recreate something if it
was accidentally deleted, or simply as a routine step in an automated
deployment pipeline -- without needing to first check whether the
resource already exists or worry about breaking anything by running
the same command more than once.

WHY THIS WORKS AS AN ANSWER
------------------------------
This names the specific property (idempotency) the chapter attributes
to apply, and then walks through the actual mechanism -- comparing
desired vs. actual state and only acting on a real difference -- that
produces that property, rather than simply asserting "it's safe"
without explaining the underlying diff-based behavior that makes it
true.