What IaaS, PaaS, and SaaS mean structurally — not just acronyms
The Shared Responsibility Model — what you always own vs. what varies
Real cloud vendor examples for each service model
Security controls unique to each model and their exam implications
94%
Enterprises use cloud services in 2025 (Flexera)
678B
Global cloud market size USD (2024)
99%
Cloud breaches caused by customer misconfig (Gartner)
No matter what cloud service model you choose, the customer ALWAYS owns the data, the endpoints, and the user identities. The provider never owns your data.

The Shared Responsibility Reality

When an enterprise migrates to 'The Cloud,' they do not transfer all security responsibility to the provider. The Shared Responsibility Model is a division of security duties formalized in every cloud service agreement. The critical exam question is: who patches the OS? Who configures the firewall? The answer changes by model.

Service Model Comparison

IaaS (Infrastructure as a Service) provides raw virtualized compute, storage, and networking. The cloud provider manages the physical hardware, power, cooling, and the base hypervisor. You get a Virtual Machine and control everything above it. You own: Operating System (patching, hardening), application stack, database configuration, virtual network firewall rules, data security, identity management. Cloud provides: Physical servers, hypervisor, physical network infrastructure, physical security of data centers. Security implication: You can install an EDR agent, configure OS-level security controls, and segment virtual networks exactly like on-premise. Maximum control, maximum responsibility. Examples: AWS EC2, Azure Virtual Machines, Google Compute Engine, DigitalOcean Droplets. Hotel Analogy: Renting a bare plot of land. You architect, build, and maintain the entire house.
PaaS (Platform as a Service) provides a managed runtime environment. The cloud provider manages hardware *and* the Operating System. You only upload your application code and your data. You own: Application code security, API security design, data classification and encryption, user access management within the app. Cloud provides: Hardware, hypervisor, operating system patching, runtime environment (Node.js, Python, Java), middleware. Security implication: You CANNOT install OS-level security tools (EDR/AV) because you have no root OS access. You must rely on application-layer security controls and the provider's platform-level protections (WAF, network isolation). Examples: AWS Elastic Beanstalk, Heroku, Azure App Service, Google App Engine. Hotel Analogy: Renting a fully-furnished apartment. Landlord owns plumbing/wiring. You bring your furniture and belongings.
SaaS (Software as a Service) provides a complete application delivered via browser. The provider manages everything: hardware, OS, application, and even database. You simply log in and use the interface. You own: User identity governance (who has access, with what privileges), MFA enforcement, data classification, acceptable use policies, and monitoring user activity within the application. Cloud provides: Everything else — hardware, OS, application, database infrastructure, availability, patching. Security implication: Your security controls are limited to configuration options the vendor exposes. You must review vendor SOC 2 Type II reports and ensure data processing agreements (DPAs) exist for GDPR/HIPAA compliance. Examples: Salesforce, Microsoft 365, Google Workspace, Dropbox, Zoom, ServiceNow. Hotel Analogy: Staying in a hotel room. You have access to what's provided. You bring only your personal items (your data).
Organizations rarely use a single model. Hybrid cloud combines on-premise resources with public cloud services (AWS/Azure/GCP) — connected via VPN or ExpressRoute/Direct Connect for low-latency private connectivity. Multi-cloud uses services from multiple public cloud providers simultaneously — AWS for compute, Azure for Active Directory, GCP for AI workloads. Security challenges: Extended attack surface across providers, inconsistent IAM policies, data sovereignty questions across jurisdictions, and lack of unified visibility for the SIEM. Exam context: Questions involving both on-premise and cloud resources often discuss CASB (Cloud Access Security Broker) as the visibility and control layer sitting between users and cloud services.

Shared Responsibility Matrix

Entity ResponsibleIaaSPaaSSaaS
Physical Hardware & DatacenterProviderProviderProvider
Hypervisor / VirtualizationProviderProviderProvider
Operating SystemCustomerProviderProvider
Runtime / MiddlewareCustomerProviderProvider
Application CodeCustomerCustomerProvider
Data & EncryptionCustomerCustomerCustomer
Identity & Access ManagementCustomerCustomerCustomer
Endpoint DevicesCustomerCustomerCustomer

Real-World Scenario

A security analyst discovers an unpatched Apache vulnerability is being exploited on the company's web server. Who is responsible for patching it? If the server is an EC2 instance (IaaS), the customer must patch it. If it's running on Elastic Beanstalk (PaaS), the platform manages the runtime — but the customer's custom application code security remains their responsibility. If it's Microsoft 365 (SaaS), Microsoft patches it entirely.

The SY0-701 exam key: 'patch an Apache/Windows Server vulnerability' = IaaS. 'Upload web application files' = PaaS. The model changes who owns the OS layer. What never changes: the customer always owns the data and user identity management — in every cloud model.
  • IaaS: You own the OS upward. Highest control, highest responsibility.
  • PaaS: You own the app code and data. OS managed by provider — no EDR agent possible.
  • SaaS: You own only identity/data governance. Provider owns everything else.
  • Data and IAM are ALWAYS the customer's responsibility regardless of service model.
  • 99% of cloud breaches are customer misconfiguration — not provider vulnerabilities.

Ready to test your knowledge?

Take a free full-length practice exam with 90 questions and instant feedback.

Start Practice Exam