Free CCSK Exam Flashcards

1. On-demand self-service (automated provisioning without human provider interaction) 2. Broad network access (reachable over standard network protocols by diverse clients) 3. Resource pooling (multi-tenant dynamic allocation with location independence) 4. Rapid elasticity (quick outward and inward scaling with demand) 5. Measured service (metered resource usage, telemetry, and billing transparency)

IaaS (Infrastructure as a Service) provides compute, storage, and networking with customer control over deployed operating systems and applications, within the service boundaries. PaaS (Platform as a Service) abstracts the OS and runtime so customers control deployed applications and possibly application-hosting environment settings; access configuration and data protection remain important. SaaS (Software as a Service) delivers a complete turnkey application where the customer primarily manages user access, tenant configuration, and data governance.

1. Public Cloud: Provisioned for open use by the general public; ownership/operation may be business, academic, government, or a combination. 2. Private Cloud: Provisioned for exclusive use by a single organization (hosted on-premises or by a third party). 3. Community Cloud: Provisioned for exclusive use by a specific group of organizations with shared mission, security, or compliance needs. 4. Hybrid Cloud: Composition of two or more distinct cloud infrastructures bound by standardized or proprietary technology enabling data and application portability.

In a typical provider-hosted public cloud, the provider operates physical facilities, hardware, and the underlying abstraction layer. Private-cloud arrangements may allocate these duties differently; verify the service-specific matrix. In IaaS, the customer secures the guest OS, middleware, runtime, network firewall rules, application code, IAM, and data. In PaaS, the provider takes over guest OS and runtime patching, leaving application code, configuration, IAM, and data to the customer. In SaaS, the provider secures the full application stack while the customer remains accountable for data classification, tenant configuration, and user IAM.

The Management Plane (part of the CSA metastructure) consists of the administrative web console, REST APIs, CLI endpoints, and IAM controls used to provision and configure cloud resources. A VM breach initially affects that workload but can also expose credentials and enable lateral movement; compromising a privileged management-plane identity lets an attacker modify network rules, disable audit logging, exfiltrate snapshots, or terminate infrastructure across every resource within that identity's permission scope.

Cloud governance aligns cloud use with enterprise objectives, risk tolerances and applicable obligations. Outsourcing an operational task does not automatically discharge the customer’s legal duties; providers can also have independent duties. Define decision rights, service-specific responsibility matrices, contracts and service-level commitments, then monitor whether the required controls operate. Provider-hosted and organization-operated private clouds can allocate operational responsibilities differently.

Data residency is where data is geographically stored, while data sovereignty means data is subject to the laws of the jurisdiction where it resides or where the data controller/CSP operates. Cross-border replication, support access, or lawful government subpoenas (such as under the US CLOUD Act or GDPR transfer rules) can create conflicting legal obligations, and multi-tenant pooling complicates forensic e-discovery holds.

The CSA Cloud Controls Matrix is a cloud security control framework. Current CCM v4.1 (released January 2026) contains 207 controls across 17 domains, including IAM, Cryptography & Key Management, Infrastructure Security, and Audit & Assurance. It supports control selection, shared-responsibility allocation and mappings to other frameworks. The 17 CCM domains are not the 12 CCSK v5 curriculum domains, and current CCM release counts are not exam weighting percentages.

ENISA classifies cloud risks into Policy & Organizational, Technical, and Legal categories. Examples discussed include loss of governance, vendor lock-in, isolation failure (multi-tenancy/hypervisor breach), management interface compromise, insecure or incomplete data deletion, malicious insiders at the CSP, subpoena/e-discovery conflicts, and changes in jurisdiction during cross-border transfers.

The Consensus Assessments Initiative Questionnaire translates Cloud Controls Matrix controls into provider self-assessment questions. It helps customers compare and investigate provider controls, but a completed questionnaire is not an independent audit opinion. For a STAR submission, use the current submission version of CAIQ: CSA distinguishes that form from a CCM-plus-CAIQ reference workbook that cannot itself be submitted.

STAR Level 1 publishes a provider’s CAIQ self-assessment based on the CCM; standard self-assessment is complimentary. Optional AI validation is not an independent third-party audit. Level 2 uses third-party assessment: common security routes include STAR Certification with ISO/IEC 27001 plus CCM and STAR Attestation with SOC 2 plus CCM; C-STAR is another scheme for the Greater China market. CSA’s 2021 Level 3 research describes continuous auditing, while its current levels page foregrounds Levels 1 and 2. Check a provider’s actual scheme listing; a historical framework description does not establish that the provider holds a continuous-auditing certification.

