2.2 Cloud Reference Architecture (Domain 1.2)

Certified Cloud Security Professional CCSP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current CCSP Exam Facts 1.2 CAT Format, Scoring & Logistics 1.3 Eligibility, Experience & Certification Maintenance

2 Domain 1: Cloud Concepts & Architecture Foundations

2.1 Cloud Computing Concepts (Domain 1.1) 2.2 Cloud Reference Architecture (Domain 1.2) 2.3 Security Concepts Relevant to Cloud (Domain 1.3)

3 Domain 1: Secure Design, CSP Evaluation & AI/ML

3.1 Design Principles of Secure Cloud Computing (Domain 1.4) 3.2 Evaluate Cloud Service Providers (Domain 1.5) 3.3 AI/ML in Cloud Security (Domain 1.6)

4 Domain 2: Data Concepts, Storage & Protection Technologies

4.1 Cloud Data Concepts (Domain 2.1) 4.2 Cloud Data Storage Architectures (Domain 2.2) 4.3 Data Security Technologies & Strategies (Domain 2.3)

5 Domain 2: Discovery, Classification & Information Rights Management

5.1 Data Discovery (Domain 2.4) 5.2 Data Classification (Domain 2.5) 5.3 Information Rights Management (Domain 2.6)

6 Domain 2: Retention, Auditability & AI/ML Data Protection

6.1 Retention, Deletion & Archiving (Domain 2.7) 6.2 Auditability, Traceability & Accountability (Domain 2.8) 6.3 AI/ML Data Protection (Domain 2.9)

7 Domain 3: Infrastructure Components, Data Center & Risks

7.1 Cloud Infrastructure Components (Domain 3.1) 7.2 Secure Data Center Design (Domain 3.2) 7.3 Infrastructure & Platform Risks (Domain 3.3)

8 Domain 3: Security Controls & Business Continuity / Disaster Recovery

8.1 Security Controls Implementation (Domain 3.4) 8.2 Business Continuity & Disaster Recovery (Domain 3.5)

9 Domain 4: Application Security Awareness & Secure SDLC

9.1 Application Security Training & Awareness (Domain 4.1) 9.2 Secure SDLC Process (Domain 4.2) 9.3 Apply Secure SDLC (Domain 4.3)

10 Domain 4: Software Assurance, Architecture & IAM

10.1 Cloud Software Assurance & Validation (Domain 4.4) 10.2 Verified Secure Software (Domain 4.5) 10.3 Cloud Application Architecture (Domain 4.6) 10.4 Identity & Access Management Solutions (Domain 4.7)

11 Domain 5: Build, Operate & Operational Controls

11.1 Build Physical & Logical Infrastructure (Domain 5.1) 11.2 Operate & Maintain Infrastructure (Domain 5.2) 11.3 Operational Controls & Standards (Domain 5.3)

12 Domain 5: Forensics, Stakeholder Communication & Security Operations

12.1 Digital Forensics Support (Domain 5.4) 12.2 Communication with Relevant Parties (Domain 5.5) 12.3 Manage Security Operations (Domain 5.6)

13 Domain 6: Legal Requirements, Privacy & Audit

13.1 Legal Requirements & Cloud Risks (Domain 6.1) 13.2 Privacy Requirements (Domain 6.2) 13.3 Audit Processes for Cloud (Domain 6.3)

14 Domain 6: Enterprise Risk Management & Cloud Contracts

14.1 Cloud Implications for Enterprise Risk (Domain 6.4) 14.2 Outsourcing & Cloud Contract Design (Domain 6.5)

2.2 Cloud Reference Architecture (Domain 1.2)

Key Takeaways Explain This Topic AI

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.

Last updated: July 2026

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.