CSPCC common mistakes
CSPCC · Understand the traps and how to avoid them.
When asked to design a cloud architecture for a given scenario, the candidate immediately selects a multi-region active-active deployment without first clarifying recovery point objective (RPO), recovery time objective (RTO), budget, and data residency constraints.
Candidates often equate 'high availability' with 'multi-region active-active' and assume it is always the best answer. They may also overlook that the scenario's business requirements might be satisfied by a less complex and cheaper design, such as a single-region multi-AZ deployment with backups.
What to do instead
Before choosing a topology, explicitly extract the RPO, RTO, cost ceiling, and compliance constraints from the scenario. Map each option to those constraints: single-region multi-AZ for RTO in minutes, multi-region active-passive for RTO in hours, and active-active only when near-zero RTO and RPO are stated. Eliminate options that violate a stated constraint even if they are technically superior.
Treating the cloud provider's shared responsibility model as a binary split: assuming the provider secures 'the cloud' and the customer secures 'everything in the cloud' without differentiating service models (IaaS, PaaS, SaaS) and specific controls such as host OS patching, network controls, and identity management.
The shared responsibility model is frequently summarized as a simple division, and candidates memorize that summary without learning how responsibilities shift by service model. In the exam, questions often present a specific service (e.g., a managed database or serverless function) and ask who is responsible for a control like patching or network segmentation.
What to do instead
For each service model, create a responsibility matrix. For IaaS, the customer is responsible for guest OS patching, application security, and identity; for PaaS, the provider handles OS and runtime patching while the customer manages application code, identity, and data; for SaaS, the provider handles most of the stack, but the customer remains responsible for data classification, access management, and configuration of SaaS security settings. Practice classifying controls as 'provider', 'customer', or 'shared' for common services.
Designing identity and access management (IAM) policies that grant broad permissions (e.g., wildcard actions or resources) because the candidate focuses only on making the scenario work functionally, not on least privilege.
Candidates often reason from the perspective of 'what permissions are needed for this task to succeed' and choose the simplest policy that allows the action. They may also be unfamiliar with how to scope permissions using conditions, resource tags, or permission boundaries, and default to broad grants.
What to do instead
When evaluating IAM policy options, apply a least-privilege checklist: Does the policy specify exact actions? Does it restrict resources by ARN or tag condition? Does it include conditions such as source IP, MFA, or time? Reject any option that uses '*' for actions or resources unless the scenario explicitly requires a broad administrative role and justifies it. Also consider permission boundaries and service control policies as guardrails.
Choosing encryption at rest as the primary control for data protection without addressing key management lifecycle, access to keys, and encryption in transit, or assuming that enabling default encryption satisfies all data protection requirements.
Candidates often equate 'encryption enabled' with 'data is secure' and overlook that encryption is only effective if keys are properly managed and access to keys is restricted. Exam questions may describe a scenario where data is encrypted but a broad key policy allows any principal to decrypt, or where data in transit between services is unencrypted.
What to do instead
For any data protection question, evaluate the full lifecycle: classification, encryption at rest, encryption in transit, key management (customer-managed vs. provider-managed keys), key rotation, and access controls on keys. Check whether the proposed solution restricts key usage to authorized principals and whether it covers data in transit between all relevant components. Reject options that encrypt data but leave key policies overly permissive.
Designing network security controls (security groups, NACLs, firewalls) based on a flat network model, without segmenting workloads by sensitivity or function, and without considering east-west traffic between cloud resources.
Candidates often focus on perimeter security (north-south traffic) and forget that cloud networks are software-defined and internal traffic between instances, containers, and services can be a major attack path. They may also default to allowing broad internal CIDR ranges because 'it's internal'.
What to do instead
Apply a zero-trust segmentation approach: group resources by sensitivity and function into separate subnets or VPCs, and define security group rules that reference other security groups rather than CIDR blocks where possible. Explicitly consider east-west traffic controls, such as service meshes, private endpoints, and network policies. When evaluating options, reject designs that allow unrestricted internal traffic or that rely solely on perimeter firewalls.
In secure DevOps scenarios, embedding secrets (API keys, passwords, tokens) directly in source code, CI/CD pipeline variables, or container images, and treating code scanning as a one-time gate rather than an ongoing control.
Candidates may be unfamiliar with secrets management services and assume that pipeline variables are sufficiently protected. They may also view security scanning as a checkbox at the end of the pipeline rather than integrating it throughout the development lifecycle.
What to do instead
For any CI/CD design question, require a dedicated secrets management solution (e.g., vault service) with short-lived credentials and automatic rotation. Ensure secrets are never stored in code or images. Integrate static application security testing (SAST), software composition analysis (SCA), and dynamic testing (DAST) as automated stages in the pipeline, with policy-as-code gates that block builds on critical findings. Reject options that rely on manual reviews alone or that store secrets in environment variables without a vault.
When designing logging and monitoring for cloud security operations, collecting logs but not centralizing them, not defining retention, and not correlating events across services to detect incidents.
Candidates often focus on enabling logging at the resource level and assume that logs are sufficient for incident response. They may overlook the need for a centralized log archive with integrity controls, retention policies aligned with compliance, and correlation rules (e.g., SIEM) to identify multi-step attacks.
What to do instead
Design a logging architecture with: (1) centralized log aggregation across accounts and regions, (2) immutable storage with retention based on legal and compliance requirements, (3) real-time correlation and alerting using a SIEM or native security analytics service, and (4) integration with incident response workflows. When evaluating options, prefer designs that include cross-service correlation and automated alerting over those that only enable logging.
Assuming that using a cloud provider's compliance certifications (e.g., SOC 2, ISO 27001, FedRAMP) automatically makes the customer's workload compliant, without verifying scope, inheritance, and customer responsibilities.
Candidates often treat provider certifications as a blanket assurance and do not realize that certifications cover the provider's infrastructure and services, not the customer's configurations, data handling, or application controls. Exam questions may ask what additional actions the customer must take to achieve compliance.
What to do instead
For compliance questions, distinguish between provider attestations and customer obligations. Identify which controls are inherited from the provider, which are shared, and which are customer-only. Require evidence such as provider compliance reports, customer-configured controls (e.g., encryption, access logging), and independent audits of the customer's workload. Reject options that claim provider certification alone satisfies the customer's compliance requirement.
Designing incident response for cloud environments using traditional on-premises assumptions, such as expecting to physically isolate a server or relying on network forensics that are not available in a cloud model, and failing to account for account-level containment and evidence preservation.
Candidates may transfer on-premises incident response playbooks directly to cloud scenarios without adapting to cloud-specific capabilities and constraints, such as the ability to snapshot volumes, isolate instances via security groups, or revoke credentials centrally, but also the risk of destroying evidence by terminating instances.
What to do instead
Adapt incident response playbooks to cloud primitives: use security group isolation, IAM credential revocation, and resource tagging for containment; preserve evidence by snapshotting volumes and exporting logs before remediation; and use infrastructure-as-code to rebuild known-good environments. When evaluating options, prefer those that include evidence preservation and account-level containment over those that simply terminate resources.
When evaluating cloud architecture options, ignoring vendor lock-in and portability considerations entirely, or conversely over-prioritizing portability at the expense of using native security controls.
Candidates may see 'multi-cloud' or 'portable' as inherently good and choose options that avoid native services, even when native services provide stronger security integration. Alternatively, they may ignore lock-in risks when the scenario explicitly requires exit strategy or data portability.
What to do instead
Balance portability with security and operational efficiency based on the scenario's stated priorities. If the scenario emphasizes regulatory exit strategy or multi-cloud, include abstraction layers and open standards; if it emphasizes security and rapid iteration, prefer native integrated services with compensating controls for lock-in (e.g., data export, infrastructure-as-code). Reject options that dogmatically avoid native services without justification or that ignore a stated portability requirement.