Exercise 2: Why certbot Uses command + creates — Possible Solution
====================================================================

Explanation:

Per ansible1-4's own material, command and shell tasks are NOT
idempotent by default -- they simply run whatever command they're
given, every single time the playbook executes, with no built-in
concept of "has this already been done." Requesting a Let's Encrypt
certificate via certbot is a real, meaningful action with genuine
side effects and real-world constraints (Let's Encrypt itself rate-
-limits how often a certificate can be reissued for the same domain)
-- running "certbot --apache -d ... --non-interactive" unconditionally
on every single playbook run would attempt to re-request or reissue
the certificate every time the capstone's harden.yml playbook runs,
even on a host that already has a perfectly valid certificate sitting
in place. That's exactly the wasteful, potentially rate-limit-triggering,
non-idempotent behavior ansible1-4 warned about.

The creates: "/etc/letsencrypt/live/{{ domain_name }}/fullchain.pem"
argument is ansible1-4's own documented fix for exactly this
situation: it tells Ansible to check whether that specific file
already exists BEFORE running the command at all, and to skip the
command entirely if it does. Since certbot itself creates
fullchain.pem as part of successfully obtaining a certificate, its
presence is a reliable signal that the certificate already exists --
so on any run after the first successful one, this task is skipped
outright, reported as ok (not changed), and certbot is never invoked
again unnecessarily. This turns an inherently non-idempotent shell
command into a task that behaves correctly under ansible1-6's own
"run twice, expect changed=0" test.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the real-world consequence of NOT using creates here
(repeated, potentially rate-limit-triggering certificate requests on
every run), then explains exactly how the creates argument prevents
that by checking for the certificate file's existence first, directly
tying the fix back to ansible1-4's own documented pattern.