Certified Cloud Security Analyst cheat sheet
Certified Cloud Security Analyst · Keep the key ideas within reach.
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.
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.
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.
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.
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.
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.