KCSA common mistakes
KCSA · Understand the traps and how to avoid them.
Treating the '4Cs' (Cloud, Cluster, Container, Code) as four separate checklists and answering questions about a control without naming which layer owns it, so answers drift toward the wrong layer (e.g., attributing RBAC to the container layer).
The overview material is short and candidates skim it, then focus all study on kubectl-level objects. Exam items often describe a control and ask where responsibility sits, and without a firm layer model candidates default to 'cluster' for everything.
What to do instead
Build a one-page mapping and rehearse it: Cloud = provider IAM, network, host/VM, managed control plane; Cluster = API server, etcd, kubelet, RBAC, admission, network policy; Container = image contents, runtime isolation, seccomp/capabilities, read-only rootfs; Code = app secrets handling, TLS, dependency hygiene. For every practice question, write the layer name before choosing the answer.
Assuming the managed control plane shifts etcd, API server, and scheduler hardening to the provider entirely, and answering 'provider responsibility' for items about audit logging configuration, admission controller enablement, or API server flags on a managed service.
Marketing language around managed Kubernetes creates a mental model of 'control plane is not my problem'. In reality the shared-responsibility line varies by service and many control-plane settings remain tenant-configurable.
What to do instead
Learn the split per service model: provider patches and runs control plane hosts; tenant still configures audit policy/webhook, admission plugins where exposed, API server authorization mode options, encryption of secrets at rest, and who can reach the endpoint. When a question names a configurable setting, treat it as tenant-owned.
Answering that the kubelet's read-only port 10255 or an anonymous-auth API server is 'fine because it is bound to localhost', and missing items where the correct answer is to disable anonymous authentication and the read-only port.
Candidates memorize port numbers but not the security posture behind them. The read-only port historically exposed pod and node metadata without authentication, and anonymous auth is enabled by default in some configurations.
What to do instead
Memorize the posture, not just the port: kubelet should have authentication enabled with webhook authorization, anonymous auth disabled, and read-only port disabled (10255 closed, only 10250 serving authenticated traffic). Be able to state why each is dangerous: unauthenticated metadata and log exposure.
Confusing which component talks to etcd and therefore which certificate or credential protects it, e.g., saying kubelets connect directly to etcd or that the controller manager authenticates to etcd with the kubelet client cert.
Component interaction diagrams are studied visually but not rehearsed as a verbal chain, so the direction of calls blurs under exam pressure.
What to do instead
Draw the call graph from memory repeatedly: only the API server talks to etcd; kubelet and kube-proxy talk to the API server; controller-manager and scheduler talk to the API server and watch it. etcd should accept client connections only from the API server, with peer and client TLS. Then answer component questions by tracing the arrow.
Treating a RoleBinding to a ServiceAccount as sufficient isolation, and picking answers that rely on namespace boundaries alone for tenant separation, without network policy, resource quotas, or admission controls.
RBAC is the most visible Kubernetes security topic, so candidates over-weight it and under-weight the fact that namespaces are not a security boundary by default: pods can reach each other across namespaces and cluster-scoped resources are shared.
What to do instead
For isolation questions, require a bundle: RBAC scoped per namespace, NetworkPolicy default-deny with explicit allows, ResourceQuota and LimitRange, Pod Security Admission labels, and restricted access to cluster-scoped objects. If an answer offers only RBAC, look for the option that adds network and admission controls.
Choosing 'create a PodSecurityPolicy' or describing PSP as the current mechanism for restricting privileged pods, rather than Pod Security Admission with namespace labels (privileged, baseline, restricted).
Older study material and blog posts still center PSP, which was deprecated and removed. Candidates who learned from legacy sources answer with a removed feature.
What to do instead
Anchor on the current model: Pod Security Standards enforced via Pod Security Admission using namespace labels (pod-security.kubernetes.io/enforce), with audit and warn modes. Know that PSP is removed and that admission webhooks (e.g., policy engines) are the extension path for finer control.
Describing the threat model only as 'attackers break in' and missing the specific attack surfaces the exam tests: compromised container image supply chain, exposed kubelet or dashboard, over-privileged service account tokens mounted into pods, and lateral movement via cluster network.
Threat model content is conceptual and candidates read it passively, so they cannot map a described scenario to the named threat or the standard mitigation.
What to do instead
Build a table of threat to surface to mitigation: malicious image → image scanning, signing, admission verification; stolen SA token → disable automount, bound tokens, least-privilege RBAC; exposed dashboard/kubelet → no anonymous access, network restriction; lateral movement → network policy and namespace segmentation. Practice naming the threat before the fix.
Answering that a pod's service account token is short-lived and audience-bound by default in all cases, or conversely that tokens never expire, without distinguishing legacy Secret-based tokens from bound projected tokens.
The token model changed: legacy long-lived Secret tokens versus bound service account tokens with expiry and audience. Candidates learn one version and apply it universally.
What to do instead
State both: legacy tokens stored in Secrets are long-lived and not audience-restricted; bound tokens are projected, time-limited, and audience-scoped. Security answer: disable automount where not needed (automountServiceAccountToken: false), use bound tokens, and keep RBAC minimal. Match the answer to the token type the question describes.
Ignoring host-level and runtime controls in platform security answers: not mentioning seccomp profiles, Linux capabilities dropping, read-only root filesystems, AppArmor/SELinux, or runtime threat detection, and answering with Kubernetes-object controls only.
Candidates study the API surface and forget the node and container runtime layer, which is where many real escapes are prevented. These controls are also frequently the distinguishing option in a question.
What to do instead
Memorize a container hardening checklist: runAsNonRoot, allowPrivilegeEscalation false, drop ALL capabilities and add only needed ones, read-only root filesystem, seccomp RuntimeDefault, no hostPath or hostNetwork, and runtime detection on the node. When a question asks how to limit the impact of a container compromise, prefer these over RBAC options.
Treating compliance frameworks as interchangeable, e.g., answering that PCI DSS covers protected health information or that a CIS Benchmark is a certification, and failing to distinguish control frameworks from audit attestations.
Framework names are memorized as acronyms without scope. Candidates also conflate 'we ran a benchmark scan' with 'we are compliant', which the exam tests directly.
What to do instead
Learn scope in one line each: PCI DSS = cardholder data; HIPAA = PHI in US healthcare; SOC 2 = trust services criteria attestation; ISO 27001 = ISMS certification; CIS Benchmarks = prescriptive configuration baselines, not certifications; NIST 800-53/CSF = control catalogs and risk framework. Then separate 'technical baseline' from 'audit evidence' when answering.