Walk me through the cloud shared responsibility model and give an example of a security failure that falls on the customer, not the provider.

technical-conceptual · Mid level · cloud-devops-security

What the interviewer is really asking

Assess whether the candidate understands where the provider/customer security boundary sits, how it shifts across IaaS/PaaS/SaaS, and can name a concrete customer-side failure rather than assuming the cloud is secure by default.

What to say

• State the boundary: the provider secures the cloud (physical data centers, hardware, hypervisor, managed-service internals) — 'security of the cloud' — and the customer secures what they put in it: their data, IAM/access configuration, OS and patching (on IaaS), network rules, and application code — 'security in the cloud'.
• Show that the line moves by service model: on IaaS you own the OS, patching, and most config; on PaaS the provider takes the OS/runtime and you own app code, data, and access; on SaaS the provider runs almost everything but you still own identity, access controls, data classification, and configuration — IAM and data are always the customer's.
• Give a concrete customer-side failure and the lesson: a publicly-exposed S3 bucket or an over-permissioned IAM role is the customer's fault, not AWS's — defaults aren't the most secure (object storage and IAM must be explicitly locked down), so you enforce least privilege, block public access, and use posture tooling/guardrails to catch drift, since misconfiguration is the dominant cause of cloud breaches.

What to avoid

• Assuming the provider secures your data or configuration by default ('it's in AWS, so it's secure').
• Saying the model is fixed regardless of service type — the boundary genuinely shifts between IaaS, PaaS, and SaaS.
• Blaming the provider for a customer misconfiguration like a public bucket or an admin-level role on a read-only workload.

Example answers

Strong: On an audit I found an S3 bucket holding customer exports with public-read enabled and no default encryption — squarely a customer failure, since AWS secures the storage service but bucket policy and encryption are ours. I enabled account-level Block Public Access, turned on default SSE-KMS, and added an SCP so no one could re-open public access org-wide, then used Config rules to alert on any bucket drift. AWS's compliance certifications never covered our misconfiguration.

Weak: The cloud provider handles security, so as long as we're on AWS our data is protected.