CrowdStrike CCCS common mistakes
CrowdStrike CCCS · Understand the traps and how to avoid them.
Treating the shared responsibility model as a single dividing line and assuming everything 'in the cloud' is the provider's problem, so questions about patching guest OS packages, securing container images, or configuring security groups get answered as 'AWS/Azure responsibility'.
Candidates memorize the slogan 'provider secures the cloud, you secure what's in the cloud' without mapping it to concrete layers (IaaS vs PaaS vs SaaS, managed vs unmanaged services). The exam tests the boundary at specific layers, and the slogan alone cannot resolve those items.
What to do instead
Build a layer-by-layer table for IaaS, PaaS, and SaaS covering physical, hypervisor, host OS, guest OS, runtime, application, data, and identity. For each exam item, first identify the service model and the specific asset, then assign ownership. Practice with concrete examples: unpatched kernel in an EC2 instance (customer), hypervisor escape (provider), misconfigured S3 bucket policy (customer), and managed database engine patching (provider).
Choosing 'deploy a WAF' or 'enable encryption' as the answer to architecture questions that actually ask about segmentation, least-privilege network paths, or blast-radius reduction, because the candidate pattern-matches 'security control' to any risk.
Candidates default to familiar perimeter controls instead of reading what the question is testing. Cloud architecture items often hinge on design properties such as isolation between environments, avoiding flat networks, or limiting lateral movement, none of which a WAF addresses.
What to do instead
Before answering, restate the risk in one sentence and ask which control actually changes that risk. Learn the distinct jobs of WAF (HTTP application attacks), security groups (instance-level stateful filtering), NACLs (subnet-level stateless filtering), and network segmentation (blast radius). Reject any option that mitigates a different threat than the one described.
Confusing identity-based policies with resource-based policies and picking either one when a cross-account access scenario requires both sides to allow it.
Candidates learn that 'a policy grants access' and stop there, missing that cross-account access in AWS requires the trusting account's resource policy to grant the principal and the calling account's identity policy to permit the API call. Similar dual-authorization patterns exist in other clouds.
What to do instead
Draw the request path for every access question: principal, identity policy, resource policy, permission boundary, SCP, and session policy. Remember that an explicit deny anywhere overrides all allows, and that SCPs and permission boundaries filter but never grant. Practice cross-account scenarios by writing both policies and confirming each side.
Answering least-privilege questions by picking 'use a wildcard but restrict by condition' or 'create a custom role with broad permissions and audit later' instead of scoping actions and resources.
Wildcards feel pragmatic and conditions feel sophisticated, so candidates overvalue them. The exam rewards precise action and resource scoping plus conditions as a supplement, not a substitute, and treats 'audit later' as detection rather than prevention.
What to do instead
Rank options by how tightly they scope the principal, actions, and resources. Prefer explicit action lists and specific resource ARNs, then add conditions (source IP, MFA, VPC endpoint, tags) as defense in depth. Recognize that a wildcard action with a condition is still broader than a scoped action list and is usually the wrong answer when a scoped option exists.
Treating long-lived access keys and service account credentials as acceptable if they are rotated, rather than identifying workload identity federation or instance roles as the correct design.
On-premises habits carry over: candidates think rotation solves credential risk. Cloud exams consistently prefer eliminating static credentials entirely through workload identity, OIDC federation, or instance metadata roles, and rotation is a weaker control.
What to do instead
When a question mentions credentials stored in code, CI/CD variables, or config files, look first for an option that removes the secret: IAM roles for compute, workload identity federation for external systems, or a secrets manager with short-lived dynamic credentials. Reserve rotation answers for cases where static credentials genuinely cannot be eliminated, and expect those to be distractors.
Assuming endpoint agents installed on cloud VMs provide complete workload protection, and missing that container and serverless workloads need image scanning, admission control, and runtime detection at a different layer.
Candidates transfer their endpoint-security mental model to all workloads. Containers are ephemeral and often immutable, and functions have no persistent host, so host-agent coverage alone leaves gaps the exam explicitly tests.
What to do instead
Map protection to workload type: VMs get host agents plus vulnerability management; containers get registry image scanning, admission policies that block vulnerable or unsigned images, and runtime sensors on nodes; serverless gets function-level permissions review, dependency scanning, and runtime detection. For any workload question, name the workload type first, then select controls that actually operate at that layer.
Answering 'patch the image' as the fix for a vulnerable container already running in production, instead of isolating or terminating the affected workload and rebuilding from a patched image.
Immutable infrastructure principles are easy to state but easy to forget under exam pressure, and 'patch' sounds like the responsible answer. The exam expects candidates to recognize that in-place patching of running containers breaks immutability and leaves drift.
What to do instead
For running vulnerable containers, prefer containment (network isolation, quarantine) followed by replacement with a rebuilt image from a clean base. Reserve in-place remediation for mutable VM workloads. Learn to spot the phrasing that signals immutability, such as 'containers are rebuilt, not modified,' and let it steer the answer.
Believing that private subnets, no public IPs, or a NAT gateway makes a workload unreachable, and therefore skipping egress monitoring, VPC flow log analysis, or private-link exposure review.
Candidates equate 'no inbound path' with 'no network risk.' Egress to the internet, lateral movement inside the VPC, and service endpoints exposed through private connectivity are all real paths the exam probes.
What to do instead
Analyze traffic in both directions. For visibility questions, expect VPC flow logs, DNS logs, and traffic mirroring to be relevant even for private subnets. For exposure questions, check security group egress rules, private link and endpoint policies, peering and transit connections, and whether any resource is reachable from a compromised internal host.
Choosing 'enable GuardDuty' or 'turn on a SIEM' as the answer to a question about detecting a specific behavior, when the question is really asking which telemetry source or detection logic surfaces that behavior.
Candidates conflate tooling with detection content. Managed threat-detection services are useful, but the exam distinguishes between a control that exists and a signal that actually captures the behavior in question, such as process execution, DNS tunneling, or anomalous API calls.
What to do instead
For detection items, name the behavior first, then the telemetry that records it: process and command-line telemetry for execution, DNS query logs for tunneling, cloud audit logs for control-plane anomalies, flow logs for data movement. Match the telemetry to the behavior before considering which product consumes it, and treat 'enable a tool' answers as incomplete unless the tool's data source covers the behavior.
Describing incident response as 'isolate the instance, then delete it' and omitting evidence preservation, scoping, and the order of containment versus eradication, especially for identity-based incidents where the credential, not the host, is the compromised asset.
Candidates memorize a linear IR checklist and apply it uniformly. Cloud incidents often involve compromised identities or API keys where terminating a VM does nothing, and premature deletion destroys the forensic record the exam expects you to preserve.
What to do instead
Classify the incident first: compromised identity, compromised workload, or compromised data path. For identity incidents, disable or rotate the credential, revoke sessions, and review what the principal did before containment. For workload incidents, snapshot or capture memory and logs before termination. Always sequence containment, evidence preservation, eradication, recovery, and lessons learned, and state which step each action belongs to.