CCSK common mistakes
CCSK · Understand the traps and how to avoid them.
When a stem names a specific component (guest OS, hypervisor, function runtime, object in a bucket), the candidate answers from the memorised slogan 'provider secures the cloud, customer secures what's in it' instead of resolving the split for the service model described - for example saying the provider patches the guest OS of an IaaS VM, or that the customer configures the hypervisor.
The slogan is the most repeated line in cloud security and is only true at its original level of abstraction; on-premises habits and consumer-cloud experience both push toward a fixed split, and candidates rarely practise resolving it component by component.
What to do instead
Before reading the options, write down (a) the deployment model, (b) the service model, (c) the exact component named, then assign it. Memorise the invariants: data classification, identity, access policy and tenant configuration stay customer tasks in every model; the guest OS is customer-patched in IaaS but provider-patched in PaaS and SaaS; the hypervisor is always the provider's.
Treating CSA's publications as interchangeable - describing the CAIQ as an audit report or attestation, calling the CCM a certification, or asserting that STAR Level 1 means a third-party-audited provider.
CCM, CAIQ, STAR, the Security Guidance and ISO/IEC 27017/27018 all sit under the same CSA banner and appear in the same paragraphs of study material, so they collapse into one blurry 'CSA compliance thing'.
What to do instead
Anchor one sentence per artifact: Security Guidance = best-practice document organised into domains; CCM = catalogue of control specifications across 17 control domains; CAIQ = self-assessment questionnaire whose answers map to CCM controls; STAR = programme in which Level 1 is self-assessment, Level 2 is a third-party audit and Level 3 is continuous assessment; ISO/IEC 27017 and 27018 are certifications, not CSA documents.
Answering governance questions with a compliance artifact - choosing 'obtain the provider's SOC 2 report' or 'map the service to ISO 27001' when the stem is really asking who decides, who is accountable, or how cloud is structured inside the organisation.
Governance and compliance are used interchangeably in vendor marketing, and auditable documents are the easiest things to name, so they become the default answer whenever the word 'governance' appears.
What to do instead
Separate the concepts: governance = decision rights and accountability, the policy hierarchy (policy, standard, procedure, guideline), defined roles such as cloud service owner and cloud security architect, plus portfolio and provider management; compliance = evidence that requirements are met. Keep provider reports for options about assurance evidence and look for a policy, role or ownership answer when the stem talks about authority or decision-making.
Using OAuth 2.0 and OpenID Connect interchangeably for authentication, or saying SAML issues access tokens for API authorisation, when asked how a user or workload is authenticated or how delegated access is granted.
Sign-in buttons are commonly labelled 'Log in with X, powered by OAuth', and all three protocols appear together in federation discussions, so the distinction between proving identity and granting delegated access is lost.
What to do instead
Hold three one-liners: SAML 2.0 = XML assertions for browser-based SSO and federation; OAuth 2.0 = delegated authorisation that issues access tokens and does not authenticate the user; OpenID Connect = identity layer on top of OAuth 2.0 that adds an ID token (JWT) and authenticates the user. Add SCIM for cross-domain identity provisioning, and remember that federation is not provisioning.
Assuming the provider's native control-plane logs are the customer's complete monitoring story - answering that no additional logging is needed for an IaaS workload, or that the provider is responsible for detecting attacks on the customer's application.
Provider consoles present rich dashboards and 'the provider logs everything' is a comfortable assumption; candidates underestimate that provider logs are scoped to the provider's own plane and that the customer must both enable and export them.
What to do instead
Split monitoring by layer and state who produces each: the provider supplies control-plane/API audit logs and infrastructure telemetry; the customer enables them, adds OS, application, data-access and network-flow logging, centralises into a SIEM, writes detections and alerting, and protects log integrity and retention. Remember logs are customer data and must be exported and retained independently of the workload's lifecycle.
Mixing up stateful instance-level firewalling with stateless subnet-level filtering (security groups vs network ACLs), placing a WAF where a network control is wanted, or stating that VPC/VNet peering or a private endpoint carries traffic over the public internet.
The controls overlap in purpose, each provider renames them, and 'private connection' sounds like a tunnel over the internet to anyone who has not drawn the actual packet path.
What to do instead
Learn properties, not brand names: stateful, allow-only rules attached to an instance/ENI versus stateless rules supporting allow and deny attached to a subnet; WAF is application-layer HTTP content inspection and no substitute for network filtering. For connectivity, know that peering and private endpoints keep traffic on the provider backbone and off the internet, and that peering is non-transitive so a transit hub is needed for multi-site meshes.
Applying VM patching logic to containers and functions - saying the customer patches the host OS of a managed container service, or that the provider is responsible for a function's third-party libraries and its execution role.
'Workload' is treated as a single category, and the shared-responsibility question is answered on autopilot from the IaaS case the candidate studied most.
What to do instead
Trace the boundary explicitly: for managed orchestration the provider patches the control plane and, on managed nodes, the host OS, while the customer owns the image, base-image currency, application dependencies and cluster/RBAC configuration; with self-managed nodes the customer also owns the host OS. For functions the provider owns the runtime and physical host, while the customer owns the code, dependencies, timeout/memory configuration and the execution role's permissions.
Answering that data is 'protected because it is encrypted at rest' without asking who holds the keys and who can reach plaintext, and using DLP, CASB, tokenisation and encryption as if they were synonyms.
Encryption is taught as a checkbox, so the existence of ciphertext gets equated with control of the data, and key custody, key residency and provider administrative access never enter the reasoning.
What to do instead
For each data question resolve three things separately: where the ciphertext lives, who controls the keys (provider-managed, customer-managed KMS, BYOK/HYOK, client-side), and who can obtain plaintext (provider operators, support access, a compromised tenant administrator). Keep the tool definitions distinct: encryption renders data unreadable; tokenisation substitutes non-sensitive surrogates with the mapping held elsewhere; DLP detects or masks sensitive content; CASB is a policy enforcement point between users and cloud services; key management is a separate control with its own availability risk.
Matching the wrong testing technique to the stem - selecting DAST when the question describes reviewing source or open-source dependencies, or claiming SAST finds runtime configuration errors in a deployed environment.
SAST, DAST, SCA, IAST and RASP are acronyms memorised as one table, and exam stems describe the activity rather than naming the acronym, so pattern-matching on keywords fails.
What to do instead
Map technique to what it can actually see: SAST reads source or bytecode without executing (white box, early, higher false positives); DAST probes a running application from outside (black box, no source needed); SCA inventories third-party libraries and licences; IAST instruments the running application from inside; RASP blocks at runtime in production. Dependency or licence language means SCA; a live URL with no source access means DAST.
Applying on-premises incident response mechanics in the cloud - proposing to power off or reimage a suspected instance as the first containment step, assuming disk imaging is the only evidence method, or assuming the provider will investigate the customer's workload for them.
'Pull the plug and take the disk' is deeply practised, the loss of volatile state, instance-store data and log streams on termination is not intuitive, and the provider's scale creates a false expectation of managed forensics.
What to do instead
Adapt the phases: preserve first by snapshotting volumes, capturing memory where supported, exporting and copying logs into a separate account, and recording instance metadata and security-group state; then contain through the API (revoke and rotate credentials, remove the instance from the network via security groups or a quarantine subnet) rather than destroying evidence; rebuild from known-good images instead of cleaning in place. Know the boundary - the provider secures its own infrastructure and may give log access and support, but investigating the customer's workload and meeting notification obligations remain the customer's. For resilience questions, keep RTO (tolerable downtime) and RPO (tolerable data loss) explicit and remember multi-AZ availability is not disaster recovery.