The cloud shared responsibility model

WHAT THIS TESTS This checks whether you understand that moving to the cloud does not outsource all security, and that the division of duties changes with the service model.

A GOOD ANSWER COVERS The shared responsibility model splits ownership of the stack between the provider and you. The provider is responsible for security of the cloud: physical datacenters, host hardware, the hypervisor, the underlying network, and, in a PaaS, the operating system and the managed language runtime including their patching. You are responsible for security in the cloud: your application code and its dependencies, your data and its encryption choices, identity and access management, network and firewall rules you configure, and correct service configuration. With PaaS like Elastic Beanstalk or App Engine the provider handles more than with raw IaaS, where you would also own OS patching, but in every model your code, your data, and your access policies remain yours.

COMMON WRONG ANSWERS Thinking the provider secures everything once you deploy. Blaming the provider for a breach caused by a public storage bucket, weak IAM, or a vulnerable dependency. Believing the line is fixed across IaaS, PaaS, and SaaS rather than shifting.

LIKELY FOLLOW-UPS How does the boundary differ between IaaS, PaaS, and SaaS? Who patches the OS in PaaS versus IaaS? Who is responsible for encrypting data at rest and managing keys? Give an example of a customer-caused breach.

ONE CONCRETE EXAMPLE You deploy a Django app to App Engine. Google patches the host OS, the Python runtime, and the load balancer, so a kernel vulnerability is their problem to fix. But if you commit an API key to your repo, leave a Cloud Storage bucket public, or grant an overly broad IAM role, that is squarely your responsibility, and Google's secure platform does not protect you from your own misconfiguration.