2.2 Cloud Reference Architecture (Domain 1.2)
Key Takeaways
- Cloud reference architecture describes activities, service capabilities (application, platform, infrastructure), service categories (SaaS, PaaS, IaaS), and deployment models (public, private, hybrid, community, multi-cloud).
- Shared responsibility shifts by category: customers own more of the stack in IaaS and less in SaaS, but always retain accountability for data, identity decisions, and acceptable use.
- Shared considerations — interoperability, portability, reversibility, availability, security, privacy, resiliency, performance, governance, SLAs, auditability, regulatory alignment, and outsourcing — drive architecture and contract design.
- Related technologies (data science, ML/AI, blockchain, IoT, containers, quantum, edge, confidential computing) change threat models and control placement without replacing core cloud concepts.
- CCSP items often hide the correct answer in the deployment model or service category; identify those first, then apply shared responsibility.
Cloud Reference Architecture
If Domain 1.1 is vocabulary, Domain 1.2 is the map. A cloud reference architecture organizes how services are described, delivered, consumed, and governed so security professionals can reason consistently across vendors. CCSP expects vendor-neutral fluency: the same patterns apply whether the provider is a hyperscaler, a regional CSP, or an internal private-cloud platform team.
Cloud Computing Activities
Reference models (ISO/IEC 17789-style activity views and CSA architectural thinking) group work into activities such as:
| Activity cluster | Examples |
|---|---|
| Prepare / plan | Strategy, architecture selection, risk assessment, classification |
| Provide / enable | Service deployment, capacity, metering, support |
| Consume / use | Provisioning, configuration, application operation, data handling |
| Administer / govern | Identity administration, policy, compliance, audit, cost control |
| Secure / protect | Preventive, detective, and corrective controls across layers |
| Exit / reverse | Data extraction, contract wind-down, secure decommission |
Security is not a single activity at the end — it threads prepare through exit. Exam scenarios that describe a “lift-and-shift with no exit plan” fail reversibility even if day-one encryption looks fine.
Cloud Service Capabilities
Capability types describe what the service offers, independent of marketing labels:
| Capability type | Focus | Typical consumer concern |
|---|---|---|
| Application capabilities | End-user or business applications delivered as services | Feature fit, data residency in the app, identity integration, SaaS configuration security |
| Platform capabilities | Middleware, runtimes, managed data platforms, development services | Secure SDLC, language/runtime patching boundaries, platform IAM, secret injection |
| Infrastructure capabilities | Compute, storage, network as services | OS/image hardening (when customer-managed), network segmentation, encryption, key custody |
A single product may expose multiple capability types (for example, a managed Kubernetes service mixes platform orchestration with infrastructure nodes). Classify by what you control, not by the product name.
Cloud Service Categories: SaaS, PaaS, IaaS
Service categories are the exam’s primary lever for shared responsibility.
| Category | Customer typically manages | CSP typically manages | Residual customer accountability |
|---|---|---|---|
| IaaS | OS (if not managed), middleware, runtime, apps, data, network config in the tenant, identities | Hypervisor/host, physical network/storage/compute, facilities | Data classification, access, encryption choices, secure images, monitoring of tenant resources |
| PaaS | Applications, data, identity integration, some config | Runtime, middleware, OS, underlying infrastructure | App security, secrets, data protection, least-privilege roles on the platform |
| SaaS | User access, data entered into the app, configuration/settings, some integrations | Nearly entire stack including application code | Account hygiene, data governance, third-party app grants, retention settings |
Exam scenario pattern: “Who patches the guest OS?” → IaaS customer (unless a managed-OS offering explicitly shifts it). “Who patches the SaaS application code?” → CSP. “Who decides whether exports of customer PII are allowed?” → customer, in every category. Accountability for regulatory outcomes stays with the customer organization even when responsibility for a control is contractually assigned to the CSP.
Shared-responsibility diagram in words: as you move from IaaS → PaaS → SaaS, the CSP’s responsibility boundary moves up the stack. Misconfigurations at the customer layer remain the #1 breach pattern across all three.
Cloud Deployment Models
| Model | Definition | Security notes |
|---|---|---|
| Public | Multi-tenant services offered over the public network to many customers | Strong isolation expectations; region/sovereignty choices; broad shared infrastructure |
| Private | Cloud used exclusively by one organization (on-prem or hosted) | Greater control and customization; customer often bears more operational security burden |
| Hybrid | Composition of two or more distinct infrastructures (e.g., private + public) bound by technology enabling data/app portability | Identity federation, consistent policy, secure connectivity, and data-flow mapping are critical |
| Community | Shared by organizations with common concerns (sector, compliance, mission) | Shared governance model; peer risk; common baseline controls |
| Multi-cloud | Deliberate use of two or more public CSPs (or major platforms) | Reduces single-vendor concentration; increases identity, logging, and skill-complexity risk |
Multi-cloud vs hybrid: Hybrid mixes deployment environments (often private + public). Multi-cloud multiplies providers. An enterprise can be both. CCSP likes questions that force this distinction.
Worked example: A bank keeps core ledgers in a private cloud, bursts analytics to a public CSP (hybrid), and uses a second CSP for SaaS collaboration (multi-cloud). Security design must unify identity, classify data before it leaves the private boundary, and align SLAs across providers — not apply a single public-cloud playbook everywhere.
Cloud Shared Considerations
These cross-cutting concerns appear in design reviews, RFPs, and exam stems. Treat them as a checklist.
| Consideration | What good looks like |
|---|---|
| Interoperability | Systems exchange data/services using open or well-documented interfaces |
| Portability | Workloads and data can move between environments with acceptable rework |
| Reversibility | Customer can retrieve data and unwind the service relationship cleanly |
| Availability | Agreed uptime, multi-AZ/region options, graceful degradation |
| Security | Controls matching data sensitivity and threat model; continuous assurance |
| Privacy | Lawful processing, minimization, subject rights support, residency |
| Resiliency | Absorb faults; recover within recovery time/point objectives |
| Performance | Latency, throughput, and scalability meeting business needs |
| Governance | Policies, roles, decision rights, and oversight for cloud use |
| Maintenance and versioning | Change windows, deprecation notice, backward compatibility |
| Service levels / SLAs | Measurable commitments, credits, exclusions, reporting |
| Auditability | Logs, evidence, right-to-audit or third-party reports (SOC, ISO) |
| Regulatory | Sector and jurisdictional requirements mapped to control ownership |
| Outsourcing | Concentration risk, subcontractors (fourth parties), exit clauses |
Vendor lock-in is the dark side of weak portability and interoperability. Mitigations include open formats, infrastructure as code with abstracted modules, data export drills, and multi-cloud readiness for critical paths — not superstition that multi-cloud magically eliminates all dependency.
SLA exam tip: An SLA is a business commitment, not a security control by itself. Credits rarely equal breach cost. Read exclusions (force majeure, customer misconfiguration) and pair SLAs with technical resiliency and insurance/risk treatment.
Impact of Related Technologies
Modern cloud estates rarely stop at VMs and object storage. The outline highlights technologies that reshape architecture and risk:
| Technology | Cloud impact | Security focus |
|---|---|---|
| Data science platforms | Large-scale pipelines and feature stores on cloud data lakes | Data classification, lineage, access to training sets, exfiltration via notebooks |
| Machine learning / AI | Training and inference as managed services | Model/data poisoning, prompt injection (for genAI apps), secret leakage in logs, GPU multi-tenancy |
| Blockchain | Distributed ledgers sometimes hosted on cloud nodes | Key custody for wallets, smart-contract flaws, immutability vs right-to-erasure tension |
| Internet of Things (IoT) | Massive device fleets phoning home to cloud hubs | Device identity, firmware integrity, edge-to-cloud TLS, topic-level authorization |
| Containers | Dense packaging and rapid deploy on shared hosts | Image provenance, runtime isolation, orchestrator RBAC, secrets injection |
| Quantum computing | Emerging cloud-accessible quantum processors | Crypto-agility planning; harvest-now-decrypt-later risk for long-lived secrets |
| Edge computing | Processing near users/devices, often CSP-managed edge locations | Physical exposure, intermittent connectivity, consistent policy to core cloud |
| Confidential computing | Hardware-backed trusted execution environments (TEEs) protecting data in use | Attestation, enclave lifecycle, residual side-channel and supply-chain trust |
None of these replace the reference architecture — they layer onto capability types and categories. Example: a containerized ML inference service on a public PaaS still requires you to name the deployment model, identify SaaS/PaaS/IaaS boundaries for each dependency, and apply shared considerations (privacy for training data, auditability of model changes, SLA for inference latency).
Exam Approach for Reference Architecture Items
- Label service category and deployment model from the stem.
- List who is customer vs CSP vs partner/broker.
- Apply shared responsibility for the control named (patching, encryption, logging, physical security).
- Check shared considerations the design ignored (especially reversibility, auditability, residency).
- If a related technology is present, adjust the threat model without abandoning core cloud controls.
Common Traps
- Calling every hosted application “SaaS” when the customer still manages OS and runtime (that is closer to IaaS/PaaS).
- Assuming private cloud removes multi-tenancy risk entirely (business units can still be tenants of a shared internal platform).
- Treating multi-cloud as inherently more secure rather than a complexity trade-off.
- Confusing SLA credits with residual risk acceptance.
In a pure SaaS collaboration suite, which responsibility almost always remains with the cloud service customer?
An enterprise runs regulated systems in its private cloud, bursts seasonal analytics to one public CSP, and uses a different public CSP for email. Which deployment description is most accurate?
Which shared consideration is primarily about the customer’s ability to retrieve data and cleanly end a cloud relationship?
Confidential computing most directly aims to protect which data state that traditional encryption at rest and in transit leaves exposed?