Every cloud security exam includes one or more questions on the shared responsibility model — and most real-world cloud breaches trace back to a misunderstanding of it. Internalise this lesson and the rest of the course makes much more sense.
The Core Idea
The cloud provider operates the platform; the customer operates the workloads on top. Both have security responsibilities, and they split along a line that moves depending on the service model.
| Provider responsibility ("of the cloud") | Customer responsibility ("in the cloud") |
|---|---|
| Physical data centres, hardware, hypervisor, region/AZ infrastructure, global network, the managed services themselves | IAM, data, applications, OS patching (where you control the OS), configuration of network controls and encryption, monitoring and incident response on your workloads |
How the Line Shifts: IaaS → PaaS → SaaS
| Layer | IaaS (EC2, Compute Engine VMs) | PaaS (App Service, App Engine) | SaaS (Microsoft 365, Workspace) |
|---|---|---|---|
| Physical / hardware | Provider | Provider | Provider |
| Virtualisation | Provider | Provider | Provider |
| Operating system | Customer | Provider | Provider |
| Runtime / middleware | Customer | Provider | Provider |
| Application | Customer | Customer | Provider |
| Data | Customer | Customer | Customer |
| Identity / access | Customer | Customer | Customer |
| Configuration of controls | Customer | Customer | Customer |
Notice the constants: regardless of service model, identity, data, and configuration are always yours. That is where attackers focus — and where most defenders are weakest.
Per-Cloud Wording
- AWS — "Security of the cloud" (AWS) vs "Security in the cloud" (customer).
- Azure — "Shared responsibility model" with categorised matrix per service tier.
- GCP — "Shared fate" — Google emphasises providing tools, blueprints, and joint accountability rather than just leaving customers to figure it out.
The substance is the same. Exam tip: when you see "in the cloud" or "above the hypervisor," it is a customer responsibility.
Common Real-World Failures (All Customer Side)
- Public S3 / Blob / GCS bucket with sensitive data. Provider gave you private-by-default; you flipped a switch.
- Overly broad IAM — wildcards in policies, long-lived access keys committed to GitHub.
- Open security group on 0.0.0.0/0:22 for an admin port.
- Unencrypted EBS / managed disk / persistent disk. Encryption is one checkbox.
- Missing logs / disabled CloudTrail / Audit Logs / Activity Logs. You cannot investigate what was not recorded.
- No MFA on root / global admin accounts. Catastrophic if compromised.
None of these are platform vulnerabilities. They are configuration choices. The cloud provider published the docs; the customer skipped them.
Hybrid / Edge / Co-location
If you run workloads on-prem, edge, or hybrid (Outposts, Anthos, Arc), the line moves again. You retain some hardware and physical responsibility. Read the specific service docs — exam questions love this nuance.
The Five Customer Pillars
Every cloud you use, plan around five customer-side pillars:
- Identity — who is who, MFA, roles, federation, least privilege.
- Network — VPC design, segmentation, egress control, private connectivity.
- Data — classification, encryption, key management, DLP.
- Workload — image hardening, patching, runtime protection.
- Detection & response — logs, alerts, runbooks, recovery.
Each subsequent lesson maps to one of these pillars.
Mental Model: "What Do You Configure?"
Whenever you spin up a new cloud service, ask: what controls do I configure? Even fully-managed services expose configuration surfaces — IAM policies, encryption settings, network ACLs, audit log destinations. That is your responsibility envelope.
If a service exposes no security controls (rare in real clouds), the provider handles it. If it exposes one toggle, that toggle is your job to set correctly. The next lesson dives into the most important toggle of all: identity.