Certified Cloud Security Analyst study materials
Certified Cloud Security Analyst study resources

Certified Cloud Security Analyst cheat sheet

Certified Cloud Security Analyst · Keep the key ideas within reach.

Quick reference

Cloud Security Fundamentals and Governance

  • CIA triad applied to cloud: confidentiality maps to encryption and least privilege; integrity to hashing, logging and change control; availability to multi-AZ design, quotas and DDoS protection.

  • NIST SP 800-145 defines five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service. A workload missing measured service is not cloud by this definition.

  • Governance control hierarchy: policy (intent) → standard (mandatory requirement) → procedure (steps) → guideline (recommendation). Audit findings cite the standard violated, not the policy.

  • Risk treatment options are exactly four: mitigate, transfer, avoid, accept. Residual risk equals inherent risk minus control effectiveness; acceptance must be documented by an accountable owner.

  • CSA Cloud Controls Matrix is a control framework mapped to ISO 27001, NIST, PCI DSS and HIPAA; use it as a crosswalk, not as a certification.

  • Control categories: preventive (blocks), detective (identifies), corrective (restores), deterrent (discourages), compensating (substitutes when primary control is infeasible).

  • Data classification tiers drive handling rules; label at creation because retroactive classification of object stores requires full-scan discovery and often fails on unlabeled buckets.

  • Shared fate vs shared responsibility: the provider secures the cloud, the customer secures what they put in it - but accountability for customer data and compliance remains with the customer in every model.

Quick reference

