Exercise 3: Three "Looks Broken, Actually Working as Designed" Examples — Possible Solution
====================================================================

Three examples, drawn from the chapter's own closing table:

1. CHAPTER 1 -- A leaked, publicly-readable storage bucket looking
   like "the cloud is insecure." In reality, per the shared
   responsibility model, this was a customer-side configuration
   mistake -- the provider's infrastructure was never at fault; the
   bucket's permission setting was simply left in a state the customer
   controlled and configured incorrectly.

2. CHAPTER 5/7 -- "I can't reach my database directly from outside."
   In reality, this is very often the deliberate private-subnet
   pattern working exactly as intended -- databases are commonly
   placed where they are NOT directly reachable from the internet on
   purpose, specifically to reduce the attack surface, and the correct
   response is a bastion host or VPN, not treating the unreachability
   itself as a bug to "fix" by exposing the database.

3. CHAPTER 3 -- "I'm still being billed even though my VM is
   stopped." In reality, stopping a VM only halts COMPUTE charges;
   its attached storage volume continues to exist and continues
   billing independently, exactly as the billing model is designed to
   work -- not an error in the invoice.

(A fourth valid example from Chapter 11: a confusing IaC "plan" output
showing unexpected changes, which is very often just the tool
reconciling drift introduced by an earlier manual console fix, not a
bug in the tool itself.)

What they have in common:

In every case, the SYMPTOM (something inaccessible, something still
costing money, something showing unexpected output) looks identical to
a genuine failure from the outside -- but the actual explanation, in
every single case, is that the system is behaving exactly according to
an intentional design decision or a well-defined billing/replication
rule, not malfunctioning. The common thread is that assuming
"something is broken" without first asking "could this be intentional
behavior I don't yet understand" leads to the wrong diagnosis every
time -- which is exactly the instinct the chapter's own tip-box
recommends carrying forward: ask what it would mean for the behavior
to be intentional, before assuming it's a bug.

WHY THIS WORKS AS AN ANSWER
------------------------------
Each example is drawn directly from the chapter's own summary table,
and the closing "what they have in common" paragraph restates the
chapter's own explicitly named throughline -- that recognizing
intentional-but-surprising behavior, rather than defaulting to "this
must be broken," is the single most transferable skill the whole
course has been building toward.