Compliance inheritance means the customer can rely on the provider's audited controls for layers the provider wholly manages (such as physical data center security and hypervisor patching). However, the customer remains responsible for configuring and evidencing all customer-owned controls (such as IAM policies, encryption settings, firewall rules, and application security); an unhardened customer workload on a compliant cloud is still non-compliant.

SOC 1 concerns controls relevant to user entities’ financial reporting. SOC 2 addresses applicable Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality and Privacy. A Type I report addresses design at a specified date; Type II additionally addresses operating effectiveness over a specified period and includes tests/results. SOC 2 is restricted-use. SOC 3 is a general-use report with less detail, not merely a seal. Read the actual scope, period, exceptions and complementary user-entity controls rather than assuming every report covers every criterion.

A CCoE is a cross-functional governance team uniting security, architecture, operations, legal/compliance, procurement, and finance (FinOps). It establishes reusable cloud guardrails, reference architectures, approved service catalogs, landing zones, and shared-responsibility standards so application teams can adopt cloud services securely without ad-hoc silos.

Minimize dependence on proprietary provider APIs by using open standards, portable container formats (OCI), Infrastructure as Code abstractions, and documented data schemas. Contractually define data ownership, export formats, transition assistance windows, egress cost terms, and verifiable post-termination data destruction before onboarding the service.

Rehost ('lift and shift') moves VMs to IaaS with minimal changes, keeping OS/network security on the customer. Replatform ('lift and reshape') adopts managed PaaS services (like managed databases), shifting OS and engine patching to the CSP. Refactor re-architects applications into cloud-native microservices/serverless. Repurchase ('drop and shop') replaces legacy software with SaaS, shifting stack maintenance to the vendor while focusing customer security on IAM and data.

The Identity Provider (IdP) is the authoritative system that authenticates the user (verifying credentials and MFA) and issues a cryptographically signed identity assertion or token. The Relying Party / Service Provider (SP)—such as a cloud console or SaaS app—trusts the IdP's signature, validates the token's claims and expiration, and makes local authorization decisions without storing the user's password.

SAML 2.0 is an XML-based federation standard used primarily for enterprise browser Single Sign-On (SSO). OAuth 2.0 is a delegated authorization framework (not an authentication protocol by itself) that issues access tokens so applications/APIs can act on a user's behalf. OpenID Connect (OIDC) is a lightweight identity layer built on top of OAuth 2.0 that uses JSON Web Tokens (JWTs) to provide modern authentication for web, mobile, and API clients.

While SAML 2.0 and OIDC handle runtime authentication (SSO), they do not automatically deprovision accounts or synchronize group changes when a user isn't logging in. SCIM uses a standardized REST/JSON API to automate user lifecycle provisioning, attribute updates, role/group synchronization, and account deprovisioning ('joiner-mover-leaver') across SaaS and cloud providers. Actual removal latency depends on connector scheduling and implementation; disabling an account does not necessarily revoke every existing session or token.

RBAC assigns permissions to static roles, which can lead to 'role explosion' and over-privileged accounts in large multi-cloud environments. ABAC evaluates dynamic attributes of the subject, resource tags, action, and context (time, IP, device posture) at request time. Cloud Infrastructure Entitlement Management (CIEM) continuously analyzes effective permissions across cloud identities to detect and right-size excessive or unused privileges. RBAC remains useful for stable job functions; ABAC is not automatically superior and requires trustworthy attributes and well-tested policies.

Instead of granting standing administrative permissions ('always-on' root or admin roles), JIT PAM keeps privileged roles unassigned by default and grants temporary, time-bound, logged elevation only after an approved workflow or step-up MFA check, automatically revoking the privilege when the lease expires.

1. Management/Control Plane Audit Logs (e.g., CloudTrail, Activity Logs): record API calls, IAM changes, and resource provisioning. 2. Virtual Network Flow Logs (e.g., VPC Flow Logs): capture IP-level packet metadata (source/destination IP, ports, byte counts, accept/reject status) without full packet payloads. 3. Workload/Application Logs: capture guest OS events, container runtime telemetry, API gateway access, and application errors.

CSPM continuously queries cloud provider management-plane APIs and resource states to detect security misconfigurations (such as public storage buckets, permissive security groups, disabled logging, or unencrypted volumes), compares posture against benchmarks like CSA CCM or CIS, and alerts or triggers automated remediation.

