Browse Linux Foundation and CNCF Guides

Linux Foundation KCSA Cheat Sheet: Cloud Native Security and Controls

April 24, 2026

Linux Foundation KCSA cheat sheet for cloud native security, controls, traps, and final review.

On this page

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

  1. Locate the layer: cloud, cluster, node, runtime, image, workload, network, identity, data, or audit.
  2. Identify the asset at risk: API access, secrets, workload identity, image integrity, traffic, node access, or evidence.
  3. Choose preventive, detective, or corrective control based on the stem.
  4. Scope the control to namespace, cluster, repository, registry, pipeline, or organization.
  5. 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.

Open the exact IT Mastery route here: KCSA on MasteryExamPrep.

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.

Revised on Sunday, May 10, 2026
Study Plan