Exercise 1: Imperative vs. Declarative, and Which to Use for Something Reusable — Possible Solution
====================================================================

The difference:

IMPERATIVE commands (like `kubectl run` or `kubectl create
deployment`) tell kubectl what action to take RIGHT NOW -- create this
specific thing, immediately, based on flags and arguments typed at the
command line. Per the chapter, this is "fast for quick testing," but
it "leaves no reusable record of what was done" -- there's no file
anywhere describing what was created; the only record is whatever was
actually typed into the terminal at that moment.

DECLARATIVE work means writing a YAML manifest that describes the
DESIRED STATE of a resource, then running `kubectl apply -f
file.yaml`, letting Kubernetes' own reconciliation loop (Chapter 2)
figure out what changes are actually needed to reach that state.

Which is more appropriate for something meant to be kept and reused,
and why:

DECLARATIVE YAML is the appropriate choice. Per the chapter, "real,
reusable, version-controllable work... should be declarative YAML."
The specific reasons this matters for something meant to be KEPT:

1. The YAML file itself IS a durable, reusable record -- it can be
   read later to see exactly what was configured, unlike an imperative
   command that leaves no artifact behind once the terminal history is
   gone.

2. It can be put under VERSION CONTROL (per the chapter's own
   `git1`-`git3` cross-reference) -- tracked, reviewed, and diffed over
   time the same way application code is.

3. Per the chapter's own idempotency point, the SAME file can be
   safely re-applied later -- to recreate the resource if it's ever
   deleted, to reproduce it in a different cluster/namespace, or to
   confirm it still matches what's actually running -- none of which
   an imperative, one-off command supports as cleanly.

Imperative commands remain genuinely useful for quick, throwaway
exploration or learning -- but anything meant to persist and be relied
upon should exist as a YAML file, not just a command someone happened
to type once.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly applies the chapter's own explicit guidance
("declarative YAML" for reusable work) and explains the SPECIFIC
practical reasons why -- durability as a record, version control
compatibility, and safe re-application -- rather than just restating
the chapter's recommendation without justifying it.