16.2 Cloud Security: Deployment, Service Models, and Shared Responsibility
Key Takeaways
- SSCP knowledge area 7.4 (outline effective 1 October 2025) deployment models are public, private, hybrid, and community. Community is a shared pool for organizations with a common mission or compliance need, not a synonym for hybrid.
- Service models are Infrastructure as a Service, Platform as a Service, and Software as a Service. Who patches the guest operating system is the fastest way to tell them apart on CAT items.
- In Infrastructure as a Service you patch the guest operating system, applications, and virtual-network configuration; the provider patches the hypervisor, hardware, and facility. In Software as a Service the provider patches the application stack; you still own identity, access, data classification, and acceptable use.
- A virtual private cloud is an isolated virtual network you configure inside a public cloud. It is not a private-cloud building and it does not move legal jurisdiction by itself.
- The shared responsibility model never lets the customer hand data classification or identity governance to the provider, regardless of service model.
Why cloud configuration is a Domain 7 operations skill
Knowledge area 7.4 is Understand and configure cloud security. Domain 7 as a whole remains 15% of the SSCP under the outline effective 1 October 2025. This section teaches the first cluster of 7.4 bullets: deployment models (public, private, hybrid, community), service models (Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS)), virtualization (hypervisor, virtual private cloud (VPC)), and the shared responsibility model. Legal and regulatory concerns, data storage and transmission, and third-party or outsourcing requirements are the next section. Secure virtual environments (Type 1 versus Type 2, containers, virtual machine escape) are knowledge area 7.5.
The SSCP is a practitioner credential. You are not being asked to recite a provider's marketing names. You are being asked who patches the guest operating system this week, whether a VPC is the same thing as a private cloud, and what you still own when the clinic's charting system is SaaS.
Deployment models
A deployment model is who shares the pool and where it lives, not which service tier you bought.
| Model | Who shares the infrastructure | Typical SSCP tell | Trap |
|---|---|---|---|
| Public | Provider's multi-tenant infrastructure, consumed over the internet by many customers | Clinic virtual machines in a commercial region; you pay for capacity | Public does not mean the data is public; it means the platform is multi-tenant |
| Private | Dedicated to one organization, on-premises or hosted for that tenant only | Hospital-owned rack running a hypervisor cluster only for that hospital | Hosted-private is still private if the pool is not shared with other customers |
| Hybrid | Combination of private and public, usually with connectivity and consistent identity | Burst rendering to public cloud while protected health information (PHI) stays in the on-premises cluster | Hybrid is not two SaaS products; it is two deployment models working together |
| Community | Shared by organizations with a common mission, industry, or compliance community | Several clinics on a regional health-information network with a shared control baseline | Community is not a synonym for hybrid or for public |
If the stem says several hospitals jointly consume a cloud that is built to a health-sector baseline and is not open to arbitrary tenants, that is community. If the stem says production stays in the data hall and disaster-recovery copies run in a commercial region, that is hybrid. Do not answer public merely because a browser is involved.
Service models: who patches what
A service model is how much of the stack the provider operates. The outline's examples are IaaS, PaaS, and SaaS. Shared responsibility is easier if you memorize the patch line.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Data classification, identity, access, acceptable use | Customer | Customer | Customer |
| Application code and tenant configuration | Customer | Customer (your code and config) | Provider operates the app; customer still configures tenants, roles, and data |
| Guest operating system patches | Customer | Provider | Provider |
| Runtime / middleware | Customer unless you buy it as a service | Provider | Provider |
| Hypervisor, host, physical facility | Provider | Provider | Provider |
| Virtual network / VPC configuration | Customer designs subnets, routes, and security groups; provider runs the fabric | Mixed — you still own how your app is exposed | Provider; you still own who may sign in |
IaaS sells compute, storage, and network. You deploy a guest operating system and you patch it. Leaving an IaaS virtual machine unpatched because it lives at a famous provider is how ransomware walks a subnet.
PaaS sells a runtime (application platform, managed database, functions). You do not patch the operating system. You still own the code you push, secrets, and who can invoke the function.
SaaS sells the finished application. You do not patch the application binary. You still own accounts, multi-factor authentication (MFA), data you put in, and whether marketing may export member lists.
Scenario (who patches IaaS versus SaaS). The clinic runs two workloads. Claims imaging is a fleet of IaaS virtual machines you built from a gold image. Charting is a SaaS EHR in another company's region.
- Tuesday's guest operating-system cumulative update on the imaging servers is your change window. The IaaS provider will not log in and patch Windows for you. They will patch the hypervisor and the hardware under the virtual machines.
- Tuesday's EHR application patch is the vendor's. You still verify that MFA is enforced, that former contractors are deprovisioned, and that export roles match job functions. You do not get to skip identity hygiene because the vendor patched the app.
- If an imaging virtual machine is compromised, you isolate it, rebuild from a known-clean image, and review security groups. If the SaaS EHR is compromised at the provider, you still rotate tenant credentials, review audit logs you can export, and execute the contract — you do not patch their kernel.
Exam trap: answering that SaaS means the customer has no security work, or that IaaS means the provider patches the guest operating system because they own the building.
Virtualization in the cloud: hypervisor and VPC
The outline's virtualization examples under 7.4 are hypervisor and virtual private cloud (VPC). Type 1 versus Type 2 detail is knowledge area 7.5; here you need the cloud meaning.
A hypervisor is the software (or firmware plus software) that multiplexes physical hosts into virtual machines. In public IaaS you do not walk up to that hypervisor. You consume virtual machines, virtual disks, and a software-defined network the provider operates. You still choose sizes, images, and whether management ports are exposed to the internet — that last choice is how brute-force against Remote Desktop becomes your incident, not the provider's.
A VPC is an isolated virtual network you define inside a public (or hosted) cloud: subnets, route tables, gateways, security groups or network access control lists (ACLs), and peering. It is how you keep the imaging subnet from being a default-open campus. A VPC is not:
- A private-cloud building. You can have a VPC in a public region.
- Automatic encryption or automatic legal jurisdiction. Data residency is a contract and region choice, taught in the next section.
- A substitute for guest hardening. A perfect subnet with an unpatched guest is still IaaS customer failure.
Peering, transit gateways, and hybrid VPN or dedicated interconnects turn a VPC into the cloud side of a hybrid deployment. Mis-peering a development VPC to production is a segmentation failure, the same class of mistake as a flat virtual local area network on-premises.
Shared responsibility — the exam's operational test
The shared responsibility model is the split of who implements which control, not a way to dump accountability. Across every service model the customer retains:
- Data — classification, what you upload, encryption in the application, retention.
- Identity and access — accounts, federation, MFA, joiner-mover-leaver.
- Acceptable use and configuration of the tenant — which features are on, which regions, which sharing links.
The provider retains the physical facility, hardware, and (except when you run your own private-cloud hypervisor) the hypervisor. Everything between those poles moves with IaaS, PaaS, and SaaS as in the table above.
Exam traps. Calling a VPC a private cloud. Calling community cloud hybrid. Claiming the IaaS provider patches Windows because the virtual machine is in their region. Claiming SaaS means you no longer own personally identifiable information (PII) you typed in. Treating shared responsibility as shared blame after an incident instead of a pre-agreed patch line.
When a CAT item asks who patches what, name the service model first, then the layer. Guest operating system on IaaS is you. Application binary on SaaS is the vendor. Identity is you either way.
A clinic runs claims-imaging virtual machines on Infrastructure as a Service and charting on a Software as a Service electronic health record. Who is responsible for patching the guest operating system on the imaging servers versus the charting application?
Several independent clinics jointly consume a cloud environment built for health-sector controls and not offered to arbitrary public tenants. Which SSCP deployment model is this?
Which statement about virtual private clouds and shared responsibility is correct for SSCP knowledge area 7.4?