The Three Cloud Service Models
Think of it like pizza: IaaS = you buy ingredients and cook it yourself. PaaS = someone delivers the dough and sauce — you add toppings and bake. SaaS = pizza delivered to your door, fully cooked — you just eat it.
The key question: who patches the operating system? IaaS = you do. PaaS = provider does. SaaS = provider does. This distinction appears constantly on Security+ scenarios.
The Shared Responsibility Model
The shared responsibility model defines the security boundary between the cloud provider and the customer. This is the most important cloud concept on Security+ SY0-701 — the exam gives you a security incident and asks who is responsible for preventing it.
| Responsibility | On-Premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Physical security (datacentre) | Customer | Provider | Provider | Provider |
| Network infrastructure | Customer | Provider | Provider | Provider |
| Hypervisor / virtualisation | Customer | Provider | Provider | Provider |
| Operating system | Customer | Customer | Provider | Provider |
| Runtime / middleware | Customer | Customer | Provider | Provider |
| Application | Customer | Customer | Customer | Provider |
| Data | Customer | Customer | Customer | Shared |
| Identity & access management | Customer | Customer | Customer | Customer |
Identity and access management is always the customer's responsibility — in every cloud model. The provider can never manage who in your organisation should have access to your data. If someone in your company has excessive permissions or a credential is stolen, that's on you regardless of whether you use IaaS, PaaS, or SaaS.
Similarly, your data is always your responsibility in IaaS and PaaS. In SaaS it's shared — the provider secures the platform but you're responsible for what data you put in and who in your org can access it.
Cloud Deployment Models
Key Cloud Security Concepts
| Concept | What It Is | Exam Relevance |
|---|---|---|
| CASB | Cloud Access Security Broker — sits between users and cloud services to enforce security policies, DLP, and visibility into cloud usage | Security+ — controlling shadow IT and cloud data loss |
| Shadow IT | Employees using unauthorised cloud services (e.g. personal Dropbox for work files) without IT's knowledge or approval | Security+ — risk of data leaving the organisation |
| Cloud-native security | Security tools built into the cloud platform — AWS Security Hub, Azure Defender, GCP Security Command Center | Security+ — provider-managed vs customer-managed controls |
| Serverless | Functions-as-a-Service (FaaS) — code runs in response to events without managing servers. AWS Lambda, Azure Functions. | Security+/Network+ — attack surface is the code, not the OS |
| Containers | Lightweight, isolated application environments (Docker). Run on a shared OS kernel unlike full VMs. Orchestrated by Kubernetes. | Security+ — container escape, image security, registry security |
| VM escape | An attacker breaks out of a virtual machine to access the hypervisor or other VMs on the same host | Security+ — virtualisation security risk |
| Data sovereignty | Laws requiring data to stay within a specific country's borders — affects which cloud regions can be used | Security+ — compliance and jurisdiction concerns |
| Right to audit | Contractual right allowing a customer to audit a cloud provider's security controls and compliance | Security+ — third-party risk management |
Cloud vs On-Premises — Key Differences
| Factor | On-Premises | Cloud |
|---|---|---|
| Capital expense | High upfront (hardware purchase) | Low upfront — operational expense (pay-as-you-go) |
| Scalability | Limited by physical hardware — slow to scale | Elastic — scale up or down in minutes |
| Physical security | Your responsibility | Provider's responsibility |
| Patching | Always your responsibility | Depends on service model (shared in IaaS, provider in SaaS) |
| Customisation | Full control | Limited by what the provider offers |
| Availability | Depends on your infrastructure/redundancy | Provider SLA — typically 99.9%+ uptime guaranteed |
Exam Scenarios
Study all three CompTIA exams
Cloud concepts appear on A+, Network+, and Security+. See the best resources for each.
The Economics of Cloud — Why Organisations Move to Cloud
Understanding why cloud exists helps you answer scenario questions about when to recommend cloud vs on-premises. Cloud's core economic argument is the shift from capital expenditure (CapEx) to operational expenditure (OpEx). Buying servers, networking equipment, and datacenter space requires large upfront investment that depreciates over 3–5 years. Cloud replaces this with monthly operating costs that scale with actual usage — you pay for what you consume, when you consume it.
For start-ups and growing organisations this is transformative: a company can launch a globally distributed application without buying a single server. For established enterprises the calculus is more complex — at sufficient scale, owned infrastructure can be cheaper than cloud, but the operational overhead of maintaining it must be factored in. The exam doesn't ask you to calculate TCO (total cost of ownership), but it does expect you to understand the CapEx vs OpEx trade-off and when each model is appropriate.
Elasticity is the other key cloud advantage — the ability to scale resources up or down automatically based on demand. A retailer's website that handles 10x normal traffic on Black Friday doesn't need to own hardware capable of handling Black Friday traffic 365 days a year. Cloud auto-scaling provisions additional capacity when needed and releases it when demand drops. This is fundamentally different from on-premises where you must own enough hardware for peak load regardless of average utilisation.
Multi-Cloud and Hybrid Cloud — Real-World Architectures
Hybrid cloud combines on-premises infrastructure with one or more cloud providers, connected via dedicated links (AWS Direct Connect, Azure ExpressRoute) or encrypted VPN tunnels. Hybrid is the most common enterprise architecture because most large organisations can't migrate everything to cloud immediately — regulatory requirements, latency-sensitive applications, and legacy systems that can't be easily migrated keep some workloads on-premises while new workloads are cloud-native. The exam tests hybrid cloud as a deployment model alongside public, private, and community cloud.
Multi-cloud uses services from multiple cloud providers simultaneously — AWS for compute, Azure for Active Directory integration, Google Cloud for machine learning workloads. Organisations adopt multi-cloud to avoid vendor lock-in, optimise costs (different providers price services differently), and improve resilience (an outage at one provider doesn't take down everything). The operational complexity of managing multiple cloud environments is the primary trade-off.
Community cloud is shared infrastructure operated for a specific community with common concerns — for example, a cloud platform shared by multiple healthcare organisations that all have HIPAA compliance requirements, or a government cloud shared by multiple federal agencies. Community cloud provides economies of scale while maintaining isolation from the general public cloud. This is the least common deployment model and tested less frequently, but it does appear on exam questions about which deployment model suits a specific regulated-industry scenario.
Cloud Service Models — What You Actually Manage
The practical impact of choosing IaaS vs PaaS vs SaaS is how much you manage. In IaaS (AWS EC2, Azure VMs, Google Compute Engine), you provision virtual machines and are responsible for everything on them: operating system installation and patching, application installation and configuration, security hardening, and monitoring. IaaS gives maximum control and flexibility at the cost of maximum operational responsibility. This is the right choice when you need specific OS configurations, run custom applications, or are "lifting and shifting" existing workloads to cloud.
In PaaS (AWS Elastic Beanstalk, Azure App Service, Google App Engine), the platform manages the OS, runtime, and scaling automatically. You deploy your application code and the platform handles everything beneath it. PaaS is the right choice for development teams that want to focus on writing application code rather than managing infrastructure — a developer can deploy a web application without knowing anything about Linux administration or load balancer configuration. The trade-off is less control — you can't customise the underlying OS or choose specific runtime versions beyond what the platform offers.
In SaaS (Microsoft 365, Salesforce, Google Workspace, Dropbox), the provider manages everything including the application itself. You configure the application through the user interface or admin portal, but you cannot access the underlying infrastructure, operating system, or database. SaaS is the right choice for standard business applications where you don't need customisation beyond what the vendor's settings allow. The exam often asks what you're responsible for in SaaS — the answer is always your data and user access management. Everything else is the provider's responsibility.
Cloud Storage Types — Object, Block, and File
Object storage (AWS S3, Azure Blob Storage, Google Cloud Storage) stores data as flat objects with metadata and a unique identifier. There is no directory hierarchy — objects are stored in "buckets" or "containers" and retrieved by key (essentially a filename). Object storage is massively scalable, cheaply priced, and designed for unstructured data: images, videos, backups, log files, static website assets. It is not suitable for workloads that need low-latency random read/write access (like databases).
Block storage (AWS EBS, Azure Managed Disks) presents virtual disk volumes to compute instances that are formatted with a filesystem and used like a physical hard drive. Block storage is used for OS volumes on VMs, databases, and any workload that needs traditional filesystem access. It's faster and lower latency than object storage but more expensive and tied to a specific compute instance.
File storage (AWS EFS, Azure Files) provides shared filesystem access that multiple instances can mount simultaneously using NFS or SMB protocols. File storage is suitable for shared application data, lift-and-shift of NAS workloads, and any scenario where multiple VMs need to access the same files. On the exam, the distinguishing question is usually: "multiple EC2 instances need to share the same data concurrently" → file storage (EFS), not block storage (EBS), which can only be attached to one instance at a time.