Exercise 2: Confirming Whether Storage Volumes Are Genuinely Orphaned — Possible Solution
====================================================================

Steps to confirm before recommending removal, combining this chapter's
own investigation material with its explicit warning against
unconfirmed deletion:

1. CHECK TAGS FIRST (per this chapter and `cloud1-9`'s own material).
   A properly tagged volume may directly indicate its purpose (e.g.
   tagged "backup-retention" or belonging to a specific, still-active
   project) -- this alone can resolve the question without further
   digging. The ABSENCE of tags is itself informative too, per the
   chapter's own point that forgotten resources are "often
   discoverable specifically because they lack proper tagging."

2. CHECK CREATION DATE AND ANY ASSOCIATED SNAPSHOT/BACKUP SCHEDULE.
   A volume that's part of a deliberate, ongoing backup strategy would
   typically show a pattern consistent with regular use (recent
   snapshots taken from it, or it being the TARGET of a scheduled
   backup job) rather than simply sitting untouched since its creation
   date.

3. CROSS-REFERENCE AGAINST RECENTLY TERMINATED INSTANCES (per this
   chapter's "Investigating Orphaned Storage" section). If the volume
   corresponds to an instance that was intentionally terminated as
   part of a completed teardown, that's consistent with genuine
   orphaning. If it doesn't correspond to any terminated instance at
   all, it may have always been intentionally standalone (a deliberate
   backup volume never meant to be attached to a running instance in
   the first place) rather than "orphaned."

4. ASK THE CUSTOMER DIRECTLY. Per the chapter's own warn-box --
   "always confirm with the customer before recommending removal" --
   the final, decisive step is confirming with the customer whether
   this specific volume is something they recognize as intentional
   (a deliberate backup strategy) or something they agree looks
   unused and safe to remove. Internal investigation narrows down the
   LIKELY answer, but the chapter is explicit that deletion should
   never be recommended purely from internal investigation alone,
   given how consequential and hard-to-reverse an incorrect deletion
   would be.

WHY THIS WORKS AS AN ANSWER
------------------------------
This combines the chapter's own investigative techniques (tags,
creation date, cross-referencing terminated instances) with its
explicit warning that deletion recommendations require customer
confirmation -- treating "looks orphaned based on internal
investigation" and "confirmed safe to delete" as two DIFFERENT
conclusions, exactly as the chapter's warn-box insists they should be
treated.