Send audit events promptly to a separately administered logging account or security boundary. Restrict deletion and changes to log collection, enable appropriate immutable retention where supported, encrypt stored evidence, and monitor collection gaps. Use the provider’s integrity-validation mechanism (such as signed digest files) when available. Test access and recovery: an object-lock setting or a separate account alone does not prove the complete evidence pipeline is tamper-resistant.

While CSPM focuses on static posture and configuration state ('is this bucket or IAM policy misconfigured?'), CDR analyzes runtime telemetry, API call sequences, identity behavior, and network flows in real time to detect active threats ('is a compromised identity currently enumerating secrets and staging data exfiltration?').

A Type 1 hypervisor controls hardware resources beneath guest operating systems; privileged management components still need hardening and patching. Some cloud designs offload networking/storage/security functions to dedicated hardware, but implementations vary. A VM escape exploits a hypervisor or virtual-device weakness to cross guest isolation, potentially reaching the host or another guest. Bare-metal classification does not mean the trusted computing base has no operating-system code or vulnerabilities.

SDN decouples the network control plane (centralized software routing and policy controllers) from the data/forwarding plane (virtual switches on hypervisors encapsulating packets via overlay protocols like VXLAN or Geneve). This allows multiple tenants to use overlapping private IP ranges in logically isolated Virtual Private Clouds (VPCs) over shared physical switching fabric without packet cross-talk.

Microsegmentation applies granular, workload-level network policies (attached to virtual NICs, tags, or workload identities) to restrict east-west lateral movement inside a virtual network. In AWS’s model, stateful security groups track connection state and automatically permit return traffic for allowed requests, whereas stateless subnet network ACLs evaluate applicable inbound and outbound traffic independently. Do not assume every provider uses these names or the same semantics.

A Software-Defined Perimeter separates access decisions from application connectivity. A controller authenticates users/devices and authorizes access; an enforcing gateway permits only the authorized connections, commonly through encrypted tunnels. Default-deny exposure reduces the attack surface. Single Packet Authorization is one technique used in SDP architectures, not proof that every implementation hides DNS or presents no public authentication endpoint. Validate the actual design and authorization boundary.

Virtual machines run separate guest operating system kernels atop a hypervisor, providing hardware-assisted isolation. Containers share the underlying host OS kernel and rely on Linux kernel features—namespaces (visibility isolation), cgroups (resource metering/limits), and seccomp/AppArmor/SELinux—for separation. Consequently, a kernel vulnerability or privileged container misconfiguration can compromise the shared host and all sibling containers on that node.

1. Restrict and authenticate access to the Kubernetes API Server with a supported authentication mechanism and least-privilege RBAC; OIDC is one authentication option. 2. Configure encryption at rest for sensitive API data stored in etcd and restrict network access to control-plane nodes. 3. Enforce Pod Security Standards / admission controllers to block privileged pods and hostPath mounts. 4. Apply default-deny ingress/egress NetworkPolicies using a CNI implementation that enforces them. 5. Scan container images and strip unnecessary binaries/shells.

In FaaS, the CSP manages the host OS and ephemeral microVM/container runtime, so customers normally lack host administrative access; supported runtime instrumentation and network controls vary by service. Key FaaS risks include over-privileged shared IAM execution roles (violating per-function least privilege), event-data injection from non-HTTP triggers (queues, storage events), vulnerable third-party code dependencies, and secrets embedded in code or exposed through poorly controlled configuration; environment variables require access and logging safeguards rather than being inherently hardcoded.

CWPP focuses specifically on protecting compute workloads (VMs, containers, serverless functions) via vulnerability scanning, runtime behavioral protection, file integrity monitoring, and workload microsegmentation. CNAPP unifies CWPP, CSPM (posture), CIEM (entitlements), and IaC/artifact scanning into a single platform that correlates risks from code commit through runtime.

In immutable infrastructure, running production servers or containers are never manually modified or patched in place via interactive SSH/RDP. Instead, updates are baked into a new hardened golden image or container artifact in the CI/CD pipeline, tested automatically, and deployed to replace the old instances—reducing configuration drift and replacing compromised instance-local state. Stolen credentials, poisoned images and persistent external data still require separate remediation.

Create -> Store -> Use -> Share -> Archive -> Destroy (CSU-SAD). Data classification and metadata tagging should begin at creation or ingestion and be reassessed when content or use changes because downstream automated controls—such as encryption requirements in Store, masking in Use, DLP egress policies in Share, retention in Archive, and crypto-shredding in Destroy—depend on accurate classification labels. These are conceptual phases; real data can cycle between use and sharing or have several copies in different phases.

