Exercise 1: "The Cloud Provider's Service Is Broken" — What's Missing Before Filing — Possible Solution
====================================================================

Questions that need answers first, per this chapter's "What Makes a
Good Support Case" material:

1. WHICH SPECIFIC RESOURCE is affected -- the exact resource ID/ARN,
   not "my service" generically. Which specific instance, bucket,
   database, or other resource is actually exhibiting the problem?

2. WHAT IS THE EXACT ERROR MESSAGE being seen -- the precise wording
   and error code, not a paraphrase like "it's broken."

3. WHEN DID IT START, PRECISELY, and did anything change around that
   time -- a specific timeline, not "recently."

4. WHAT HAS ALREADY BEEN CHECKED OR RULED OUT -- has this been
   confirmed to NOT be an internal/customer-side issue (per this
   chapter's own "when to actually engage provider support" gut
   check)? Has the account-specific health dashboard already been
   checked to see if this is a known, already-tracked issue?

5. IS THIS ACTUALLY A PROVIDER-SIDE ISSUE AT ALL, per the chapter's
   own distinction between provider-support's job and what should stay
   an internal (Chapter 6) matter -- e.g., has an IAM misconfiguration
   or application bug already been ruled out as the real cause?

Why a vague case gets a slower response:

Per the chapter's own warn-box, "vague cases get vague, slow
responses... the provider's own support engineer has to do the exact
same scoping work Chapter 4 covers before they can even start actually
helping." If none of the above questions have answers yet, opening a
case immediately just shifts that scoping work onto the provider's
support engineer, who then has to go back and forth asking for exactly
this information before any real diagnosis can even begin --
adding an entire round-trip of delay (and typically several) compared
to gathering it up front before the case is even filed.

WHY THIS WORKS AS AN ANSWER
------------------------------
This lists the exact pieces of information the chapter names as
required for "a good support case," and explains the delay mechanism
directly -- the provider engineer needing to independently re-derive
the same scoping information a well-prepared case would have already
included, adding real, avoidable round-trip time to case resolution.