Exercise 2: A Public Storage Bucket — Whose Responsibility? — Possible Solution ==================================================================== This falls on the CUSTOMER's side of the shared responsibility line, not the provider's. Reasoning, using the chapter's own breakdown: The provider's responsibility ("of" the cloud) covers the physical data center security, the underlying hardware, the virtualization layer, and the global network infrastructure -- none of which were involved in this incident. The storage service itself was almost certainly functioning exactly as designed; nothing about the provider's own infrastructure failed or was breached. The customer's responsibility ("in" the cloud) specifically includes the customer's OWN DATA and their OWN CONFIGURATION -- and a storage bucket's access permissions (public vs. private) are a configuration setting the customer controls directly. Leaving a bucket publicly readable is a customer-side configuration mistake, not a provider security failure -- the provider gave the customer the tool to set permissions correctly; the customer simply set them incorrectly (or failed to set them at all). This is a direct, concrete example of the chapter's own point about "outage" or "breach" tickets often turning out to sit entirely on the customer's side of the responsibility line -- exactly the kind of scenario this chapter's tip-box describes as one of the fastest things to check first when triaging an incident, rather than assuming the provider is at fault. WHY THIS WORKS AS AN ANSWER ------------------------------ The key distinguishing test from the chapter is: did the failure happen in something the PROVIDER manages (hardware, hypervisor, network) or something the CUSTOMER manages (data, IAM, configuration)? A bucket's permission setting is unambiguously a configuration choice made by the customer, which is why this scenario -- despite being a real, serious data exposure -- is a customer-side responsibility-model failure rather than a provider security failure.