Cloud Concepts, Architecture & Design

Ask five vendors what "the cloud" is and you get five sales pitches; CCSP grades against exactly one answer, the NIST SP 800-145 definition, which fixes five essential characteristics, three service models (IaaS, PaaS, SaaS), and four deployment models (public, private, community, hybrid). That definition is the vocabulary every later control maps onto. Sitting on top of it is the single most testable idea in the domain, the shared-responsibility model: the same security goal lands on a different owner depending on the service model, because the customer/provider responsibility line slides up the stack from IaaS (you secure the guest OS upward) to SaaS (you configure mainly data and identity). The classic trap is a scenario that quietly changes the service model and expects you to follow the line; data and identity stay the customer's job in every model, so when a question feels ambiguous, anchor on the definition and ask which side of that line the control falls on.

Read this page as a map, then follow the five subtopics in order. Cloud Computing Concepts establishes the shared vocabulary: the NIST definition, the roles (customer, provider, partner, broker, auditor), and the building blocks (virtualization, software-defined storage and networking) that make the five characteristics possible. Cloud Reference Architecture lays out the layered stack and shows where the service and deployment models place the responsibility line and the lock-in trade-offs. Cloud Security Concepts adds the cross-cutting defenses that change in a multi-tenant world: who holds the encryption key, identity as the new perimeter, cryptographic erase for deletion, and zero trust on the network. Secure Cloud Design Principles turns those concepts into a method: design from the data outward across the six-phase data lifecycle, pick controls by service model, and justify resilience (BC/DR) from a business impact analysis. Cloud Service Provider Evaluation closes the loop, judging a provider on independent evidence (SOC 2, ISO/IEC 27017, CSA STAR) rather than its own marketing.

Across every subtopic the exam rewards the same instinct: trust what an outside party can verify, and keep the levers that matter in your own hands. A provider calling itself "secure" counts for nothing against a third-party attestation tested over time (SOC 2 Type II beats Type I; STAR Level 2 audit beats a Level 1 self-assessment). Encryption protects you from the provider only when you, not the provider, hold the key, which is why customer-managed keys and crypto-erase recur as the defensible choices. And because identity is the cloud perimeter, least privilege with just-in-time elevation beats standing admin rights. The pattern to internalize: the answer backed by verifiable evidence and the narrowest, customer-controlled access is the exam-correct one far more often than the convenient default.