Exercise 3: Intermittent Cloud API Timeouts Breaking Dynamic Inventory — Possible Solution
====================================================================

-- Why this is a genuinely new category of failure --
--
-- Per the chapter's own warn-box, a static inventory file is just a
-- plain file sitting on disk -- reading it has no dependency on any
-- external network service being reachable, authenticated correctly,
-- or responding within any particular time limit. A dynamic
-- inventory, by contrast, makes a REAL network call to a live cloud
-- API every single time it's used, which means it has inherited an
-- entirely new class of failure a static file structurally could
-- never have: the API being temporarily unreachable, rate-limiting
-- the request, or simply timing out under its own load. This isn't a
-- bug in the dynamic inventory plugin itself -- it's a direct,
-- unavoidable consequence of depending on a live external service
-- instead of a local file, exactly the tradeoff the chapter names
-- ("a real network dependency, not a free abstraction").

-- A mitigation worth considering --
--
-- One reasonable mitigation is enabling the dynamic inventory
-- plugin's own CACHING support (most dynamic inventory plugins,
-- including aws_ec2, support caching the query result for a
-- configurable duration). Rather than hitting the live API on every
-- single playbook run, the inventory would be refreshed only every
-- few minutes (or whatever interval is reasonable for how often the
-- underlying infrastructure actually changes), with cached results
-- used in between. This directly reduces how often the intermittent
-- timeout can actually occur, while still keeping the inventory
-- meaningfully more current than a fully static, hand-maintained file
-- would ever be -- a middle ground between "always live, always
-- vulnerable to API flakiness" and "never updated at all."

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains why the failure is structurally new (a real network
dependency vs. a local file) rather than treating it as an unrelated
bug, then proposes a concrete, named mitigation (caching) rather than
a vague "make it more reliable" suggestion.