Block storage provides raw virtual disk volumes attached to VMs (risk: unencrypted snapshots or unattached 'zombie' volumes). Object storage stores flat data blobs with rich metadata accessed via REST/HTTPS APIs (risk: misconfigured bucket policies or ACLs exposing objects directly to the internet). File storage provides shared hierarchical POSIX/SMB network filesystems (risk: overly broad mount permissions across subnets).

A data encryption key (DEK), generated locally or by a key service, encrypts the bulk data. A key encryption key (KEK) wraps that DEK; the wrapped DEK can be stored with the ciphertext. This limits bulk-data traffic to the key service and separates data encryption from key protection. The KEK may reside in a managed KMS/HSM or an external system. Rewrapping a DEK is different from rotating the DEK and re-encrypting the data; rotating a KMS key does not automatically re-encrypt all existing ciphertext.

Provider-managed keys give the provider most lifecycle control. Customer-managed keys allow customer policy/lifecycle control; their material may be generated by the cloud KMS or imported. BYOK specifically refers to bringing key material and is not synonymous with all customer-managed keys. HYOK/external key management keeps key control outside the cloud service. External availability, latency, recovery and supported service features must be assessed; key location alone does not guarantee sovereignty or prevent authorized plaintext access.

In multi-tenant cloud storage, data blocks are distributed across shared SSDs (wear-leveling) and replicated across multiple nodes, so a tenant cannot run low-level magnetic overwrite passes on physical media. Cryptographic erasure (crypto-shredding) encrypts data with a strong, unique key at creation and destroys all copies of that DEK/KEK when the data reaches the Destroy phase, rendering any residual ciphertext unreadable. This requires suitable encryption, successful destruction of all relevant key copies, and verification that no recoverable plaintext or alternate decryption keys remain; deleting one cloud key reference is not sufficient evidence.

Shift-left integrates automated security controls early and continuously into the Software Development Lifecycle (SDLC)—starting with threat modeling at design, pre-commit secret detection in the IDE, and automated SAST/SCA/IaC checks on every pull request—rather than relying on manual penetration tests or cab approvals right before production deployment.

SAST (Static Application Security Testing) analyzes source code or bytecode without executing it. DAST (Dynamic Application Security Testing) probes a running application from the outside for runtime flaws. SCA (Software Composition Analysis) inventories third-party components, including open-source libraries to flag known CVEs and license risks, and can produce a Software Bill of Materials (SBOM); an inventory alone does not prove vulnerability freedom. IaC scanning inspects Terraform/CloudFormation/Kubernetes manifests for cloud misconfigurations before provisioning.

An API Gateway acts as a centralized policy enforcement point for microservices, enforcing TLS termination, OAuth/OIDC token validation, mTLS, schema validation, and rate limiting/throttling. However, an API Gateway often cannot stop BOLA (OWASP API1)—where an authenticated user changes an object ID in an API call to access another user's record—unless the backend service or policy engine explicitly checks object-level ownership.

Because CI/CD runners often possess high-privilege management-plane credentials to deploy infrastructure and application code, compromising the build server or injecting malicious code via a pull request can compromise resources within the runner’s privileges and reachable trust relationships. Secure pipelines use ephemeral build runners, short-lived OIDC workload identity tokens instead of static long-lived secrets, signed commits/artifacts, and separate credentials for dev vs production.

Adapt preparation to the service and its responsibility matrix. Establish provider contacts and escalation paths, pre-authorize forensic access, configure and retain relevant management, network and workload logs, and test cloud-specific containment and recovery procedures. APIs and automation can support repeatable response, but permissions, service limitations and evidence requirements must be verified before an incident.

In provider-hosted public clouds, customers generally lack physical-media and hypervisor access. Ephemeral workloads and distributed logs can make evidence disappear or require correlation across clocks and services. Use supported volume snapshots, relevant audit and workload logs, and volatile-memory capture where feasible. Protect retention and integrity, record acquisition times and access, and verify provider-specific collection limits; neither memory capture nor immutable logging is automatic.

Immediate termination can destroy RAM, running-process and ephemeral-storage evidence. Balance urgent harm reduction with the response plan: isolate network access, restrict or revoke compromised credentials through supported mechanisms, capture volatile data where feasible, and snapshot relevant volumes for controlled analysis. Verify that isolation actually stops traffic: changing a stateful security group may leave tracked flows active. Removing a role alone may not invalidate already issued credentials. Containment sequence depends on the threat, service and evidence requirements, not a universal “never terminate” rule.

