Use this cheat sheet for Kubernetes and Cloud Native Security Associate (KCSA) after you know Kubernetes basics and need sharper security decisions. KCSA questions usually ask where risk enters the platform and which control reduces it without pretending one setting secures the whole cluster.
KCSA answer sequence
Use this when the stem mixes layer, asset, preventive control, detective control, or operations.
flowchart TD
S["Scenario"] --> L["Locate the layer"]
L --> A["Identify the asset at risk"]
A --> C["Choose preventive, detective, or corrective control"]
C --> V["Verify with scope and evidence"]
Read every KCSA question in this order
- Locate the layer: cloud, cluster, node, runtime, image, workload, network, identity, data, or audit.
- Identify the asset at risk: API access, secrets, workload identity, image integrity, traffic, node access, or evidence.
- Choose preventive, detective, or corrective control based on the stem.
- Scope the control to namespace, cluster, repository, registry, pipeline, or organization.
- Reject answers that harden one layer while leaving the stated exposure open.
Cloud native security model
| Layer |
Security question to ask |
| cloud provider or infrastructure |
who can create, reach, or modify the cluster and nodes? |
| control plane |
how are API access, etcd data, admission, and audit protected? |
| node and runtime |
are host access, kubelet exposure, runtime isolation, and patching controlled? |
| workload |
can pods run privileged, mount sensitive paths, or escape expected boundaries? |
| image and supply chain |
is the image trusted, scanned, signed, and built from controlled sources? |
| network |
which workloads can talk, and is ingress or egress constrained? |
| operations |
can the team detect, contain, recover, and prove what happened? |
Identity and RBAC
| Requirement |
Strong answer pattern |
| workload needs Kubernetes API access |
service account with only required verbs and resources |
| team needs namespace work |
Role plus RoleBinding scoped to the namespace |
| platform admin needs cluster-wide access |
ClusterRole only when cluster scope is truly required |
| reduce blast radius |
split duties by namespace, resource, verb, and subject |
| investigate overpermission |
review bindings, groups, service accounts, and inherited permissions |
Admission, policy, and pod hardening
| Control |
What it prevents |
| admission policy |
unsafe workloads before they are accepted by the API server |
| Pod Security Standards |
privileged pods, unsafe host access, and risky container settings |
| securityContext |
privilege escalation, user identity, capabilities, filesystem behavior, and seccomp profile |
| resource quotas and limits |
noisy-neighbor and resource exhaustion risks |
| namespace policy |
consistent baseline for groups of workloads |
Secrets and sensitive data
| Bad answer pattern |
Better instinct |
| put secrets in ConfigMaps |
use Secrets or external secret management with strict access |
| remove exposed secret from YAML only |
rotate, revoke, investigate, and prevent recurrence |
| log every request for debugging |
avoid leaking tokens, keys, PII, and retrieved secret values |
| assume encoded equals encrypted |
distinguish base64 representation from encryption and access control |
| give broad secret read access |
scope RBAC and workload identity to the minimum required secret |
Image and supply-chain security
| Requirement |
Start with |
| reduce vulnerable images |
scan images and base images, then patch or replace |
| prevent unknown images |
approved registries, admission policy, image signing, and provenance |
| protect build pipeline |
least-privilege CI tokens, secret handling, dependency review, and artifact integrity |
| prove image source |
signature, digest pinning, software bill of materials, and build metadata |
| respond to vulnerable dependency |
assess exposure, update safely, redeploy, and verify runtime state |
Network and runtime triage
| Scenario |
Check first |
| workload should be isolated |
namespace labels, pod labels, NetworkPolicy ingress and egress rules, and CNI support |
| public endpoint is too broad |
ingress rules, load balancer exposure, TLS, authentication, and allowed sources |
| suspicious pod behavior |
runtime alerts, process activity, outbound traffic, mounted secrets, and image provenance |
| node compromise concern |
cordon, drain when appropriate, preserve evidence, rebuild from trusted image, rotate credentials |
| service mesh option appears |
match it to mTLS, traffic policy, identity, telemetry, or zero-trust needs |
Audit, compliance, and incident response
| Need |
Strong answer pattern |
| know who did what |
audit logs, API server events, identity context, and retention |
| handle suspected compromise |
contain, preserve evidence, scope impact, rotate secrets, recover, and document |
| meet compliance expectations |
policy, access review, logging, encryption, vulnerability management, and evidence |
| reduce repeated findings |
automate policy checks in admission and CI/CD, not just manual reviews |
| prove remediation |
show new policy, clean scan, rotated secret, fixed workload, and monitoring evidence |
Common traps
| Trap |
Better instinct |
| cluster-admin for convenience |
bind only the verbs and resources required |
| network policy assumed active |
verify CNI support and default ingress/egress behavior |
| secret deleted from Git only |
rotate the credential and investigate use |
| image scan equals secure runtime |
also consider admission, signing, least privilege, and runtime monitoring |
| incident cleanup before evidence |
preserve facts before deleting compromised resources when feasible |
Final 15-minute review
| If the stem says… |
Start here |
| least privilege |
RBAC subject, scope, verbs, resources, and service account |
| unsafe workload |
admission policy, pod security, securityContext, and namespace defaults |
| exposed credential |
revoke, rotate, remove, investigate, and prevent |
| untrusted image |
registry, scan, signature, digest, provenance, and admission |
| lateral movement |
network policy, identity, service mesh, and runtime detection |
| compliance or audit |
logs, retention, policy, evidence, access review, and ownership |
Practice fit
Use IT Mastery for the exact product route, practice status, spaced review when available, and close-answer explanation practice as coverage expands.
One-line decision rule
KCSA answers should reduce a specific cloud native risk at the right layer, with least privilege, policy enforcement, detection, and evidence.