Cloud computing is the delivery of computing services — servers, storage, databases, networking, software, analytics, and intelligence — over the internet, on demand, with pay-as-you-go pricing. Rather than owning and maintaining physical data centers and servers, organizations can access computing resources as a utility, the same way they consume electricity or water: use what you need, pay for what you use, and scale up or down as demand changes.
For the A+ technician, cloud computing knowledge matters in two contexts. First, many of the systems and applications that users need support on are now cloud-hosted — understanding the cloud model explains behaviors and constraints that don't exist with on-premises software. Second, cloud concepts are directly tested on the exam and increasingly appear in troubleshooting scenarios.
NIST Definition
The National Institute of Standards and Technology (NIST) defines cloud computing as a model that enables ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. This definition underpins the five essential characteristics the A+ exam tests.
Before examining individual models and characteristics, it helps to understand why organizations move to the cloud in the first place. The core trade-off is simple: cloud computing converts capital expenditure (CapEx) — buying and owning servers, storage, and networking equipment — into operational expenditure (OpEx) — paying a monthly or hourly subscription for services. This shifts IT infrastructure from an asset that must be purchased, maintained, and eventually replaced to a service that scales with the business's actual needs.
A cloud deployment model describes who owns the cloud infrastructure, who has access to it, and where it is physically located. The four deployment models represent different points on a spectrum from fully private (owned and operated by one organization) to fully public (owned and operated by a third-party provider, shared by everyone).
Definition: Cloud infrastructure provisioned for exclusive use by a single organization. May be owned and managed by the organization itself, or hosted by a third party — but access is restricted to that one organization.
Location: On-premises in the organization's own data center, or off-premises in a colocation facility or managed by a third party.
Who uses it: Government agencies, financial institutions, healthcare organizations — any entity with strict regulatory, compliance, or security requirements that prevent using shared infrastructure.
Key trade-off: Maximum control and security, but requires the organization to staff, manage, and fund the infrastructure — no CapEx savings.
Examples: VMware Private Cloud, OpenStack-based private cloud, Microsoft Azure Stack.
Definition: Cloud infrastructure owned and operated by a third-party cloud provider and shared among multiple customers (tenants). The customer has no ownership of the underlying hardware.
Location: Provider's data centers, distributed globally. Customer has no visibility into or control over physical infrastructure.
Who uses it: Organizations of all sizes — from individual developers to Fortune 500 companies — for virtually all use cases that don't have strict regulatory prohibitions on shared infrastructure.
Key trade-off: Maximum scalability and lowest upfront cost, but less control; compliance limitations for some regulated data types.
Examples: Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP).
Definition: A combination of private cloud and public cloud environments that are interconnected and allow data and applications to move between them. Organizations maintain some workloads on private infrastructure while using public cloud for others.
Key use cases: Cloud bursting (run normal workloads on-premises; automatically expand to public cloud during demand spikes); keeping sensitive data on private cloud while running less-sensitive apps in public cloud; gradual cloud migration while maintaining on-premises systems.
Key trade-off: Best of both worlds in theory, but complex to manage — requires integration layer, consistent identity management, and network connectivity between environments.
Examples: AWS Outposts, Azure Arc, VMware Cloud on AWS.
Definition: Cloud infrastructure shared by a specific group of organizations that have common concerns — such as a shared mission, security requirements, policy, or compliance framework. More exclusive than public cloud but shared among multiple organizations.
Who uses it: Government agencies sharing cloud services for a specific purpose; healthcare providers sharing HIPAA-compliant infrastructure; universities sharing research computing resources; financial institutions sharing regulatory-compliant platforms.
Key trade-off: Cost sharing reduces individual burden compared to private cloud; shared infrastructure is purpose-built for the community's specific requirements. Less flexible than public cloud.
Examples: US Government FedRAMP-authorized clouds; AWS GovCloud; Azure Government.
Exam Focus — Deployment Models
Know all four deployment models and their distinguishing characteristics. The most commonly tested scenarios: Private = exclusive to one org, maximum control, on-premises or hosted. Public = shared infrastructure, third-party owned, AWS/Azure/GCP. Hybrid = mix of private and public, allows workload flexibility. Community = shared by organizations with common requirements (government, healthcare).
Cloud service models describe what the cloud provider delivers to the customer — and, critically, what the customer is responsible for managing themselves. Each model represents a different point on the spectrum of managed services, from "we give you raw computing hardware" to "we give you a finished, ready-to-use application."
The most useful mental model is the pizza analogy: on-premises is cooking everything from scratch at home; IaaS is buying ingredients from the store (provider gives you raw materials); PaaS is getting a partially made pizza you finish yourself; SaaS is ordering delivery — the whole pizza arrives ready to eat.
IaaS is the most fundamental cloud service model. The provider delivers virtualized computing resources — virtual machines, virtual storage (block storage, object storage), and virtual networking (VPCs, subnets, load balancers) — over the internet. The customer rents these raw infrastructure components and is responsible for everything that runs on top of them.
Think of IaaS as renting a server rack in someone else's data center, but with the ability to provision new servers in minutes and pay by the hour. The physical hardware, data center facilities, and hypervisor are all managed by the provider. Everything above the hypervisor — the OS, the applications, the data, the security configuration — is the customer's responsibility.
PaaS abstracts the infrastructure one level further. The provider manages not just the hardware but also the OS, runtime environment, and middleware. The customer focuses exclusively on writing and deploying their application code — they don't manage servers, patch operating systems, or configure web server software.
A developer using Heroku or Azure App Service simply pushes their application code to the platform. The platform automatically provisions servers, installs the required runtime (Python, Node.js, Java, etc.), scales the application based on demand, and handles load balancing. The developer never touches a server.
PaaS in Practice
PaaS dramatically accelerates application development. A small startup can deploy a full production web application in minutes without hiring a DevOps engineer to manage infrastructure. The trade-off is less control — the customer cannot configure the OS, choose the exact database version, or customize the server environment beyond what the platform allows.
SaaS is the highest-level cloud service model. The provider delivers a complete, fully functional application — the infrastructure, platform, and software are all managed by the provider. The customer simply logs in and uses the application. There is nothing to install, no servers to manage, and no software to update.
SaaS is what most end users interact with daily, even if they don't use the term. Microsoft 365 (Word, Excel, Teams, Exchange Online), Google Workspace (Gmail, Drive, Docs), Salesforce (CRM), Zoom (video conferencing), and Slack (team messaging) are all SaaS products. The customer's only responsibility is managing their users, their data, and their access settings — the application itself is entirely the provider's problem.
| Component | On-Premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Application | Customer | Customer | Customer | Provider |
| Data | Customer | Customer | Customer | Shared |
| Runtime / Middleware | Customer | Customer | Provider | Provider |
| Operating System | Customer | Customer | Provider | Provider |
| Virtualization / Hypervisor | Customer | Provider | Provider | Provider |
| Physical Servers / Storage | Customer | Provider | Provider | Provider |
| Data Center / Networking | Customer | Provider | Provider | Provider |
Exam Focus — Service Models
This is one of the most tested cloud topics. Key facts: IaaS = raw VMs and storage; customer manages OS and everything above it. PaaS = platform for developers; provider manages OS and runtime; customer manages app and data only. SaaS = complete ready-to-use application; customer only manages data and users. The shared responsibility table is the most practically useful mental model for exam scenarios.
The A+ acronym list includes FaaS (Function as a Service), a newer model beyond IaaS/PaaS/SaaS. FaaS (also called serverless computing) allows developers to run individual functions or code snippets in response to events — the provider manages everything including servers, OS, and scaling. The customer pays only for the actual execution time of their function, measured in milliseconds. Examples include AWS Lambda, Google Cloud Functions, and Azure Functions. FaaS is not a primary A+ exam topic but may appear in the acronym list questions.
Beyond deployment and service models, the A+ exam tests specific characteristics that define how cloud computing works and distinguish it from traditional on-premises IT. These characteristics are not just abstract features — they have direct operational implications for how cloud services behave, how they are billed, and why organizations choose them.
One of the most fundamental concepts in cloud computing is the question of whether customers share the underlying hardware with others or have it exclusively to themselves.
The Noisy Neighbor Problem
In shared infrastructure, a tenant running an extremely resource-intensive workload (a cryptomining operation, a massive database query, or a DDoS attack being repelled) can consume disproportionate shared resources — CPU, network I/O, storage I/O — causing performance degradation for other tenants on the same physical host. Cloud providers implement resource limits (cgroups, network throttles) to mitigate this, but dedicated resources eliminate it entirely.
Metered utilization (also called measured service) means cloud resources are monitored, measured, and billed based on actual consumption — like a utility meter on a water or electricity supply. You pay for exactly what you use, not for a fixed capacity allocation.
Different cloud services meter different dimensions of usage:
Ingress and egress are critical billing terms that every cloud practitioner must understand — and they are explicitly listed in the A+ exam objectives.
Exam Focus — Ingress vs. Egress
Ingress = data going IN to the cloud = typically free. Egress = data going OUT of the cloud = charged per GB. This is a specific exam topic. Remember: data uploads are free; data downloads are billed. The asymmetry exists because cloud providers make it easy and cheap to move data in but expensive to move it out — encouraging customers to keep their data in the provider's ecosystem.
Elasticity is the ability of a cloud environment to automatically or rapidly scale resources up or down based on workload demand — and to do so quickly enough to match real-time fluctuations. Elasticity is distinct from scalability: scalability means you can add more capacity; elasticity means the system adds or removes capacity automatically in response to demand without human intervention.
The canonical example is a retail website during Black Friday. Traffic might be 100× normal volume for a few hours and then drop back to normal. In a traditional on-premises environment, the organization must provision enough servers for the peak load — servers that sit idle 99% of the year. With elastic cloud infrastructure, the platform automatically provisions additional VMs when traffic spikes and terminates them when traffic subsides, paying only for the hours of peak capacity actually used.
Elasticity vs. Scalability — The Distinction
These terms are related but not identical. Scalability means the system can handle increased load — either by adding resources (scale out) or upgrading resources (scale up). Elasticity adds the dimension of automation and speed — the system automatically adapts to demand changes in real time without manual intervention, and can scale back down as well as up. All elastic systems are scalable, but not all scalable systems are elastic.
Availability refers to the percentage of time a cloud service is operational and accessible. Cloud providers express availability commitments in Service Level Agreements (SLAs) — contractual guarantees of uptime, typically expressed as a percentage.
| SLA Uptime | Annual Downtime Allowed | Monthly Downtime | Context |
|---|---|---|---|
| 99% ("two nines") | 87.6 hours / year | 7.2 hours | Rarely sufficient for production services |
| 99.9% ("three nines") | 8.76 hours / year | 43.8 minutes | Minimum for most business applications |
| 99.95% | 4.38 hours / year | 21.9 minutes | Common for managed cloud services (AWS RDS, etc.) |
| 99.99% ("four nines") | 52.6 minutes / year | 4.38 minutes | High availability; requires multi-AZ deployment |
| 99.999% ("five nines") | 5.26 minutes / year | 26 seconds | Mission-critical systems; very expensive to achieve |
Cloud availability is achieved through redundancy at multiple levels: multiple power feeds and UPS systems in data centers, redundant network connections, data replicated across multiple physical servers (Availability Zones — physically separate data center buildings within one geographic region), and cross-region replication for truly global high availability.
File synchronization is one of the most practically visible cloud characteristics for end users — it is the mechanism that keeps files consistent and up to date across multiple devices and with the cloud storage repository. When a user modifies a file on their laptop, file sync ensures the updated version appears on their desktop, phone, and tablet within seconds, without any manual transfer.
A sync client runs on each device, monitoring a designated local folder. When a file changes, the client uploads the delta (changed blocks, not the whole file) to the cloud. The cloud notifies all other devices, which download the changes. Conflicts (two devices editing the same file simultaneously) are resolved by creating conflict copies.
File synchronization services that A+ technicians commonly support include:
Troubleshooting File Sync Issues
Common file sync issues an A+ technician encounters: Sync not completing — check internet connectivity, verify the sync client is running, check storage quota (full cloud storage stops sync). Files not updating — restart the sync client, check for paused sync, verify the device is online. Selective sync — most sync clients allow syncing only specific folders to save local disk space; confirm the expected folders are included. Conflict copies — when two devices edit the same file offline, the sync client creates conflict copies to prevent data loss; user must manually reconcile.
Multitenancy is the architectural model in which a single instance of software or infrastructure serves multiple customers (tenants) simultaneously, with each tenant's data and configuration isolated from all others. It is the foundational model that makes public cloud economically viable.
In a multitenant architecture, the same physical servers, the same hypervisor software, and often the same application code serve hundreds or thousands of different customers at once. From each customer's perspective, they appear to have dedicated resources — their own virtual machines, their own storage, their own application instances — but the underlying infrastructure is shared.
Multitenancy and Security
Multitenancy is one of the primary security concerns in cloud computing. The question is always: how confident can you be that the isolation mechanisms between tenants are unbreakable? For most workloads, hypervisor isolation is considered sufficient. For highly sensitive workloads (classified government data, healthcare records, financial transaction processing), organizations may require dedicated infrastructure or private cloud deployments specifically because they cannot rely on multitenant isolation.
NIST's formal definition of cloud computing identifies five essential characteristics that, taken together, distinguish cloud computing from traditional hosting or on-premises IT. The A+ exam may test these both explicitly and implicitly through scenario questions.
| Characteristic | Definition | Example |
|---|---|---|
| On-demand self-service | A customer can provision computing resources (VMs, storage, bandwidth) automatically, without requiring human interaction with the service provider | Logging into AWS console and spinning up a VM in 3 minutes with no phone calls to AWS |
| Broad network access | Capabilities are available over the network and accessible through standard mechanisms — accessible from laptops, tablets, smartphones, and workstations | Accessing Office 365 from a browser on any internet-connected device worldwide |
| Resource pooling | The provider's computing resources are pooled to serve multiple consumers (multitenancy), with different physical and virtual resources dynamically assigned based on demand | AWS EC2 instances from many customers running on shared physical servers with hypervisor isolation |
| Rapid elasticity | Capabilities can be elastically provisioned and released — in some cases automatically — to scale rapidly outward and inward commensurate with demand | Auto-scaling group adding 20 web servers in response to a traffic spike, then terminating them 2 hours later |
| Measured service | Cloud systems automatically control and optimize resource use by leveraging a metering capability; resource usage is monitored, controlled, and reported — providing transparency for both the provider and consumer | AWS billing dashboard showing exact CPU-hours, GB-months of storage, and GB of data transfer, billed to the cent |
Final Exam Reminders
IaaS = virtual servers and storage; you manage the OS. PaaS = managed platform; you deploy your app. SaaS = finished application; you just use it.
Private = one org only. Public = shared/AWS/Azure. Hybrid = both. Community = shared by orgs with common requirements (government, healthcare).
Ingress = IN = FREE. Egress = OUT = CHARGED. This is the single most commonly missed billing concept on the exam.
Elasticity = auto-scaling up AND down based on demand. A traffic spike that automatically adds servers and then releases them = elasticity.
Multitenancy = multiple customers share the same infrastructure with logical isolation. The opposite is dedicated/single-tenant.
Metered utilization = pay-as-you-go; pay only for what you consume; like a utility bill.
Availability = SLA uptime percentage. 99.99% = "four nines" = only 52 minutes downtime allowed per year.
File sync conflict = two devices edit same file offline → sync client creates conflict copy → user must resolve manually.