Cloud Computing Concepts

Is a service "the cloud"? CCSP refuses to argue about marketing and grades the answer against one document: NIST Special Publication 800-145^[1]. It defines cloud computing as a model for enabling on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort. That single sentence carries the whole exam: a service counts as cloud only when it exhibits all five essential characteristics, and NIST then sorts cloud into three service models and four deployment models (both covered in the reference-architecture subtopic). Treat the five characteristics as a checklist, not a vibe: drop any one and the offering is hosting or managed IT, not cloud.

The five essential characteristics

Each characteristic is testable on its own, and questions love to describe a setup that is missing exactly one.

• On-demand self-service. The consumer provisions compute, storage, and other capabilities automatically, without requiring human interaction with the provider. The tell is the absence of a ticket or a phone call: you click or call an API and capacity appears.
• Broad network access. Capabilities are available over the network and accessed through standard mechanisms that work across heterogeneous clients (laptops, phones, thin clients). This is what makes the service reachable from anywhere, and also what enlarges the attack surface.
• Resource pooling. The provider's resources are pooled to serve multiple consumers using a multi-tenant model, with physical and virtual resources dynamically assigned and reassigned on demand. The consumer generally has no control or knowledge of the exact location of the resources. Pooling is the root of multi-tenancy, and therefore the root of every tenant-isolation concern later in the exam.
• Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward with demand. To the consumer the available capacity often appears unlimited and can be appropriated in any quantity at any time.
• Measured service. Resource usage is monitored, controlled, and reported, providing transparency for both provider and consumer. Metering is what turns capital expense into metered operating expense, and the usage logs it produces become audit and anomaly-detection data.

A useful exam habit: when a stem says "a customer must email the provider to add capacity," self-service fails; when it says "a fixed monthly fee regardless of use," measured service fails; when it says "dedicated hardware reserved for one customer," resource pooling fails. In each case the correct answer is that the service is not cloud by the NIST definition.

The five characteristics describe the technology; the cloud roles describe the people, and they exist so a question can ask "whose job is this?" and have one right answer. NIST SP 500-292^[2] and ISO/IEC 17788 name the actors a CCSP must place precisely.

The roles

• Cloud service customer (consumer). The organization or person that uses the cloud service. In NIST's vocabulary this is the cloud consumer; ISO calls it the cloud service customer. Treat the terms as the same role.
• Cloud service provider (CSP). The entity that makes the service available: it builds, operates, and secures the underlying infrastructure and platform.
• Cloud service partner. A party that supports the provider or customer, for example a developer building on the platform, a system integrator, or an independent cloud auditor who assesses controls.
• Cloud service broker. An intermediary that negotiates relationships and adds value (aggregation, integration, or customization) between consumers and providers, often without the consumer dealing with the provider directly.
• Cloud auditor / regulator. The auditor independently examines services and controls against a standard; a regulator imposes legal or sector rules the parties must meet. Both are oversight roles, not operators.

A recurring trap is to blur broker and partner. The broker is specifically the value-adding intermediary in the commercial relationship; the partner is the broader category of any supporting party, auditor included.

Roles drive the shared responsibility model

Naming the role is step one; the payoff is the shared responsibility model^[3], the principle that security duties are divided between provider and customer according to the service model. The rule to internalize: the provider always secures what is below the line, the customer always secures what is above it, and the line moves up the stack as you go IaaS to PaaS to SaaS. In IaaS the customer owns the OS, runtime, and data; in PaaS the provider also takes the OS and runtime, leaving the customer the application and data; in SaaS the provider runs almost everything and the customer is left mainly with data, identities, and access configuration. Two duties never transfer no matter the model: classifying and protecting your own data, and managing your own identities and access. An exam item that says "in SaaS the provider is responsible for everything" is wrong for exactly that reason.

The five characteristics are outcomes; this section is the machinery that produces them. CCSP groups the building blocks as virtualization, storage, networking, databases, and orchestration, and the exam expects you to connect each block to the characteristic it enables and the risk it introduces.

Virtualization

Virtualization is the foundation. A hypervisor abstracts one physical host into many isolated virtual machines (VMs), each believing it owns the hardware, which is exactly what makes resource pooling and elasticity possible. A Type 1 (bare-metal) hypervisor runs directly on the hardware and is what clouds use for tenant workloads; a Type 2 (hosted) hypervisor runs on top of a host OS and is a desktop or lab tool. Containers are the lighter sibling: they share the host's kernel and isolate at the OS level instead of emulating hardware, so they start in milliseconds and pack densely, at the cost of weaker isolation than a VM. The security headline for this whole block is the hypervisor as a high-value target: compromise it and you reach every tenant on the host, and a flaw that lets a tenant break out of its VM or container is a VM escape, the multi-tenancy nightmare.

Storage and networking

Cloud storage is software-defined: capacity is provisioned by API and presented as block volumes, object stores, or file shares, decoupled from any specific disk. Software-defined networking (SDN) does the same for connectivity, separating the control plane (which decides where traffic goes) from the data plane (which forwards it), so networks become programmable. Both are what let self-service and elasticity actually happen, because a human no longer racks a disk or patches a cable. The risk they add is that a single misconfigured API call (a storage bucket left public, a security-group rule opened to the internet) now exposes data at scale.

Databases and orchestration

Managed database services push patching, backup, and replication to the provider, trading some control for less operational burden, and they come in relational and non-relational (NoSQL) forms. Orchestration is the conductor: it automates provisioning, scaling, and teardown across all the other blocks, and in modern practice it is expressed as Infrastructure as Code (IaC), where the whole environment is defined in version-controlled templates. Orchestration is what makes "rapid, automatic" elasticity real. Its risk is concentration of power: whoever controls the orchestration or IaC pipeline can build or destroy the entire estate, so that pipeline becomes a prime target and a prime place for least-privilege and change control.

CCSP questions on this subtopic reward precise memory of NIST's vocabulary. A few recurring patterns cover most of them.

"Is this cloud?" stems

The stem describes a deployment and asks whether it qualifies as cloud computing, or which characteristic is missing. Map the scenario to the five: no API or portal to self-provision means on-demand self-service is absent; a flat monthly fee unrelated to usage means measured service is absent; hardware dedicated to one tenant means resource pooling is absent. The correct answer names the missing characteristic, or concludes "not cloud." The classic distractor offers a real-sounding sixth characteristic ("high availability," "automation") that is not one of NIST's five; reject it, because availability is a shared consideration, not an essential characteristic.

"Whose responsibility?" stems

The stem gives a service model and an incident (a leaked record, an unpatched OS) and asks who is accountable. Walk the shared responsibility line for that model: in IaaS the customer patches the OS, so an unpatched guest OS is the customer's fault; in SaaS the provider runs the platform, so a platform vulnerability is the provider's, but a misconfigured sharing setting or a weak user identity is still the customer's, because data and identity never transfer. The trap answer assigns data protection to the provider in SaaS; it is always the customer's.

Role-identification stems

The stem describes an actor and asks which cloud role it is. "Independently assesses the provider's controls" is the cloud auditor; "negotiates and bundles services between you and several providers" is the cloud broker; "uses the service to run its business" is the cloud customer/consumer. The distractor swaps broker for partner or auditor; keep broker pinned to the value-adding commercial intermediary.

Multi-tenancy and building-block stems

When a stem raises a noisy neighbor, data co-residency, or one tenant reaching another, trace it to resource pooling and its multi-tenant model, and the right control is tenant isolation. When it describes one tenant breaking out of its VM to the host or other tenants, that is a VM escape rooted in the hypervisor, the highest-value target in the virtualization block.