An availability zone is a failure-isolation location within a region and may comprise one or more data centers. Multi-AZ designs can reduce exposure to a zone failure; multi-region designs address wider failures and introduce additional replication/routing tradeoffs. RTO is the recovery-time objective; RPO is the tolerated data-loss interval. Neither deployment label guarantees a particular RTO/RPO: replication mode, failover automation, dependencies and tested recovery determine the outcome. Synchronous replication can reduce data loss; asynchronous replication may leave a recovery gap.

1. Policy Engine (PE): evaluates trust signals (identity, device health, location, behavior, resource sensitivity) against policy rules to decide whether to grant access. 2. Policy Administrator (PA): establishes or tears down the communication path via session-specific tokens/credentials. 3. Policy Enforcement Point (PEP): the inline gateway or agent that mediates, monitors, and terminates the connection between the subject and enterprise resource.

In Inline Proxy mode (forward or reverse proxy), the CASB sits directly in the network traffic path to enforce real-time controls—blocking unauthorized downloads, unsanctioned 'Shadow IT' SaaS apps, or unmanaged devices. In Out-of-Band API mode, the CASB connects directly to a sanctioned SaaS provider's APIs to inspect data at rest, audit sharing permissions, and remediate policy violations asynchronously without adding network latency.

1. Direct and indirect Prompt Injection (manipulating model instructions to bypass guardrails or invoke unauthorized tools/APIs). 2. Sensitive Data Leakage & Training Data Ingestion (proprietary corporate data or PII being exposed through prompts, retrieval, outputs or retention; whether prompts are used for training depends on the service’s terms and configuration). 3. Data Poisoning & Model Supply Chain tampering. 4. Insecure Output Handling (passing unvalidated LLM outputs directly to downstream shells, browsers, or SQL queries).

A hierarchy groups environments with common governance needs and gives administrators a place to apply inherited controls. For example, AWS uses organizations and organizational units containing accounts; Azure uses management groups containing subscriptions. Separate production and non-production workloads and apply least-privilege access at the appropriate scope. The object names, inheritance rules and exceptions differ by provider, so copying a corporate reporting chart or assuming every parent policy grants access is unsafe.

Central identity integration, logging, security tooling and connectivity can make controls consistent across accounts or subscriptions. Give each shared service an accountable owner, restricted administration and protected configuration. Test its failure impact and keep evidence access separate from workload administration where practical. Centralization creates dependencies and a potentially valuable attack target; it does not mean every application should share one unrestricted account or trust boundary.

Start with common required outcomes, such as restricted administrator access, retained audit evidence and approved data locations. Map each outcome to the actual controls and responsibility split in every environment, then verify them separately. Provider accounts, subscriptions, policy inheritance and service features differ, so identical names or copied configurations do not prove equivalent protection. Record exceptions, owners and cross-environment dependencies.

AI/ML can correlate cloud events, detect departures from behavioral baselines and prioritize suspicious activity for investigation. Analysts should inspect the underlying events and business context, measure false positives and missed detections, and refresh models as conditions change. High-risk response steps need an approved playbook and human review appropriate to the action; a model's anomaly score is not proof of compromise. Protect sensitive telemetry used for inference or training.

Secure Access Service Edge (SASE) converges wide-area networking, commonly SD-WAN, with cloud-delivered security such as secure web gateways, CASB, firewall services and Zero Trust Network Access. It applies access and inspection policies near distributed users and applications rather than relying only on backhauling traffic to a central data-center perimeter. A VPN supplies connectivity; it does not by itself supply that integrated security architecture. Actual identity, device and application policies still need configuration and testing.

Data Security Posture Management (DSPM) discovers and classifies sensitive data across cloud stores, then relates that data to access, usage and exposure to prioritize remediation. CSPM primarily assesses infrastructure and resource configuration; DSPM adds data-content and sensitivity context. For example, discovering customer records in an overlooked development copy can make an exposure urgent even when the account inventory already lists the storage resource. Capabilities overlap, so verify what each product actually scans and protects.

Post-incident analysis turns the incident record into improvements after containment and recovery. Reconstruct what happened from preserved evidence, identify root causes and gaps in detection or response, and review what worked. Translate lessons into changes to controls, monitoring, playbooks and responder training, then test the changes. Restoring service alone does not establish why the incident happened or prevent recurrence; preserve the evidence needed for follow-up and any applicable reporting.