CCSP common mistakes
CCSP · Understand the traps and how to avoid them.
Reading every scenario from the cloud provider's point of view - describing what the provider does to secure the physical layer, hypervisor, or region - instead of what the organisation adopting the service must do.
Candidates study from vendor architecture whitepapers and certification material written for provider staff, so the provider's control set gets memorised first and becomes the default lens for every question stem.
What to do instead
Before answering, write down the service model (IaaS/PaaS/SaaS) and the deployment model, then explicitly ask 'who owns this control layer?' Answer only with the adopting organisation's residual responsibilities unless the stem names the provider as the actor.
Treating multi-AZ deployment, auto-scaling, or load balancing as a disaster recovery strategy, and using RTO and RPO interchangeably in scenario answers.
High availability and disaster recovery both sound like 'keeping the service up', and in the cloud they are often implemented with the same building blocks, so the two blend together under exam pressure.
What to do instead
Anchor on definitions: RTO is maximum tolerable downtime, RPO is maximum tolerable data loss. Availability keeps a service running through a component failure; DR restores service after loss of a whole site or region. Classify each scenario by which of the four DR patterns it describes - backup and restore, pilot light, warm standby, multi-site - before selecting an option.
Selecting the strongest available cryptographic control or 'encrypt everything' as the answer, without first identifying whether the data in question is at rest, in transit, or in use, and where it sits in its lifecycle.
Encryption is the most visible data-security control, so it becomes a reflex answer; the exam instead tests whether the candidate can match a control to a specific data state and lifecycle phase such as creation, storage, use, sharing, archive, and destruction.
What to do instead
Force a two-step habit: label the data state and lifecycle phase stated in the stem, then pick the control that addresses that label. Encrypting data at rest does nothing for data in use, and masking, tokenisation, and DLP each map to different phases.
Assuming the cloud customer keeps custody of encryption keys whenever encryption is enabled, and being unable to distinguish key-management approaches such as provider-managed keys, customer-managed keys held in a cloud KMS, keys held in an external HSM, and client-side encryption.
Vendors describe all four as 'encryption at rest', so candidates treat them as equivalents and miss that the control an organisation can actually assert over key custody, rotation, and revocation differs sharply between them.
What to do instead
Build a four-row comparison table (who generates, who stores, who can revoke, who can read plaintext) and answer key-custody questions from that table rather than from the word 'encrypted'. Remember that only client-side or externally held keys remove the provider's technical ability to decrypt.
Carrying on-premises network mental models into cloud scenarios - assuming an implicit network perimeter, treating a virtual network as a DMZ, and confusing stateful security groups with stateless network ACLs that can deny as well as allow.
Years of firewall-and-DMZ experience produce strong intuitions that do not transfer: cloud networks are software-defined, default to a different baseline, and expose control-plane and metadata endpoints that have no on-premises analogue.
What to do instead
Restate cloud network controls in their own terms before choosing: security groups are instance-level, stateful, allow-only; network ACLs are subnet-level, stateless, and support explicit deny. Always ask whether the metadata service is reachable from the workload, since that is a recurring scenario in this domain.
Answering identity-centred scenarios with network controls - proposing segmentation, VPNs, or firewall rules when the actual exposure described is standing privileges, unrotated credentials, missing federation, or absent multi-factor authentication.
Security training rewards network hardening and it feels like the more rigorous answer, so a stem that mentions lateral movement or compromised credentials triggers a network answer rather than an identity one.
What to do instead
Ask what the attacker actually used. If the entry point was a credential, a role, or a token, the correct control is in the identity plane - least privilege, just-in-time access, federation, MFA, credential rotation. Network controls limit blast radius; they do not fix the credential.
Treating application security questions as generic secure-SDLC questions and overlooking the cloud-specific failure points the stem is really testing: secrets embedded in source or build artifacts, unreviewed infrastructure-as-code changes, CI/CD pipeline and artifact integrity, over-permissive API gateways, and serverless function permissions.
Standard AppSec study material stops at input validation, patching, and code review, so candidates answer correctly for a traditional data centre and miss the build-and-deploy supply chain that cloud delivery introduces.
What to do instead
Add a cloud application checklist to your revision - secrets management outside the repository, IaC scanning and drift detection, pipeline identity and least privilege, API authentication and rate limiting, function-level execution roles - and scan each scenario for which of these is being described.
In incident response scenarios, choosing to terminate and rebuild the compromised instance, or to delete and recreate resources, as the first action rather than preserving volatile evidence and exporting logs first.
Immutable infrastructure is taught as a cloud virtue, so 'destroy and redeploy' feels like the cloud-native correct answer; the question is often testing the order of operations and evidentiary preservation instead.
What to do instead
Sequence every cloud incident the same way: identify and scope, isolate without destroying (quarantine via security groups or snapshot), capture volatile data and export control-plane and data-plane logs to an account the attacker does not control, then rebuild. Rebuild is a recovery step, not a containment step.
Assuming the customer can see the same telemetry the provider sees, or that built-in platform monitoring satisfies logging requirements, and therefore omitting centralised log aggregation, tamper resistance, and retention periods from answers.
The provider console shows useful dashboards, which creates the impression that monitoring is a solved, inherited problem; in reality log export, aggregation, integrity protection, and retention are customer responsibilities in every service model.
What to do instead
For any monitoring scenario, check three things: is the log source exported outside the workload's own account, can the workload or its administrator alter or delete the logs, and does retention meet the compliance obligation stated in the stem. If any answer fails one of these, it is wrong.
Mixing up legal and assurance terminology - calling the cloud provider a data controller when it is acting as processor, ignoring transborder data-flow and jurisdiction constraints, or confusing audit report and framework scope such as SOC 1 versus SOC 2 versus SOC 3, and the ISO/IEC 27017, 27018, and 27701 family.
These artefacts are learned as a list of acronyms rather than as answers to distinct questions (financial controls, security controls, public attestation, cloud-specific controls, personally identifiable information in the cloud, privacy management), so they collapse into one another under exam pressure.
What to do instead
Associate each artefact with the single question it answers and the audience it serves, and drill the controller/processor distinction until it is automatic. When a stem involves personal data, identify the role first; the correct answer usually follows from the role, not from the technology.