Convert a provider boundary into owned, testable controls

Review status: rewritten after review; interview framing added, abstraction ladder and attribution reasoning expanded.

Why interviewers ask this

The shared responsibility model is the most common cloud security question at senior level, and it is rarely asked as trivia. The interviewer is testing whether you can do three things a diagram cannot:

1. State the split precisely for a named service, not "the cloud" in general.
2. Reason about a concrete failure — an exposed S3 bucket, a leaked key, an unpatched AMI — and say which side of the line it falls on and why.
3. Convert the boundary into owned controls with evidence, because "shared" that means nobody owns the last mile is how incidents happen.

A weak answer recites the marketing diagram: "provider secures the cloud, customer secures in the cloud," then stops. A strong answer names the service, names the layer, names the owner, and names the evidence. Expect follow-ups like: "Who patches the OS on RDS?", "If our S3 bucket goes public, is that AWS's incident or ours?", and "We're SOC 2 compliant because we run on a SOC 2-compliant provider — what's wrong with that sentence?" All three are answered below.

The core split: security OF the cloud vs. security IN the cloud

Providers secure of the cloud: physical facilities, hardware, hypervisors, foundational networking, and the managed internals of their services. Customers secure in the cloud: what they deploy, configure, authorize, and store — data, identities, application code, and service configuration.

That summary is useful but incomplete. The boundary changes by service, feature, deployment mode, region, contract, and integration. A diagram does not assign an engineer, implement a control, produce audit evidence, or accept residual risk. The rest of this guide is about turning the diagram into decisions.

The boundary moves with abstraction: IaaS, PaaS, SaaS

The more managed the service, the more layers pass to the provider — and the boundary moves line by line, not all at once:

• IaaS (e.g., EC2): the provider operates facilities, hardware, and hypervisor. You own the guest OS and its patching, applications, network rules (security groups), identities, and data. An unpatched guest OS on EC2 is your finding, not theirs.
• Managed platform (e.g., RDS): the provider also owns the host and OS patching, and often the database engine patching. You still own schema-level authorization, credentials, whether the instance is publicly reachable, backups and retention policy, and query safety. Patching shifted; data duties did not.
• SaaS: the provider runs most of the application stack. You own data governance, tenant configuration, users and their access, endpoints, and lawful use. On SaaS you own essentially only your data and who can reach it.

Hybrid, marketplace, container, serverless, and AI services do not fit a single row. Serverless still leaves you owning function code, IAM execution roles, and event permissions. Map the actual service, not the category.

What is always yours, whatever you buy

Three duties survive every abstraction level:

1. Data classification and handling. A provider's encryption capability does not classify your data or decide who may decrypt it. That is a governance decision you cannot delegate.
2. IAM. Who has access, least privilege, credential hygiene, and rotation are customer-side at every layer — including on fully managed SaaS, where "who is a tenant admin" is your control.
3. Configuration. Choosing the service and configuring its capabilities is yours. Provider availability zones do not make your application multi-zone; a provider certificate does not certify your workload.

Compliance is never inherited wholesale

Adopting a compliant provider does not make you compliant. The provider's SOC 2 or ISO 27001 report is scoped evidence about their layer, for a defined period and service. You inherit their controls for their layer and must still evidence your own: IAM reviews, configuration checks, secure code, logging, backups, recovery exercises. "We run on a compliant provider, therefore we are compliant" is the single most common weak answer interviewers bait for — the correct response is that certifications are scoped evidence at a point in time, not a guarantee of workload compliance.

Attribution reasoning: which side of the line is a failure on?

Given a concrete failure, name the side and the reason. Misconfiguration and identity failures are customer-side by definition — the provider gave you the control and you set it wrong:

• Publicly exposed storage bucket: customer-side. The provider operates the storage service; the public-access setting is a customer configuration decision (and on most platforms now blockable by an org-level preventive guardrail — a good thing to mention).
• Over-permissive IAM role: customer-side. Least privilege is authored by the customer.
• Leaked access key: customer-side. Credential hygiene, rotation, and scoping are customer duties; the provider's job is to give you the tools (short-lived credentials, scoped roles) to avoid long-lived keys at all.
• Unpatched guest OS on a VM: customer-side in IaaS. On a managed database the same patch would be provider-side — which is exactly why you must name the service before answering.
• Hypervisor escape or facility compromise: provider-side. Rare, but it is the category the provider actually owns.

The interview pattern: hear the failure, name the service, name the layer, name the owner. If you cannot name the owner, say what you would check in the service documentation — that honesty scores better than a confident wrong guess.

Build a control responsibility matrix

For each risk and control, name the provider obligation, customer obligation, shared dependency, internal owner, evidence, validation frequency, failure signal, incident handoff, contract/SLA reference, and accepted gap. Decompose vague rows such as "network shared" into DDoS infrastructure, service edge, tenant firewall, private connectivity, DNS, egress, application authorization, and monitoring. Avoid the word shared when it means nobody owns the last mile.

Validate provider duties through current service documentation, contracts, SLAs, compliance reports, audit artifacts, architecture limitations, and support processes. Determine which controls can be inherited, partially inherited, or must be implemented independently, and retain the mapping an auditor can reproduce. Track expirations and changes in reports, services, regions, and subcontractors.

Validate customer duties through configuration and operating evidence: organization policy, IAM review, data classification, encryption decisions, secure code, patching where applicable, logging, backups, recovery exercises, vulnerability management, and incident response. Prefer preventive guardrails and continuous checks over a spreadsheet assertion. Test boundary assumptions with failure scenarios: lost region, compromised tenant administrator, provider control-plane outage, corrupted backup, support escalation, service retirement.

Responsibility is not accountability

A provider may operate a control while you remain accountable to regulators, users, or your own customers for the outcome. Outsourcing implementation does not outsource risk ownership. Contracts should address data location and use, confidentiality, availability, deletion, portability, incident notification, evidence access, support, change, subcontractors, and exit — but contractual remedies do not restore data or serve traffic during an outage.

Reliability crosses the boundary too

The provider operates platform infrastructure and publishes service behavior and commitments; you select regions, redundancy, quotas, timeouts, retry and failover behavior, backup/restore, dependency isolation, and realistic recovery objectives. An SLA is usually a financial commitment with measurement rules and exclusions, not an architecture or recovery plan. Design for business objectives and test from the user path.

Incident response across the boundary

Define what telemetry you can collect, what the provider controls, how to open a security case, severity and authentication procedures, what evidence can be supplied, notification obligations, and alternate communications during tenant compromise. You contain your identities, configurations, code, and data; the provider investigates their service. Preserve timelines and do not wait for attribution before applying safe customer-side containment.

Third parties add more boundaries

Marketplace software, managed service partners, SaaS integrations, carriers, and identity providers may be neither the primary provider nor you. Map their access, control operation, evidence, incident duties, and exit separately. The cloud provider's assurance does not automatically extend to a vendor image or partner-operated application.

Shared fate and measuring it

Use shared fate as an operating posture: providers supply secure defaults, guardrails, blueprints, transparency, and expert support; customers must adopt and validate them. Automation can make the secure path easier, but it must not hide ownership. When a service changes, reassess shifted controls, new defaults, deprecated features, data flows, evidence, and recovery behavior before rollout.

Measure control ownership coverage, unassigned or ambiguous controls, inherited-control evidence freshness, configuration drift, overdue customer actions, tested provider/customer handoffs, SLA and recovery exercise results, incident escalation time, unresolved contract gaps, and recurrence caused by boundary misunderstanding. Success is not memorizing who patches the hypervisor. It is proving that every material risk has an accountable owner, effective evidence, and a rehearsed response across the boundary.