Legacy Haven University

Technicians lose tickets when they treat every cloud product as the same product. CompTIA A+ Core 1 (220-1201) objective 4.2 requires you to summarize cloud computing concepts, and the exam separates those products by who provisions the stack and who still owns the work.

Cloud computing, as NIST defines it in SP 800-145, gives on-demand network access to a shared pool of configurable resources—networks, servers, storage, applications, and services—that you provision and release with little provider hand-holding. CompTIA maps that idea onto two lists you must keep distinct in your head: service models (IaaS, PaaS, SaaS) and deployment models (private, public, hybrid, community). The objectives document groups both lists under “common cloud models.” That grouping is CompTIA’s wording, not NIST’s. NIST treats service models and deployment models as separate axes. You can combine any service model with any deployment model.

Domain 4 (Virtualization and Cloud Computing) is 11% of Core 1. Objective 4.1 covers virtual machines, hypervisors, containers, and VDI. Objective 4.2 covers the cloud models and characteristics below. If you are building a Core 1 study path, start from the A+ Core 1 hub and treat 4.2 as recall work: the questions almost always describe a scenario and ask which model it is.

How the three service models actually split the stack

Every workload sits on the same layers: physical facility, network, storage, compute, hypervisor, guest operating system, runtime/middleware, application, and data. The service model answers one question: which layers does the provider operate, and which layers do you still configure?

Walk the stack from the metal up.

Infrastructure as a Service (IaaS)

IaaS hands you processing, storage, networks, and other fundamental compute so you can deploy arbitrary software, including operating systems and applications. You do not run the data center. You do control the guest OS, storage layout, and deployed apps, and you often get limited control of selected network pieces such as a host firewall. That is NIST’s definition, and it is the definition CompTIA expects you to apply.

Under the hood, the provider stands up physical hosts, a Type 1 hypervisor, and a control plane. You open a portal or API, request a virtual machine, attach a virtual disk, attach a virtual NIC, and pick an image. The hypervisor schedules your vCPU on real cores, maps your virtual disk to a LUN or object store, and enforces isolation from the next tenant. You then install patches, join a domain, configure the guest firewall, and put your application on that guest.

That last sentence is the exam tell. If the technician still patches the OS, the model is IaaS. AWS documents Amazon EC2 this way: EC2 is IaaS, and the customer manages the guest OS, the software on the instance, and the instance firewall (a security group).

IaaS fits lift-and-shift servers, lab hosts, and any workload that needs a full OS. It also carries the most technician labor of the three models.

Platform as a Service (PaaS)

PaaS lets you deploy your application onto a provider-supported runtime. You pick languages, libraries, services, and tools the provider already runs. You do not manage the network, servers, operating systems, or storage. You do control the deployed application and, sometimes, settings on the hosting environment.

The provider now owns the guest OS and the runtime (the language interpreter, application server, and managed database engine). You push source or a build artifact. The platform builds, hosts, scales, and patches the platform layer. You write code, set environment variables, bind a datastore, and read logs.

The exam tell is the missing OS. If the scenario says developers deploy an app and never touch Windows or Linux patch Tuesday, the model is PaaS.

Software as a Service (SaaS)

SaaS gives you the provider’s application running on the provider’s cloud. You reach it through a thin client such as a web browser—NIST’s own example is web-based email—or through a program interface. You do not manage the network, servers, OS, storage, or even most application features. You may change user-level settings.

The provider operates every layer through the application. You create accounts, assign licenses, set sharing permissions, and enter data. You do not deploy the app, and you do not patch it.

The exam tell is consumption. If users sign in and work, and no one on your team installs the product on a server, the model is SaaS.

Responsibility matrix: who still owns the work

CompTIA 220-1201 does not name a “shared responsibility model” as an objective. The distinction still decides every IaaS/PaaS/SaaS item, because the three models are defined by control. Use this matrix when a question describes tasks instead of acronyms.

Data and identity never leave the customer. SaaS does not mean “the vendor is responsible for your users’ passwords or for what they upload.”

Read a ticket against that table. “Spin up a VM, install Ubuntu, open port 443” is IaaS. “Push this Node.js app to a hosted runtime” is PaaS. “License the email suite and add the new hire” is SaaS.

