ExamFinch.com My Study

Study guide

4.2 Cloud Data Storage Architectures (Domain 2.2)

Practice this exam

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)

4.2 Cloud Data Storage Architectures (Domain 2.2)

Key Takeaways Explain This Topic AI

CCSP storage types include long-term, ephemeral, raw, object, and volume storage — each has different durability, access patterns, and threat profiles.

Object storage is API-addressable, highly durable, and commonly misconfigured for public access; volume storage attaches as block devices to compute and inherits instance-compromise risk.

Ephemeral storage vanishes with the instance lifecycle and must not be the sole home for durable secrets or regulated records; still sanitize and avoid sensitive residue.

Long-term and archive classes trade retrieval latency/cost for retention economics; threats include incomplete deletion, weak access on 'cold' data, and ransomware against backups.

Design by matching data lifecycle phase and classification to storage type, then apply type-specific threats: access control, encryption, immutability, network isolation, and lifecycle policies.

Last updated: July 2026

Cloud Data Storage Architectures

Domain 2.2 asks you to design and implement storage architectures — not merely list product names. The August 2026 outline highlights storage types such as long-term, ephemeral, raw, object, and volume , plus threats to each type . Vendor consoles brand these differently (block volumes, blob/object buckets, local instance disks, cold archive tiers, direct-attached or import/export raw media). CCSP expects vendor-neutral recognition of characteristics and risks.

Storage architecture is where lifecycle concepts become physical (or virtual) reality. Choosing object storage for unbounded unstructured content, volumes for databases, and long-term classes for compliance archives is a security decision as much as a cost decision — because threats follow the access model .

Shared Responsibility for Storage

  • Layer Typical CSP responsibility Typical customer responsibility
  • Physical media, racks, facilities Yes No (except private/on-prem cloud)

Underlying storage fabric durability features Yes (as marketed/SLA) Validate SLA fit; design multi-region if needed

  • Hypervisor / storage service software Yes Patch/config only if customer-managed components exist
  • Encryption in transit to storage APIs Often default TLS Enforce TLS; disable weak endpoints

Encryption at rest & key custody Provider-managed or customer-managed options Choose CMK/HSM paths when required; protect keys

  • IAM policies, public access, network endpoints Platform features Customer configures — #1 breach class
  • Classification, lifecycle rules, logging Features available Customer defines and monitors

Exam mantra: The provider keeps the disks spinning; you keep the data from being world-readable.

Storage Types Overview

Type Access model Durability posture Typical use

Volume storage Block device attached to VM/container host High when backed by networked durable volumes; depends on snapshot/replication design OS disks, databases, transactional apps

Object storage RESTful/API object + metadata Extremely high via multi-AZ erasure coding/replication Backups, content, data lakes, static assets

Long-term storage Often object/archive APIs with retrieval delay High; retrieval may be hours Compliance archives, cold backups, rarely read datasets

Ephemeral storage Local to instance/function lifecycle Low — data lost on stop/terminate/recycle Caches, scratch space, temp processing

Raw storage Low-level or direct media / import-export / bare capacity Variable Bulk ingest, specialized appliances, migration pipelines

File storage (managed NFS/SMB-style shares) appears in real architectures and may be tested as a hybrid of volume/network semantics; the outline’s explicit list is the five above — know those cold.

Volume Storage

Volume storage presents a block device (virtual hard disk) to a compute instance. The guest OS filesystems and databases sit on top. Volumes can be:

Network-attached durable volumes that survive instance stop (typical cloud "EBS-like" pattern).

Local NVMe/SSD that may be instance-bound (borderline ephemeral — check provider semantics).

Design notes

Snapshots and clones create dispersed copies — encrypt snapshots and restrict share permissions.

Multi-attach or shared-disk patterns need careful fencing to avoid corruption.

Performance tiers (IOPS/throughput) affect availability under load (noisy neighbor or throttle) but security focuses on access and encryption.

Threats to volume storage

Threat Description Mitigations

Unauthorized attach/snapshot Stolen role creates snapshot or attaches volume to attacker instance Strict IAM, deny public snapshot shares, organization policy guards

