Exercise 3: Two Different http_port Values, Not Necessarily a Bug — Possible Solution
====================================================================

-- Why this isn't necessarily a bug --
--
-- The chapter's own warn-box is explicit that a host can belong to
-- multiple levels of variable definition at once (a group's own
-- group_vars file, and that same host's own more specific host_vars
-- file), and that having the same variable name set at more than one
-- level is genuinely common, not a mistake by itself. It's entirely
-- plausible that web1.example.com is DELIBERATELY meant to run on a
-- different port than the rest of the webservers group -- maybe it's
-- running behind a different proxy, or it's a special-cased host for
-- some other legitimate reason -- and host_vars/web1.example.com.yml
-- is exactly the mechanism for overriding one specific host's own
-- value without changing the setting for the whole group. Ansible's
-- own variable precedence rules (covered fully in ansible1-5) exist
-- specifically to resolve this kind of overlap predictably, rather
-- than treating it as an error condition.

-- Where to look to find out which value actually applies --
--
-- The chapter's own tip-box names the exact tool for this:
-- ansible-inventory --list -i inventory. Running that command shows
-- exactly how Ansible parsed the whole inventory, including every
-- host's own FINAL, merged variable values after all the applicable
-- group_vars/host_vars files and precedence rules have been applied
-- -- rather than needing to manually reason through every file by
-- hand, this command reveals directly whether web1.example.com ends
-- up with http_port 80 or 8080 once everything is resolved.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains why overlapping variable definitions are a normal,
expected pattern rather than assuming it's a mistake, gives a
plausible real-world reason one host might legitimately need an
override, and names the chapter's own specific debugging tool
(ansible-inventory --list) rather than a vague "check the docs"
answer.