Cloud Architecture and the Shared Responsibility Model
When an organization moves workloads to the cloud, it does not outsource accountability — it splits operational duties with the provider. The responsibility matrix is the document that spells out exactly who patches what, who configures what, and who answers for a breach at each layer. The single most common cloud failure on the exam (and in real life) is a customer assuming the provider handles something the matrix says the customer owns, such as storage bucket permissions.
Responsibility matrix — A chart published by a cloud provider showing which security duties (physical, hypervisor, OS, application, data, identity) belong to the provider and which remain with the customer for each service model.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical facility & hardware | Provider | Provider | Provider |
| Hypervisor / virtualization | Provider | Provider | Provider |
| Operating system & patching | Customer | Provider | Provider |
| Application code / configuration | Customer | Customer | Provider |
| Data classification & protection | Customer | Customer | Customer |
| Identity & access management | Customer | Customer | Customer |
Hybrid environments — part on-premises, part cloud — add their own considerations: identities must be synchronized across both sides, data moves over links that must be encrypted, and security tooling that watches the datacenter may be blind to the cloud half. Attackers love hybrid seams because monitoring and policy are rarely consistent across them.
Third-party vendors in a cloud architecture (managed service providers, SaaS integrations, marketplace images) extend your attack surface to organizations you do not control. Vendor risk must be managed with contracts, right-to-audit clauses, and continuous monitoring — a compromise at a vendor with API access to your tenant is effectively a compromise of you.
Exam tip: On the exam, if a question asks who is responsible for data in any cloud model — IaaS, PaaS, or SaaS — the answer is always the customer. The provider never assumes responsibility for classifying or protecting your data content.
It helps to picture how this fails in practice. A team spins up object storage in IaaS, uploads customer records, and leaves the bucket policy set to public because "the cloud provider handles security." The provider *did* handle its share — the disks are encrypted, the datacenter is guarded, the hypervisor is patched — but the access policy sits squarely on the customer's side of the matrix. Nearly every headline cloud data leak follows this shape: the platform worked exactly as configured, and the configuration was the breach.
Don't confuse: "The provider is compliant" does not make you compliant. Certifications like SOC 2 or ISO 27001 on the provider's side cover the layers the provider operates. Your workloads, identities, and data configurations must be assessed separately — auditors call this the difference between compliance of the cloud and compliance in the cloud.
A company runs virtual machines in an IaaS environment. A critical vulnerability is announced in the guest operating system. Who is responsible for applying the patch?
An organization adopts a SaaS HR platform. Which security responsibility remains with the organization?