Exercise 2: Why a Customizable SSH Port Belongs in defaults/main.yml — Possible Solution
====================================================================

Explanation:

The chapter's own precedence table is explicit about the intended use
of each file: defaults/main.yml sits at the LOWEST precedence
specifically because it's "meant to be overridden by whoever uses the
role," while vars/main.yml sits higher and is meant for values that
stay "closer to fixed... not meant for casual overriding." A
customizable SSH port is exactly the kind of value different users of
this role would legitimately want to set differently -- one team
might run SSH on the standard port 22, another might deliberately run
it on a non-standard port as part of their own security posture --
and the whole POINT of exposing this as a role variable is to let
each user of the role make that choice for themselves without editing
the role's own internal files.

If this value were placed in vars/main.yml instead, its high
precedence would make it genuinely difficult for someone using the
role to override it cleanly -- per ansible1-5's own precedence order,
vars/main.yml sits above ordinary inventory-level group_vars/host_vars,
so a user's own attempt to set a different port via their inventory
would actually lose to the role's own vars/main.yml value, defeating
the purpose of making it configurable at all. Putting it in
defaults/main.yml instead guarantees it sits at the bottom of the
precedence stack, so any inventory-level or playbook-level value a
user supplies naturally wins over the role's own built-in default,
exactly the customization behavior a "customizable SSH port" is
supposed to have.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly applies the chapter's own precedence table and its
stated intent for each file, then explains concretely what would go
wrong (the value becoming effectively un-overridable) if the variable
were placed in vars/main.yml instead.