Instance compromise Malware reads mounted filesystem Hardening, EDR, least privilege OS accounts, encryption + key isolation

  • Snapshot sprawl Forgotten snapshots hold old PHI Lifecycle policies, inventory, tagging
  • Unencrypted volumes Media theft or backend exposure residual risk Default encryption, CMK for high sensitivity

Orphaned volumes Detached disks still billed and readable by privileged admins Automation to detect unattached volumes; delete or quarantine

Cross-account share abuse Volume/snapshot shared to wrong account Explicit allow-lists; monitor share events

Exam tip: If the stem says "database on a VM," think volume threats (snapshot theft, attach-to-hostile-VM) more than public bucket policies — unless backups land in object storage.

Object Storage

Object storage manages discrete objects (blobs) addressed by keys within buckets/containers, with rich metadata and HTTP(S) APIs. It scales nearly without the filesystem limitations of volumes. Versioning, lifecycle transitions, event notifications, and strong durability make it the backbone of modern cloud data lakes and backup targets.

Design notes

Flat namespace + prefixes replace deep directory ACLs — IAM and bucket policies are the perimeter.

Versioning helps ransomware recovery but retains deleted-object versions until lifecycle cleans them.

Object lock / immutability (WORM-style) supports legal retention and ransomware resilience.

Static website hosting / public read features are convenience switches with severe risk if misused for private data.

Threats to object storage

Threat Description Mitigations

Public access misconfiguration Anonymous List/Get on sensitive prefixes Block public access defaults, policy checks, continuous config audit

  • Over-permissive IAM Wildcard principals or actions Least privilege, condition keys (VPC endpoint, MFA delete)
  • Presigned URL abuse Long-lived URLs leaked in logs/tickets Short TTL, scope to object, monitor generation

Malicious object upload Malware or poison data in inbound buckets Malware scanning, content-type validation, separate unclean/clean buckets

Ransomware / mass delete Destructive API calls Versioning + object lock, MFA delete, separate backup account

Server-side request / SSRF to metadata Apps fetch attacker-controlled object URLs Egress control, validate URLs

Metadata leakage Sensitive data in object names or tags Naming standards, encryption of sensitive metadata where supported

Object storage is the most frequently breached cloud storage class in exam scenarios because one policy statement can expose petabytes.

Long-Term Storage

Long-term storage (cold/archive classes, offline vaults, tape-gateway patterns) optimizes cost for data retained months to decades with infrequent access. Retrieval may require hours and rehydration fees. From a security view, "cold" does not mean "uninteresting to attackers" — archives hold crown-jewel historical data.

Design notes

Align archive class with retention policies and legal hold (Domain 2.7 topics build here).

Test restores; untested archives fail business continuity.

Prefer encryption with keys under customer governance for regulated archives.

Document who can initiate retrieval — retrieval is a high-value audit event.

Threats to long-term storage

Threat Description Mitigations

Weak controls on "forgotten" data Legacy buckets with broad access Same IAM rigor as hot data; periodic access reviews

  • Incomplete destruction Delete primary, leave archive Unified lifecycle inventory across tiers
  • Ransomware targeting backups Encrypt/delete backup vaults Immutable vaults, separate accounts, dual control
  • Insider retrieval abuse Quiet exfiltration via restore jobs Alert on atypical restore volume/destination

Media/vendor residual risk Offline media handling, third-party vaults Chain of custody, contractual sanitization

  • Integrity decay Bit rot or silent corruption over years Checksums, periodic integrity verification
  • Ephemeral Storage

Ephemeral storage is temporary capacity tied to the life of a compute unit: instance store, container writable layers, serverless /tmp , GPU local disks. When the instance stops, recycles, or scales in, data may be wiped or become unreachable. Developers love it for speed; security professionals fear secrets left in temp files and false assumptions of durability .

Design notes

Use for caches, intermediate compute, non-authoritative scratch only.

Redirect durable writes to volume/object stores explicitly.

Prefer memory-backed secret injection over writing keys to local disk.