Deployment models sit on a different axis

CompTIA lists four deployment models next to IaaS/PaaS/SaaS. Do not treat them as substitutes for service models. They answer who may use the infrastructure, not which layers you manage.

Private cloud. One organization uses the infrastructure exclusively. The org, a third party, or both may own and operate it. It may live on-premises or off-premises.

Public cloud. The general public may use it. It lives on the provider’s premises.

Community cloud. A defined community with shared concerns—mission, security requirements, policy, compliance—uses it exclusively.

Hybrid cloud. Two or more distinct clouds (private, community, or public) stay separate systems but connect through technology that moves data or apps between them. NIST’s example is cloud bursting for load balancing.

A hospital can run SaaS email on a public cloud and IaaS imaging servers in a private cloud, then stitch the two into a hybrid. The service model and the deployment model are independent knobs.

Cloud characteristics CompTIA actually lists

Objective 4.2 also requires these characteristics. Learn CompTIA’s labels. Do not replace them with older 220-1101 phrasing or with NIST’s five-characteristic list unless a question uses that language.

Shared resources vs. dedicated resources. Shared resources put more than one customer on the same physical pool and isolate them logically. Dedicated resources reserve capacity for one customer. Shared is cheaper and is the default public-cloud pattern. Dedicated costs more and shrinks noisy-neighbor risk.

Metered utilization, including ingress and egress. The platform measures what you use—compute time, storage, bandwidth, active accounts—and bills against that meter. NIST calls this measured service. CompTIA adds the traffic direction: ingress is data into the cloud; egress is data out. Providers often price those flows differently, so a backup job that pulls terabytes out of a region is an egress event, not a free download.

Elasticity. You add or remove capacity as demand changes. To the consumer the pool looks unlimited. Scale out when the queue grows; scale in when it drains. CompTIA’s word is elasticity, not “rapid elasticity.”

Availability. The service stays reachable at the rate the contract describes. Design for it with redundant zones, but do not invent SLA percentages the exam objectives do not publish.

File synchronization. Clients keep a local copy and a cloud copy in step. A change on the laptop appears on the phone after the sync service writes the object and the other client pulls it.

Multitenancy. One instance of the platform serves many customers (tenants). Logical isolation—accounts, virtual networks, encryption keys—keeps Tenant A out of Tenant B’s data even when both sit on the same host.

NIST’s five essential characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service) explain why those CompTIA bullets exist. Use NIST to understand the mechanism. Answer with CompTIA’s terms.

How a Core 1 item usually frames this

Expect a short story, not a definition dump.

• A help-desk team licenses a browser-based productivity suite and never installs a mail server. SaaS.
• A technician requests four vCPUs, 16 GB RAM, and a 200 GB disk, then installs a guest OS. IaaS.
• Developers upload application code to a hosted runtime the vendor patches. PaaS.
• Two firms that share a compliance regime run workloads on infrastructure reserved for that group. Community cloud.
• An on-premises private cloud overflows into a public cloud overnight, then drains back. Hybrid, using elasticity.

Wrong answers often mix axes: “SaaS” when the stem is really “public,” or “IaaS” when the user only changes application settings.

Virtualization (4.1) is the engine under IaaS. Provisioning a VM is IaaS work; knowing Type 1 vs Type 2 is 4.1 work. Keep those objectives separate when you study from the A+ Core 1 (220-1201) guide.

Authoritative References

• https://assets.ctfassets.net/82ripq7fjls2/1oSdlyujpaX3GrM0rir6Ge/91afb2be72785281e8fb4c0d9a70c6f4/CompTIA-A-220-1201-Exam-Objectives-3.0.pdf — CompTIA A+ 220-1201 Exam Objectives, Version 3.0 (Domain 4.2 wording, domain weights)
• https://www.comptia.org/en-us/certifications/a/core-1-v15/ — Official A+ Core 1 V15 exam page (220-1201, 11% Virtualization and Cloud Computing, passing score 675)
• https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf — NIST SP 800-145, The NIST Definition of Cloud Computing (September 2011)
• https://aws.amazon.com/compliance/shared-responsibility-model/ — AWS Shared Responsibility Model (EC2 documented as IaaS; guest OS remains the customer’s job)