CSPM common mistakes
CSPM · Understand the traps and how to avoid them.
Treating cloud security as a network-perimeter problem: approving designs that rely on firewalls, VPNs, and private subnets as the primary control while leaving identities over-privileged and data unencrypted at rest, then failing scenario items that ask what happens once a credential leaks.
Most candidates come from traditional infrastructure or on-premises security backgrounds, where the perimeter is the dominant mental model. The shared responsibility model inverts this, but the habit is deeply ingrained and exam scenarios are deliberately written so perimeter controls look reassuring.
What to do instead
Before answering any control-selection question, ask 'who can authenticate to this resource and what can that identity do?' If the answer is broader than the workload needs, the correct answer is almost always an identity or authorization control, not a network control. Practice rewriting each scenario in terms of principal, action, resource, and condition.
Memorizing that a given cloud service is 'secure' or 'compliant' as a label rather than reasoning about its configuration surface, so the candidate picks the managed service as automatically correct even when the scenario describes a misconfiguration inside it.
Vendor marketing and certification badges create a shortcut heuristic: managed equals safe. Exam items exploit this by describing a managed service with a public bucket policy, an overly permissive trust relationship, or logging disabled.
What to do instead
For every managed service you study, list its three or four most consequential configuration knobs (public access, encryption key ownership, logging destination, cross-account trust) and what the insecure default looks like. Answer based on the described configuration, never the service name.
Confusing encryption at rest with encryption in transit and with key management, then selecting 'enable encryption' as the remedy for a scenario that is actually about key custody, rotation, or cross-account access to a customer-managed key.
The word 'encryption' appears in many answer options and feels universally correct. Candidates stop reading once they see it and miss that the scenario's risk is who controls the key or whether the key policy allows the wrong principal.
What to do instead
Classify every encryption question into one of three buckets: data state (at rest vs in transit), key custody (provider-managed vs customer-managed vs external), and key policy/rotation. The answer must match the bucket the scenario describes. Write the bucket name next to the option before choosing.
Designing or evaluating a control that only detects problems (logging, alerting, posture scanning) when the scenario asks for prevention, or vice versa, and choosing the more impressive-sounding control regardless of which side of the detect/prevent line the requirement sits on.
Detection tooling is heavily marketed and easy to describe, so it dominates candidates' mental catalog. Scenario stems use verbs like 'prevent', 'block', 'ensure cannot', or 'detect and respond within' that map precisely to one category.
What to do instead
Underline the requirement verb in every stem and tag it P (prevent), D (detect), R (respond), or G (govern). Eliminate options whose category does not match the tag before comparing quality. If two options match, prefer the one that also produces evidence for audit.
Applying a single-account mindset to multi-account or multi-tenant scenarios: proposing per-account policies, per-account logging, and per-account guardrails instead of organization-level policy, centralized logging, and delegated administration.
Lab environments and tutorials usually use one account, so candidates default to the tools they have practiced. CSPM exam scenarios frequently describe dozens of accounts and expect the answer to scale administratively.
What to do instead
When a stem mentions more than one account, subscription, project, or tenant, immediately eliminate any option that requires repeating an action per account. Favor service control policies, organization policy constraints, centralized log archives, and cross-account roles. Practice sketching a landing-zone diagram from memory.
Treating identity and access management as a binary of 'has permission' or 'does not', ignoring privilege escalation paths through role chaining, trust policies, service-linked roles, and permission to modify policies or create credentials.
Candidates study permission lists rather than permission graphs. Escalation primitives like attaching policies, passing roles, or creating access keys look harmless in isolation and are easy to overlook under time pressure.
What to do instead
Learn the short list of escalation primitives per provider (policy attachment, role passing, function creation with an execution role, credential creation, trust-policy editing). For any IAM scenario, trace a two-hop path: what can this principal do directly, and what can it become? If either hop reaches admin, the finding is critical.
Answering data-protection questions by classifying data as 'sensitive' in the abstract without tying the classification to a concrete handling requirement such as retention period, residency, masking, or deletion verification.
Classification frameworks are taught as labeling exercises, so candidates stop at the label. Exam items often give a regulatory or contractual constraint and expect the candidate to translate it into a technical control.
What to do instead
For each data class you define, write the four handling rules: who may access, where it may reside, how long it is kept, and how deletion is proven. In scenarios, locate the constraint sentence first, then choose the control that enforces that specific rule rather than a generic 'encrypt and monitor'.
Proposing a remediation that fixes the symptom in one resource without addressing the systemic cause, such as manually closing a public storage bucket instead of fixing the policy-as-code pipeline or the guardrail that allowed it.
Incident-response reflexes reward immediate containment, and candidates carry that reflex into governance questions. CSPM scenarios often ask what to change so the class of issue cannot recur.
What to do instead
Read whether the stem asks for containment, eradication, or prevention of recurrence. For recurrence questions, the answer must change a reusable artifact: policy as code, a guardrail, a template, or a review gate. If an option only names a single resource, it is usually the distractor.
Ignoring the shared responsibility boundary for the specific service model in the scenario, for example assuming the provider handles patching for a container or serverless workload, or assuming the customer must patch managed database engines.
The boundary shifts between IaaS, PaaS, containers, and serverless, and candidates memorize one diagram instead of reasoning per service. Exam items pick service models where the intuitive answer is wrong.
What to do instead
Build a table with rows for compute, network, storage, identity, and runtime, and columns for IaaS, containers, serverless, and SaaS, marking provider versus customer. Before answering, identify the service model from the stem and read the row the question is about. Never answer from a single memorized split.
Choosing a monitoring or incident-response answer that generates alerts but never closes the loop: no defined severity, no owner, no escalation path, no post-incident control change, so the response plan would not actually reduce risk.
Candidates equate visibility with security and stop at 'enable logging and alerting'. Mature response questions require triage, ownership, and feedback into prevention, which is harder to articulate under time pressure.
What to do instead
For every response option, check four boxes: detection source, triage criteria, accountable owner, and the preventive change that follows. Reject any option missing two or more. Memorize a one-line incident lifecycle (detect, triage, contain, eradicate, recover, learn) and map options onto it explicitly.
Spending disproportionate time on recall-heavy trivia such as exact default timeout values or minor API limits while leaving scenario-based judgment items under-rehearsed, resulting in running out of time or rushing the highest-value questions.
Trivia feels productive to study because it is easy to self-test, and it produces a false sense of readiness. Scenario items require practice in elimination and reasoning, which candidates postpone.
What to do instead
Budget study time so at least two-thirds goes to scenario practice with timed sets. For trivia, learn only values that change a decision (default retention, default public-access settings, key rotation defaults). In the exam, flag and skip any item that requires a number you do not know within thirty seconds, and return only if time remains.