Cloud Reference Architecture
The NIST cloud definition and the three service models
A useful test of any 'cloud' claim: can a user provision it themselves, over the network, from a shared pool, scale it on demand, and see it metered? Those are the five essential characteristics in NIST SP 800-145[1], the document CCSP treats as the canonical cloud definition: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Miss one of the five and you have hosting, not cloud. These characteristics matter for security because each one introduces an exposure: self-service can spin up unmanaged resources, pooling means you share hardware with other tenants, and measured service means your bill is itself a signal an attacker can abuse.
The shared-responsibility stack
The single most testable idea on this page is that the service model fixes the customer/provider responsibility boundary. Think of one stack of layers running from the data center facility at the bottom up through hardware, virtualization, the guest operating system, middleware and runtime, and finally the application and its data. SP 800-145 names three service models by where the provider stops and the customer starts:
- IaaS (Infrastructure as a Service) delivers compute, storage, and networking as virtual resources. The provider runs the facility, hardware, and virtualization layer; the customer owns everything from the guest OS up, including OS patching, the runtime, the application, and the data.
- PaaS (Platform as a Service) delivers a managed runtime or application platform. The provider now also owns the OS and middleware; the customer is left with the application code, its configuration, and the data.
- SaaS (Software as a Service) delivers a finished application. The provider owns the entire stack up to and including the application; the customer configures only its own data, identities, and access settings.
The rule that falls out of this: as you move SaaS → PaaS → IaaS the customer's control and security burden grow, and the provider's shrink. The CSA shared-responsibility model[2] makes the same split explicit and adds the caveat the exam loves: responsibility shifts, but accountability never transfers. You can outsource the operation of a control to the provider, but you remain answerable to your regulator for the outcome.
Why the boundary drives every later control
When a CCSP question asks 'who is responsible for X', the answer is almost always 'find the layer X lives in, then read the service model'. OS hardening in SaaS is the provider's job; in IaaS it is yours. Data classification and access management are the customer's job in all three models, because data and identity sit at the top of the stack above every provider boundary. That is why data security (Domain 2) and IAM are framed as customer obligations regardless of model.
Deployment models and the multi-cloud strategy
Where the service model answers 'who runs which layer', the deployment model answers who you share the tenancy boundary with. NIST SP 800-145 names exactly four:
- Public cloud: infrastructure is open for use by the general public and owned by a cloud provider. Resources are pooled across unrelated tenants, so multi-tenancy isolation is the dominant security concern.
- Private cloud: provisioned for the exclusive use of a single organization. A common exam trap is that 'private' does not mean 'on-premises': a private cloud can be owned, managed, and operated by the organization, a third party, or both, and can be located on or off premises. What makes it private is single-tenancy, not where the hardware sits.
- Community cloud: shared by several organizations with a common concern, such as a shared mission, security requirement, or regulator. The classic example is a set of agencies under one compliance regime pooling a vetted environment to split cost.
- Hybrid cloud: two or more distinct deployment models (for example a private and a public cloud) bound together by technology that enables data and application portability, such as cloud bursting where a private workload spills into public capacity at peak.
Multi-cloud is a strategy, not a fifth model
Using more than one public provider at once is multi-cloud. The point to hold for the exam: multi-cloud is a deployment strategy layered on top of the four models, not a fifth NIST deployment model. Organizations adopt it to avoid dependence on a single provider, to place each workload on the provider whose service fits best, or to meet data-residency rules in regions one provider doesn't serve. The cost is real: you now must federate identity across providers, keep security policy consistent where each provider's controls differ, and solve interoperability between incompatible APIs. Those are the same shared considerations the next section covers, now multiplied by the number of providers.
Picking a deployment model
The decision usually turns on data sensitivity and tenancy tolerance. Sensitive or regulated data that cannot share hardware pushes toward private or community; bursty, public-facing scale pushes toward public; a mix of both is the canonical case for hybrid. The CSA guidance frames the choice as a risk decision, not a cost one: you accept multi-tenancy exposure in exchange for elasticity, or you pay for isolation when the data demands it.
Shared considerations: the lock-in and resilience trade study
Lead with the rule the exam keeps testing: interoperability, portability, and reversibility are the three knobs that decide how cheaply you can leave a provider, and confusing them is a classic distractor. They are easy to keep straight once you fix one definition each:
- Interoperability is the ability of systems to work together by speaking common standards and interfaces, so one provider's service can exchange data with another's without custom glue. It is about communication between systems while you stay.
- Portability is the ability to move a workload or its data from one environment to another and have it run with little or no rework. It is about relocating the workload itself. A workload built on open container images is portable; one built on a provider-proprietary database is not.
- Reversibility is the ability to retrieve all of your data and artifacts on exit and have the provider verifiably delete its copies. It is the clean-exit guarantee, and it is the one candidates forget exists as a distinct concept.
The relationship to watch: high interoperability and portability are what reduce vendor lock-in; low values of either are what cause it. SaaS typically has the highest lock-in because you can export data but not the application, while IaaS workloads packaged as portable images have the lowest.
The availability and governance considerations
The remaining shared considerations split into two groups the CCSP frames as the resilience promise and the assurance promise. Availability, resilience, and performance set what service level you can commit to, and they are pinned in the contract through the SLA (service level agreement): the SLA states the measurable target (uptime percentage, response time) and the remedy if it is missed. Security, privacy, governance, maintenance, and auditability decide whether the deployment is defensible: governance is the framework of policy and oversight, auditability is the ability to produce evidence a control operated, and privacy is the obligation specific to personal data. Every one of these applies across all service and deployment models, which is exactly why they are called shared considerations rather than features of one product.
When a question describes a workload and asks which considerations dominate, map them: a regulated data store stresses privacy, auditability, and governance; a customer-facing app stresses availability, performance, and the SLA; an exit clause in a contract stresses portability and reversibility.
Related technologies and DevSecOps
CCSP doesn't ask you to engineer these technologies; it asks you to place each one on the same reference architecture and read its security implication. The blueprint names a specific set, and each maps to a familiar concern rather than a new one:
- Containers package an application with its dependencies and share the host kernel, so the isolation boundary is the kernel, not a full hypervisor. Weaker isolation than a VM is the trade for density and portability, which is why portability and runtime hardening dominate the container discussion.
- Confidential computing protects data in use by running it inside a hardware-enforced trusted execution environment (enclave), closing the gap left by encryption that only covers data at rest and in transit. It is the answer when the threat model includes the cloud operator or the host OS itself.
- Edge computing pushes processing close to where data is produced (devices, sensors, branch sites) to cut latency, which widens the attack surface to many physically exposed nodes outside the data center.
- IoT (Internet of Things) devices are constrained endpoints that often ship with weak defaults; they are a supply and patching problem more than a compute one.
- AI / ML and data science introduce model and training-data integrity, data-poisoning, and privacy-of-training-data concerns on top of the normal application stack.
- Blockchain provides a distributed, tamper-evident ledger; its security value is integrity and non-repudiation, not confidentiality.
- Quantum computing is the forward-looking threat to current public-key cryptography, which is why post-quantum and crypto-agility appear in cloud roadmaps.
DevSecOps closes the loop
The practice that ties all of this back to the architecture is DevSecOps: it integrates security into the DevOps pipeline so controls are built in and tested continuously rather than bolted on after release. The CCSP framing is 'shift left', moving security checks earlier into design and build, with automated testing in the pipeline. It is not a technology on the list above; it is the delivery model that makes the controls for everything on the list repeatable and auditable. This is the bridge into Domain 4 (application security) and Domain 1's secure-design-principles subtopic, where threat modeling and the secure SDLC live in detail.
Cloud service models: where the customer/provider responsibility line sits
| Layer / aspect | IaaS | PaaS | SaaS |
|---|---|---|---|
| What the provider delivers | Virtual machines, storage, network | Runtime, OS, middleware platform | Complete application |
| Customer secures | OS, runtime, app, data, access | App code, data, access | Data and access configuration only |
| OS patching owner | Customer | Provider | Provider |
| Greatest customer control | Highest (full stack above hardware) | Medium (app and data) | Lowest (configuration only) |
| Lock-in / portability risk | Lower: workload is portable as VM images | Higher: tied to platform APIs | Highest: data export only, app is the provider's |
| Typical example | Compute and block-storage service | Managed app/database platform | Hosted email or CRM |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- The service model fixes the customer/provider responsibility line
Across the layered stack (facility, hardware, virtualization, OS, runtime/middleware, application, data), IaaS hands you the guest OS and everything above it; PaaS keeps the OS and runtime and leaves you the application and data; SaaS keeps the whole application and leaves you only data and access configuration. Moving SaaS to PaaS to IaaS increases your control and your security burden while the provider's shrinks. This boundary is what answers nearly every 'who is responsible for which layer' question, with the shared-responsibility principle from cloud-computing-concepts as its backdrop.
Trap Assuming the provider patches the guest OS in IaaS; in IaaS the customer owns the OS and up, so OS patching is the customer's job.
3 questions test this
- An organization uses IaaS for compute resources, PaaS for application hosting, and SaaS for email services. Regarding network security…
- An organization is migrating workloads to a PaaS environment for application development. Which security control responsibility shifts from…
- An organization is migrating applications to a public cloud using IaaS virtual machines. According to the shared responsibility model,…
- There are exactly three service models: SaaS, PaaS, IaaS
NIST SP 800-145 names three and only three service models. Newer 'as-a-service' marketing terms (FaaS for functions, DBaaS for databases, and so on) are subsets or refinements that the exam still slots under one of the three canonical models, usually PaaS. When asked to classify a managed runtime or function platform, place it in the closest NIST model rather than treating the marketing label as a fourth category.
- Drop to PaaS or IaaS when a control needs OS-level access
Pick the highest service-model abstraction that still lets you meet your control obligations: SaaS minimizes operational burden but the provider owns the OS, kernel, and host network. When a requirement forces you to touch the operating system, kernel modules, or host stack, SaaS cannot satisfy it, so move down to PaaS or IaaS where the responsibility line sits below your requirement. The choice is driven by the lowest layer you must control, not by cost alone.
- There are four NIST deployment models: public, private, community, hybrid
Public cloud pools resources across unrelated tenants on provider infrastructure; private cloud is provisioned for a single organization; community cloud is shared by organizations with a common concern such as a shared regulator or mission; hybrid binds two or more of these with technology that lets data and applications move between them. The deployment model answers who you share the tenancy boundary with, which is a different axis from the service model's responsibility line.
- Private cloud means single-tenant, not on-premises
A private cloud is defined by exclusive use by one organization, and it can be owned, managed, or operated by that organization, a third party, or both, located on or off premises. What makes it private is single-tenancy and the isolation that buys, not the physical location of the hardware. A provider-hosted environment dedicated to one customer is still a private cloud.
Trap Equating private cloud with on-premises data centers; a third-party-hosted single-tenant environment is also a private cloud.
5 questions test this
- A government agency requires strict data sovereignty controls ensuring that sensitive citizen data remains within national boundaries and…
- A security architect is evaluating the shared responsibility model implications for different cloud deployment models. In which deployment…
- When selecting a cloud deployment model, an organization must balance flexibility, security, scalability, and cost. Which factor is the…
- A financial services company requires maximum control over physical infrastructure, dedicated computing resources, and the ability to…
- A government agency requires complete ownership of all governing security controls and must ensure classified data never leaves specific…
Community cloud is provisioned for exclusive use by a specific community of organizations that share a concern such as a mission, security requirement, policy, or compliance regime. The textbook example is a group of agencies under one regulator pooling a vetted environment to share both cost and a common control baseline. It sits between public (any tenant) and private (one tenant) on the tenancy axis.
3 questions test this
- A consortium of regional healthcare providers wants to share infrastructure while maintaining strict HIPAA compliance. All members have…
- A financial services organization wants to migrate to the cloud but requires that all tenants sharing the infrastructure have identical PCI…
- A financial services company wants to use cloud computing but must share infrastructure costs with other organizations while ensuring all…
- Hybrid cloud binds models together for data and app portability
Hybrid is two or more distinct deployment models joined by technology that enables data and application portability between them, the classic case being cloud bursting where a private workload spills into public capacity at peak. It is the standard answer when regulated or sensitive data must stay private while the rest of a workload needs public elasticity. The defining feature is the binding that lets work move across the boundary, not merely owning both a private and a public environment.
- Multi-cloud is a strategy, not a fifth NIST deployment model
Using several public cloud providers at once is multi-cloud, a deployment strategy layered over the four NIST models rather than a model itself. Organizations adopt it to avoid single-provider dependency, to place each workload on its best-fit provider, or to meet data-residency needs, and they pay for it with extra identity federation, consistent-policy, and interoperability work across providers. Do not force multi-cloud into the public/private/hybrid/community taxonomy on the exam.
Trap Listing multi-cloud as one of the NIST deployment models; the four NIST models are public, private, community, and hybrid only.
- Interoperability is systems working together, portability is moving the workload
Interoperability is the ability of systems to exchange data and work together through common standards while you stay on a provider; portability is the ability to move a workload or its data to another environment and run it with little rework. They are different knobs: open APIs give interoperability, open formats and container images give portability. High values of both are what reduce vendor lock-in.
Trap Using interoperability and portability interchangeably; interoperability is communicating between systems, portability is relocating the workload itself.
- Reversibility is the verified clean-exit guarantee
Reversibility is the ability to retrieve all of your data and artifacts when leaving a provider and to have the provider verifiably delete its copies, so you can exit cleanly. It is a distinct shared consideration from portability: portability is whether the workload can run elsewhere, reversibility is whether you can fully extract and confirm deletion on the way out. Candidates most often forget reversibility exists as its own concept, so the exit clause in a contract is testing it.
- SaaS carries the highest lock-in, portable IaaS images the lowest
Lock-in tracks how much of the stack you can take with you. SaaS is highest because you can export your data but not the provider's application; PaaS is in the middle because your code is tied to platform-specific APIs; IaaS workloads packaged as portable VM or container images are lowest because the whole unit relocates. Interoperability and portability are the two considerations you assess up front to keep that lock-in manageable.
- SLAs make availability, performance, and remedies contractually measurable
Availability, resilience, and performance are shared considerations that set what service level you can commit to, and the service level agreement is where they become enforceable: it states the measurable target such as uptime percentage or response time and the remedy if it is missed. An SLA without a defined remedy or measurement method is not enforceable, so the exam treats the metric plus the consequence as the substance of the SLA.
- Governance and auditability decide whether a deployment is defensible
Security, privacy, governance, maintenance, and auditability are the shared considerations that make a deployment defensible to an auditor: governance is the policy and oversight framework, auditability is the ability to produce evidence that a control operated, and privacy is the obligation specific to personal data. These apply across every service and deployment model, which is exactly why NIST calls them shared considerations rather than features of one product.
- Confidential computing protects data in use inside an enclave
Confidential computing runs sensitive workloads inside a hardware-enforced trusted execution environment, or enclave, so data is protected while in use, closing the gap left by encryption that only covers data at rest and in transit. It is the control to reach for when the threat model includes the cloud operator, the host OS, or another tenant on the same hardware. The protected state it adds is in use, the one the traditional two states miss.
Trap Reaching for at-rest or in-transit encryption when the requirement is to protect data while it is being processed; that needs confidential computing's in-use protection.
- Edge computing trades latency for a wider physical attack surface
Edge computing pushes processing close to where data is produced, at devices, sensors, or branch sites, to cut latency and bandwidth back to a central cloud. The security cost is that compute now lives on many nodes outside the protected data center, often physically accessible, which widens the attack surface and complicates patching and monitoring. Treat each edge node as an exposed endpoint rather than as a trusted data-center server.
- Blockchain provides integrity and non-repudiation, not confidentiality
A blockchain is a distributed, tamper-evident ledger whose security value is integrity and non-repudiation: entries are chained and hard to alter without detection. It does not by itself provide confidentiality, since the ledger is typically shared and visible to participants. When a question frames blockchain as a confidentiality control it is steering you wrong; its strength is verifiable, append-only history.
Trap Selecting blockchain to keep data secret; a shared ledger gives integrity and non-repudiation, not confidentiality.
- Quantum computing is the forward-looking threat to current public-key crypto
Large-scale quantum computers threaten today's public-key algorithms such as RSA and elliptic-curve, which is why cloud security roadmaps track post-quantum cryptography and crypto-agility (the ability to swap algorithms without re-architecting). The exam treats quantum as a future risk that motivates planning for algorithm migration now, not as a present-day operational control you deploy today.
- The cloud carrier's role stays connectivity-and-transport across service models
In the NIST cloud computing reference architecture (SP 500-292) the cloud carrier is defined as the intermediary that provides connectivity and transport of cloud services between consumer and provider. Because its job is the network path rather than the application stack, its core responsibility (and the security concern that follows, protecting data in transit, e.g. via dedicated, encrypted connections per the SLA) stays the same whether the workload is IaaS, PaaS, or SaaS, whereas the consumer's and provider's responsibilities shift with the service model.
Trap Assuming the cloud provider or broker is model-independent because it 'always' operates the platform; the provider's duties expand or shrink as you move down the stack.
3 questions test this
- In the NIST Cloud Computing Reference Architecture, which actor's security responsibilities remain unchanged regardless of the service…
- In the NIST Cloud Computing Reference Architecture, which actor's security responsibilities remain unchanged regardless of whether the…
- Your organization is deploying services across multiple cloud providers. According to NIST SP 500-292, which actor's security…
- Broker arbitrage picks providers dynamically; aggregation combines fixed ones
NIST SP 500-292 splits cloud broker services into three categories: service intermediation (the broker enhances a single service), service aggregation (it combines and integrates multiple fixed services into a new one with secure data movement), and service arbitrage (like aggregation but the underlying services are not fixed, so the broker can dynamically choose providers on price or performance).
Trap Calling dynamic, criteria-driven provider selection 'aggregation'; in aggregation the chosen services are fixed, arbitrage is the one that swaps them on the fly.
5 questions test this
- A cloud service broker is assisting an enterprise client in dynamically selecting the most cost-effective cloud provider for each workload…
- A cloud service customer wants to leverage multiple cloud providers while maintaining flexibility to switch services based on real-time…
- According to the NIST Cloud Computing Reference Architecture, which category of Cloud Service Broker services is responsible for combining…
- A cloud service broker provides services to multiple customers and wants to dynamically select cloud providers based on real-time…
- According to the NIST Cloud Computing Reference Architecture, a cloud service customer requires services from multiple cloud service…