Certified Cloud Security Analyst common mistakes
Certified Cloud Security Analyst · Understand the traps and how to avoid them.
Assigning the customer full responsibility for everything above the hypervisor when asked who secures a given control in an IaaS deployment, instead of naming the specific control owner for each layer (hypervisor, guest OS, network controls, data, identity).
Candidates memorize a one-line shared responsibility slogan and apply it as a blanket rule, so they mis-assign controls that shift with the service model (SaaS, PaaS, IaaS) and with the specific control being asked about.
What to do instead
Build a grid of service models (IaaS/PaaS/SaaS) against control layers (physical, hypervisor, guest OS, runtime, app, data, identity, configuration) and practice assigning owner (provider/customer/shared) for each cell. When a question names a control, locate it on the grid before answering.
Treating the cloud provider's compliance certifications (SOC 2, ISO 27001, FedRAMP) as covering the customer's own workload and configuration, and answering that the customer inherits compliance for its data and applications.
Candidates conflate provider attestations about the provider's infrastructure with assurance over the customer's use of it, because both appear in the same compliance documentation.
What to do instead
Distinguish provider-scope attestations from customer-scope obligations. For any compliance question, ask 'whose system is being audited?' The provider's report covers the provider's controls; the customer must still evidence its own config, access, and data controls.
Choosing a broad built-in role or wildcard policy (e.g., AdministratorAccess, s3:*) to solve an access problem, rather than applying least privilege with scoped actions and resources.
Least privilege questions often look like availability questions, and candidates default to the option that 'definitely works' rather than the one that is minimally sufficient.
What to do instead
When an access question appears, eliminate any answer containing wildcards or broad managed roles unless the scenario explicitly requires break-glass access. Prefer scoped resource ARNs, conditions, and permission boundaries, and expect the correct answer to grant only the actions the task needs.
Confusing authentication with authorization, or confusing identity federation with directory synchronization, when answering questions about SSO, SAML, OIDC, and role assumption.
The terms overlap in vendor documentation and candidates learn them as a bundle rather than as distinct mechanisms with distinct failure modes.
What to do instead
Write one-sentence definitions for each: authentication proves who, authorization decides what, federation trusts an external IdP's assertion, sync copies identities. Then map each exam scenario to the mechanism it actually needs before reading answer choices.
Assuming data is encrypted end-to-end by default and selecting 'encryption enabled' as a complete answer, without addressing key management, key custody, rotation, and envelope encryption.
Many services enable encryption at rest by default, so candidates stop at 'encrypted' and ignore who controls the key, which determines the actual risk posture.
What to do instead
For every data-protection question, check three things: encryption in transit, encryption at rest, and key custody (provider-managed vs customer-managed vs external/HYOK). The correct answer usually hinges on key custody and rotation, not on whether encryption exists.
Answering network-segmentation questions with a single control (e.g., 'put it in a private subnet') rather than layering security groups, NACLs, routing, and egress controls, and misreading stateful vs stateless behavior.
Candidates learn one control well and reach for it universally, and they mix up stateful security groups with stateless network ACLs when reasoning about return traffic.
What to do instead
For segmentation scenarios, enumerate each layer's job: subnet routing isolates, security group filters statefully at the instance, NACL filters statelessly at the subnet, egress controls outbound. Predict the return-traffic behavior for each before choosing.
Treating logging as 'turn on CloudTrail/flow logs' and stopping there, without addressing log aggregation, retention, integrity, centralized accounts, and alerting on the events that matter.
Candidates equate monitoring with enabling a service, because the console makes it a checkbox, and they skip the operational pipeline that makes logs useful in an investigation.
What to do instead
For monitoring questions, trace the full path: source logs, central aggregation account, immutable storage with retention, detection rules, and alert routing. If an answer stops at 'enable logging', it is usually incomplete.
Describing incident response as 'isolate the instance and delete it' without preserving evidence, following the containment/eradication/recovery sequence, or accounting for cloud-specific artifacts like snapshots, metadata, and API audit trails.
On-premises instincts dominate, and candidates prioritize restoring service over evidentiary integrity, missing that cloud IR depends on API-level evidence and snapshotting before termination.
What to do instead
Memorize the IR phases and, for cloud, the evidence-preservation step: snapshot volumes, capture metadata and logs, restrict credentials, then contain. Reject answers that destroy the resource before evidence is captured.
Treating vendor risk as a one-time procurement check, selecting 'review the SOC 2 report once' instead of continuous monitoring, right-to-audit clauses, subprocessor tracking, and exit/portability planning.
Candidates map vendor management to a checkbox audit activity and underestimate the ongoing obligations of cloud concentration risk and fourth-party exposure.
What to do instead
For vendor questions, look for the answer that includes ongoing assurance (periodic reports, continuous monitoring), contractual levers (audit rights, SLAs, breach notification), subprocessor visibility, and a documented exit strategy. One-time review answers are usually wrong.
Answering governance questions with a technical control when the scenario calls for policy, and vice versa - e.g., proposing a firewall for a data-classification or acceptable-use problem, or proposing a policy document for a misconfiguration that needs a technical guardrail.
Candidates sort questions by surface keywords rather than by the layer of the problem, and the exam deliberately mixes governance, risk, and technical framings of similar scenarios.
What to do instead
Before answering, classify the problem: is it a decision-rights/policy gap, a risk-assessment gap, or a control-implementation gap? Match the answer to that layer, and prefer preventive technical guardrails (SCPs, policy-as-code) when the scenario describes repeated human misconfiguration.