Assume residual data may persist until provider reclaims media — encrypt sensitive temp data if unavoidable.

Threats to ephemeral storage

  • Threat Description Mitigations
  • Sensitive residue Tokens, PII in /tmp after crash Avoid writing secrets; secure delete; disk encryption

Cross-tenant residual risk Theoretical residual on reused hardware Provider sanitization + customer encryption defense-in-depth

False durability App "stores" records only on local disk Architecture review; chaos terminate tests

Container breakout reading host paths Shared mounts expose sibling data Minimal mounts, user namespaces, separate nodes for sensitive workloads

  • Debug artifacts Core dumps with secrets Disable unprotected dumps; restrict permissions
  • Raw Storage

Raw storage in CCSP discussion often means low-level capacity without higher-level object semantics — for example, bare LUNs, direct-attached storage patterns, bulk data import/export devices, or unformatted block capacity presented for customer formatting. It appears in migrations (snowball-style offline transfer conceptually), specialized high-performance workloads, and lift-and-shift of appliances that expect raw disks.

Design notes

Customer may own more of the stack (partitioning, encryption software, multipathing).

Physical or courier-based bulk transfer adds chain-of-custody threats.

Label and inventory raw volumes carefully — easy to attach to the wrong host.

Threats to raw storage

  • Threat Description Mitigations
  • Mis-attachment Wrong LUN mapped to wrong tenant/host Strict zoning/mapping, change control

Transit loss/theft (import/export) Device seized in shipping Encryption before ship, tamper evidence, dual control

Uninitialized sensitive residue Previous data remnants Crypto-erase, secure wipe procedures

Weaker API audit trails Fewer high-level data events than object stores Host-level logging, storage fabric logs

Privilege on storage fabric Admin can clone raw devices silently Segregation of duties, monitoring clone/mirror jobs

Comparing Threats Across Types

  • Threat theme Volume Object Long-term Ephemeral Raw
  • Public anonymous access Rare (if exposed via app) Very common Common if archive is object-backed Low Low
  • Snapshot/clone theft High Version/copy abuse Restore abuse N/A Clone/mirror abuse

Lifecycle deletion gaps Snapshot orphans Version orphans Archive leftovers Auto-wipe on terminate Media return gaps

  • Host compromise reads data High Via keys/creds Via restore High locally High
  • Ransomware Encrypt FS / delete snaps Mass delete/overwrite Destroy vaults Limited Encrypt LUN
  • Architecture Patterns That Pass Exam Scrutiny

Tiered storage with policy: Hot volumes/objects for Use phase; lifecycle transition to long-term for Archive; automated expire/destroy.

Immutable backup pattern: Production account writes to backup account object lock vault; separate IAM boundaries.

Ephemeral compute, durable data: Stateless instances; state only in managed databases/object stores.

Private access paths: Storage endpoints reachable via private networking; block public internet where feasible.

Encryption default + CMK for sensitive classes: Provider-managed keys for low sensitivity; customer-managed for regulated.

Migration with raw/import devices: Encrypt payloads before device leaves source facility; verify hashes on ingest.

Worked multi-cloud example: An enterprise runs transactional databases on volume storage in Cloud A, lands analytics extracts in object storage, transitions year-old extracts to long-term archive, uses ephemeral disks for Spark executors, and performs initial bulk load via encrypted raw /offline transfer appliances. Threat reviews must not stop at the database volume — the object analytics bucket and archive vault are equal prize targets.

Selecting Storage Type: Decision Grid

  • Question Prefer
  • Need POSIX disk for DB/app installs? Volume
  • Massive unstructured, API access, event-driven? Object
  • Retain 7+ years, rare reads? Long-term
  • Scratch space only for job runtime? Ephemeral
  • Bulk offline migration or appliance disks? Raw (with encryption)
  • Common Traps

Using ephemeral storage as the only copy of customer records.

Treating archive tiers as "safe enough" with open IAM.

Forgetting that volume snapshots often live in object-backed snapshot services — hybrid threat model.

Equating durability SLAs with confidentiality.

Assuming raw import devices are secure because they are "offline" without encrypting contents.