Where the platform's responsibility ends
A cloud provider, a managed database, or a software-as-a-service vendor typically secures the infrastructure, the physical hosts, the network layer, and the software they operate directly. What they generally do not secure is how the customer configures access on top of that infrastructure: which accounts have which permissions, how broadly a storage bucket is exposed, whether a default credential was ever rotated. That configuration is the customer's responsibility, even though it runs on the vendor's infrastructure.
A large share of publicized cloud breaches trace back not to a failure in the underlying platform but to a customer-side misconfiguration — access left broader than intended, a resource made public by default and never restricted. The platform performed exactly as designed; the gap was in how it was configured.
The line has to be understood explicitly, not assumed
Because the responsibility split isn't always obvious from the outside, and varies between platforms and even between services from the same vendor, treating it as understood without checking the specific documentation for each service is a common and costly assumption. What a team assumes the platform handles for them and what the platform actually documents as the customer's job are not reliably the same thing, and the gap between those two only shows up during an incident.