Cloud Architecture, Models and Shared Responsibility

  • IaaS: customer owns OS, runtime, middleware, app, data. PaaS: customer owns app, data, identity configuration. SaaS: customer owns data, identity configuration, and endpoint.

  • Shared responsibility boundary shifts with service model, not with vendor: the higher the abstraction (IaaS→PaaS→SaaS), the more controls transfer to the provider.

  • Deployment models: public, private, community, hybrid, multi-cloud. Multi-cloud increases blast-radius isolation but multiplies identity planes and policy drift risk.

  • Well-architected pillars: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability. Trade-offs are explicit; security rarely loses to cost without documented acceptance.

  • Network segmentation in cloud relies on security groups (stateful, instance-attached), NACLs (stateless, subnet-attached, ordered rules), and route tables; SG rules are allow-only.

  • Availability zone failure is the standard fault domain; region failure requires cross-region replication and a documented RTO/RPO. Single-AZ designs have an implicit RTO of unknown length.

  • Landing zone / organization hierarchy: management account holds billing and guardrails, not workloads; service control policies set the maximum permissions any principal in a member account can hold.

  • Immutable infrastructure (rebuild, don't patch) reduces configuration drift and shrinks the window in which a compromised host persists.

Quick reference

Cloud Identity, Access and Data Protection

  • Authentication factors: something you know, have, are; MFA must combine different factor types. Two passwords are not MFA. Phishing-resistant MFA means FIDO2/passkeys or hardware keys.

  • Authorization models: RBAC (roles), ABAC (attributes/tags), PBAC (policy). Cloud-native policy languages (e.g., JSON IAM policies) are evaluated as explicit deny > explicit allow > implicit deny.

  • Least privilege workflow: start from deny, grant observed usage, remove unused permissions via access analyzer / last-accessed data, then re-review on a schedule.

  • Privilege escalation paths to audit: iam:PassRole + compute create, policy version rollback, trust-policy edits on roles assumable by external accounts, and CI/CD service accounts with broad deploy rights.

  • Federation: SAML 2.0 and OIDC issue short-lived tokens; prefer role assumption over long-lived access keys. Static keys are the most common leaked credential in public repositories.

  • Data at rest: envelope encryption with a KMS key hierarchy (root key → data key → data). Encryption is not access control - key policy and grants decide who can decrypt.

  • Data in transit: TLS 1.2+ with strong cipher suites; certificate pinning for mobile; mTLS for service-to-service. TLS termination point determines where plaintext exists.

  • Token and secret hygiene: secrets in a managed vault with rotation, never in environment variables baked into images, never in build logs. Detect with pre-commit secret scanning.

  • Data loss prevention controls: classification labels, egress restrictions, object-store block-public-access, and sharing-link expiry for SaaS collaboration.

Quick reference

Cloud Infrastructure and Application Security

  • Secure SDLC gates: threat model at design, SAST on commit, SCA/dependency scan on build, DAST on staging, IaC scan before plan/apply, container image scan before push.

  • IaC scanning catches misconfiguration before deployment; drift detection catches it after. Both are needed because console changes bypass pipelines.

  • Container hardening: minimal base image, non-root user, read-only root filesystem, no privileged flag, seccomp/AppArmor profile, signed images with admission control enforcing signatures.

  • Serverless risks: over-broad function execution role, event-injection via untrusted input, dependency confusion in layers, and long-lived secrets in environment variables.

  • Top API risks include broken object-level authorization (BOLA), broken authentication, excessive data exposure, and unrestricted resource consumption. BOLA is the most common cloud API flaw.

  • CSP and security headers (HSTS, X-Content-Type-Options, frame-ancestors) are defense-in-depth; they do not replace server-side authorization checks.

  • Secrets management pattern: workload identity → short-lived credential → vault-issued dynamic secret. Static secrets are a design defect, not a configuration choice.

  • Patch strategy: immutable rebuild for hosts, managed runtimes for platform services, and an SBOM to answer 'are we affected' within hours of a CVE disclosure.

Quick reference

Cloud Security Operations, Monitoring and Incident Response

  • Log sources to centralize: control-plane audit logs (who changed what API), data-plane access logs, VPC flow logs, DNS query logs, WAF logs, identity provider sign-in logs, and workload application logs.

  • Detection tiers: guardrails (prevent), config rules/drift alerts (detect misconfiguration), anomaly detection on identity behavior (detect compromise), and threat intel matching.

  • Cloud IR phases: prepare, detect, contain, eradicate, recover, lessons learned. Containment in cloud usually means revoking credentials, isolating the instance's security group, and snapshotting before termination.

  • Evidence preservation: snapshot volumes and export logs to a separate, write-once account before remediation; termination destroys volatile data.

  • Key IR artifacts to capture: the identity that made the API call, source IP, user agent, timestamp in UTC, and the resource ARN. Audit logs are the primary timeline source.

  • Serverless and container logs are ephemeral by default; set retention explicitly or logs are lost before an investigation begins.

  • Break-glass procedure: a sealed, monitored, MFA-protected emergency account with alerting on any use, plus a post-use review. Never the everyday admin.

  • Metric baselines matter: alert on deviation from learned behavior (new region, new ASN, impossible travel, spike in Describe/List calls) rather than on absolute thresholds alone.

Quick reference

Cloud Compliance, Risk and Vendor Management

  • Compliance is shared but attestation is not: provider reports (SOC 2 Type II, ISO 27001 certificate) cover the provider's controls; the customer still needs its own evidence for customer-side controls.

  • SOC 2 Type II covers a period and tests operating effectiveness; Type I covers a point in time and design only. Type I alone is weak evidence for continuous control operation.

  • Regulatory mapping examples: PCI DSS for cardholder data, HIPAA for PHI in the US, GDPR for EU personal data, and data residency laws that restrict cross-border transfer.

  • Vendor due diligence: review scope of attestation, carve-outs, subservice organizations (carve-out vs inclusive method), breach notification timelines, data return/deletion terms, and audit rights.

  • Cloud risk register entries should carry asset, threat, likelihood, impact, control, residual risk, owner, and review date; a register without an owner is not actionable.

  • Data residency vs sovereignty: residency is where data is stored; sovereignty adds legal jurisdiction over access. Provider-owned keys do not satisfy sovereignty requirements.

  • Continuous compliance uses policy-as-code evaluated against live resource state; point-in-time audits go stale within hours in a fast-changing cloud estate.

  • Exit strategy: verify export formats, egress cost, key custody, and deletion certification before signing; lock-in risk is a compliance risk when deletion cannot be proven.