Cloud Shared Responsibility and Service Models
Key Takeaways
- Shared responsibility divides security tasks between the cloud provider and the customer, but the split changes by service model.
- In IaaS, the customer manages more: operating systems, applications, data, identities, and many network controls.
- In PaaS, the provider manages more of the platform, while the customer still owns data, identities, application configuration, and access.
- In SaaS, the customer usually manages users, data, tenant settings, access policies, and monitoring of tenant activity.
- Misconfiguration, weak IAM, exposed storage, and missing logging are common cloud architecture risks on SY0-701.
Cloud Shared Responsibility and Service Models
Cloud security questions often turn on one phrase: who is responsible? The provider secures the cloud infrastructure. The customer secures what they put in the cloud and how they configure it. The exact split depends on the service model.
Service Model Responsibility Table
| Responsibility | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical data center | Provider | Provider | Provider |
| Hypervisor and hardware | Provider | Provider | Provider |
| Guest operating system | Customer | Provider | Provider |
| Runtime and platform | Customer | Provider | Provider |
| Application code | Customer | Customer | Provider |
| Data classification and handling | Customer | Customer | Customer |
| Identity and access configuration | Customer | Customer | Customer |
| Tenant security settings | Customer | Customer | Customer |
| User activity review | Customer | Customer | Customer |
Exam shortcut: the provider usually handles "of the cloud"; the customer handles "in the cloud." Data, identity, access, and configuration remain customer concerns in every model.
Cloud Architecture Terms
| Term | Meaning | Security concern |
|---|---|---|
| Public cloud | Shared provider infrastructure used by many customers | Tenant isolation, configuration, IAM |
| Private cloud | Cloud-like platform dedicated to one organization | Internal governance and platform hardening |
| Hybrid cloud | Mix of on-prem and cloud | Identity federation, routing, data movement |
| Multi-cloud | Use of more than one cloud provider | Policy consistency, monitoring complexity |
| Region | Geographic cloud location | Data residency, latency, resilience |
| Availability zone | Isolated facility group within a region | High availability and fault isolation |
Common Cloud Controls
| Risk | Control |
|---|---|
| Public storage exposure | Block public access, bucket policy review, encryption, logging |
| Overprivileged administrators | Role-based access, MFA, just-in-time access, access reviews |
| Lost cloud logs | Centralized log export, retention policy, immutable storage where needed |
| Unpatched IaaS instances | Patch management, golden images, vulnerability scanning |
| Secrets in code | Secret manager, rotation, CI scanning |
| Insecure internet exposure | Security groups, network ACLs, private endpoints, WAF |
ACL Mini Example
Scenario: A cloud VM in a public subnet serves HTTPS traffic. A database runs in a private subnet. Administrators connect from a corporate VPN.
Example security group intent:
| Target | Rule |
|---|---|
| Web VM inbound | Allow TCP 443 from 0.0.0.0/0 |
| Web VM inbound admin | Allow SSH or RDP only from VPN admin subnet |
| Database inbound | Allow database port only from web or app security group |
| Database inbound public | Deny all internet sources |
| All systems outbound logs | Allow to centralized logging endpoint |
Do not read "cloud" as "automatically secure." Cloud makes secure patterns available, but the customer must select and configure them correctly.
PBQ-Style Scenario
A team deploys an IaaS Linux server for a public application. The provider says the underlying host is patched. A scan shows the guest OS has critical vulnerabilities.
Best conclusion: the customer must patch the guest OS because IaaS leaves operating system maintenance to the customer. The provider patching the hypervisor does not patch the customer VM.
Second scenario: A SaaS email platform suffers a user mailbox compromise because the tenant did not require MFA. The provider runs the email service, but the customer usually owns tenant identity policy, user access, and monitoring. The best answer is to enforce MFA and review risky sign-ins, not to patch the SaaS provider's servers.
Cloud Exam Traps
- Trap: "The provider is responsible for all security." Incorrect. Customer data, identity, access, and configuration still matter.
- Trap: "SaaS means no customer security work." Incorrect. Tenant settings, users, retention, DLP, and logs still matter.
- Trap: "Encryption solves public exposure." Encryption helps confidentiality, but public access can still leak data to authorized-by-policy outsiders.
- Trap: "Multi-cloud automatically improves resilience." It can, but it also increases complexity and requires consistent identity, logging, and governance.
A company runs a database on a cloud IaaS virtual machine. Who is typically responsible for patching the guest operating system?
A company uses a SaaS CRM. Which responsibilities normally remain with the customer? Choose three.
Select all that apply
A storage bucket contains confidential reports and is accidentally made public. Which response best addresses the architecture issue?