KCSA Study Guide: Kubernetes and Cloud Native Security Associate

The KCSA is a 90-minute, multiple-choice exam that tests your understanding of Kubernetes security concepts. You need a 75% to pass. No terminal, no live cluster. Just questions about security primitives, threat models, and the tools that secure cloud native applications.

If you have already passed the CKS, you can pass the KCSA with a weekend of review. If you are starting fresh, expect 4 to 6 weeks of study. The KCSA covers security at a conceptual level. The CKS covers it hands-on. Everything on the KCSA is a subset of what the CKS tests, just at a lower depth.

Who Should Take the KCSA

Take the KCSA if:

• You are pursuing the Kubestronaut title and need all five certs
• You are a security professional learning Kubernetes and want a low-stakes entry point
• You work in compliance, audit, or GRC and need to understand Kubernetes security controls
• You want to test your security knowledge before committing to the CKS

Skip to the CKS if:

• You already hold the CKA and want a security credential that carries weight in hiring
• You work hands-on with Kubernetes clusters and need to prove security skills
• You want the certification that actually differentiates you in job searches

The KCSA costs $250. The CKS costs $445 but requires the CKA and proves hands-on competence. For engineers, the CKS is almost always the better investment. The KCSA exists primarily as a stepping stone or as part of the Kubestronaut path.

KCSA Exam Domains

The KCSA organizes its content around the security lifecycle of cloud native applications. The exact domain weights are not published as precisely as the professional exams, but the Linux Foundation outlines these major areas:

Domain	Focus Areas
Overview of Cloud Native Security	The 4Cs model, threat modeling, defense in depth
Kubernetes Cluster Component Security	API server, etcd, kubelet, control plane hardening
Kubernetes Security Fundamentals	RBAC, Security Contexts, Pod Security Standards, Secrets
Kubernetes Threat Model	Attack surfaces, common vulnerabilities, STRIDE/MITRE
Platform Security	Network security, image security, supply chain
Compliance and Security Frameworks	CIS Benchmarks, NIST, SOC 2, PCI DSS awareness

The single most important concept on the exam is the 4Cs of cloud native security. It is the framework that ties everything else together.

The 4Cs of Cloud Native Security

This model appears throughout the KCSA. Every security topic fits into one of four layers:

Cloud

The outermost layer. Your cloud provider's security controls: IAM roles, network ACLs, encryption at rest, audit logging at the infrastructure level. If the cloud layer is compromised, nothing inside it is safe.

What to know:

• Cloud providers offer IAM (Identity and Access Management) for access control
• Network-level controls (VPCs, security groups) restrict traffic before it reaches Kubernetes
• Encryption at rest protects data on disk (cloud provider managed or customer managed keys)
• Shared responsibility model: the cloud provider secures the infrastructure, you secure your workloads

Cluster

The Kubernetes control plane and its configuration. API server access, etcd encryption, RBAC policies, admission controllers, audit logging.

What to know:

• API server authentication (certificates, tokens, OIDC)
• API server authorization (RBAC is the standard)
• etcd should be encrypted and access-restricted
• Admission controllers validate and mutate requests before they are persisted
• Audit logging records who did what and when

Container

The container image and its runtime configuration. Image scanning, base image selection, container privileges, security contexts.

What to know:

• Use minimal base images (distroless, Alpine) to reduce attack surface
• Scan images for known vulnerabilities (Trivy, Grype)
• Do not run containers as root
• Use read-only root filesystems when possible
• Drop unnecessary Linux capabilities

Code

The application code itself. Input validation, dependency management, secrets handling, secure communication.

What to know:

• Validate and sanitize all inputs
• Keep dependencies updated and scan for vulnerabilities
• Never hardcode secrets in code or container images
• Use TLS for service-to-service communication
• Follow OWASP guidelines for common vulnerability categories

The 4Cs build on each other. A secure application (Code) running in an insecure container is still vulnerable. A secure container running on an insecure cluster is still vulnerable. Security at every layer matters.

Study Plan

Weeks 1 to 2: Kubernetes Security Fundamentals

This is the heaviest section. If you have Kubernetes experience, some of this will be familiar.

RBAC (Role-Based Access Control):

The primary authorization mechanism in Kubernetes. Know these four objects and how they connect:

• Role: Defines permissions within a single namespace (which verbs on which resources)
• ClusterRole: Defines permissions cluster-wide
• RoleBinding: Grants a Role to a user, group, or service account within a namespace
• ClusterRoleBinding: Grants a ClusterRole across the entire cluster

Key principles:

• Follow least privilege. Grant only the permissions a user or service account actually needs.
• Default service accounts have minimal permissions. Do not add permissions to the default service account in any namespace.
• cluster-admin is the most powerful ClusterRole. It should only be bound to administrators.

Security Contexts:

Security Contexts define privilege and access control settings for Pods and containers. Know the key fields:

• runAsUser / runAsGroup: Specify which UID/GID the container process runs as
• runAsNonRoot: true: Prevents the container from running as root
• readOnlyRootFilesystem: true: Makes the container filesystem read-only
• allowPrivilegeEscalation: false: Prevents a child process from gaining more privileges than its parent
• capabilities: Add or drop Linux capabilities (always drop ALL and add back only what you need)

Pod Security Standards:

Kubernetes replaced PodSecurityPolicies (deprecated in 1.21, removed in 1.25) with Pod Security Standards enforced through Pod Security Admission:

• Privileged: No restrictions. For system-level workloads that need full access.
• Baseline: Prevents known privilege escalations. Blocks hostNetwork, hostPID, privileged containers.
• Restricted: Most hardened. Requires running as non-root, dropping all capabilities, using read-only filesystems.

Pod Security Admission enforces these at the namespace level using labels:

• pod-security.kubernetes.io/enforce: Reject Pods that violate
• pod-security.kubernetes.io/warn: Allow but warn
• pod-security.kubernetes.io/audit: Log violations

Secrets Management:

• Kubernetes Secrets are base64-encoded, not encrypted by default
• Enable encryption at rest for Secrets in etcd (EncryptionConfiguration)
• Avoid mounting Secrets as environment variables when possible (they can leak in logs and process listings)
• Consider external secret stores (HashiCorp Vault, AWS Secrets Manager) for sensitive data
• RBAC should restrict who can read Secrets

Network Policies:

• NetworkPolicies control traffic flow between Pods
• By default, all Pods can communicate with all other Pods (flat network)
• Applying any NetworkPolicy to a Pod switches it to default-deny for the selected traffic direction
• Policies specify ingress (incoming) and egress (outgoing) rules
• The CNI plugin must support NetworkPolicies (Calico and Cilium do, basic Flannel does not)

For hands-on details on all these topics, the CKS study guide goes much deeper.

Week 3: Cluster Component Security

API Server security:

• All cluster communication goes through the API server
• Authentication: X.509 certificates, bearer tokens, OpenID Connect
• Authorization: RBAC (primary), Node authorization, Webhook
• Admission control: Validating and mutating webhooks intercept requests after authentication and authorization
• Always use HTTPS. The API server should never be exposed without TLS.

etcd security:

• etcd stores all cluster state including Secrets
• Access should be restricted to the API server only
• Communication should use mutual TLS (mTLS)
• Enable encryption at rest
• Back up etcd regularly and secure the backups

kubelet security:

• The kubelet runs on every node and manages Pods
• Disable anonymous authentication (--anonymous-auth=false)
• Use webhook authorization instead of AlwaysAllow
• Restrict the kubelet API to the control plane

Scheduler and Controller Manager:

• Bind to localhost only (not accessible externally)
• Use secure port configurations
• Enable profiling only in non-production environments

Week 4: Threat Modeling and Attack Surfaces

Kubernetes threat model:

Know the common attack vectors:

• Compromised container: An attacker gains code execution inside a container
• Privilege escalation: Moving from a container to the host, or from a low-privilege to high-privilege role
• Lateral movement: Moving between Pods or namespaces after initial access
• Supply chain attacks: Malicious code injected through compromised base images or dependencies
• Credential theft: Stealing service account tokens, kubeconfig files, or cloud IAM credentials
• API server exploitation: Direct attacks against the Kubernetes API

STRIDE model:

A threat modeling framework. Know what each letter stands for:

• Spoofing: Pretending to be someone else
• Tampering: Modifying data or code
• Repudiation: Denying actions (countered by audit logging)
• Information disclosure: Data leaks
• Denial of Service: Making services unavailable
• Elevation of privilege: Gaining unauthorized access

MITRE ATT&CK for Containers:

A framework mapping known attack techniques to the container and Kubernetes environment. Know that it exists and its purpose: providing a common language for describing attacks and defenses.

Weeks 4 to 5: Platform Security and Supply Chain

Image security:

• Scan images for vulnerabilities before deployment (Trivy is the most common tool)
• Use signed images to verify authenticity
• Only pull from trusted, allowlisted registries
• Use specific image tags or digests, never latest in production
• Keep base images minimal and updated

Supply chain security:

• SBOM (Software Bill of Materials): A list of all components in a container image
• SLSA (Supply-chain Levels for Software Artifacts): A framework for supply chain integrity
• Sigstore/cosign: Tools for signing and verifying container images
• Admission controllers can enforce image policies (only allow signed images, only allow images from specific registries)

Network security beyond NetworkPolicies:

• Service mesh (Istio, Linkerd) provides mTLS between services
• Ingress controllers should terminate TLS
• Egress controls restrict outbound traffic from the cluster
• DNS policies can restrict which external domains Pods can resolve

Week 5 to 6: Compliance and Frameworks

CIS Kubernetes Benchmark:

• A set of security configuration recommendations from the Center for Internet Security
• Covers control plane, worker nodes, policies, and managed services
• Tools like kube-bench automate CIS benchmark checks
• Know that CIS benchmarks exist, what they cover, and that automated tools can check compliance

Other frameworks to know at a high level:

• NIST Cybersecurity Framework: Identify, Protect, Detect, Respond, Recover
• SOC 2: Trust service criteria for service organizations (security, availability, processing integrity, confidentiality, privacy)
• PCI DSS: Payment card industry security standards (relevant if handling payment data)
• GDPR: EU data protection regulation (relevant for data handling and privacy)

You do not need deep expertise in these frameworks. Know what they are, what they cover at a high level, and how Kubernetes security controls map to their requirements.

Exam Day Tips

It is conceptual, not hands-on

The KCSA tests whether you understand security concepts, not whether you can implement them in a terminal. You will not write YAML, run kubectl, or configure Falco. You will answer questions about what these things do and when to use them.

Elimination works well

When you are unsure about an answer, eliminate the obviously wrong options first. Security questions often include one answer that violates a basic principle (like running as root or disabling RBAC). Cross those off and you are choosing between two or three options, which improves your odds significantly.

The 4Cs come up everywhere

If a question asks about where a security control applies, think about which of the 4Cs it belongs to. Is it a cloud-level control (IAM), a cluster-level control (RBAC), a container-level control (security context), or a code-level control (input validation)? This framework helps you reason through unfamiliar questions.

Watch for "best practice" questions

The KCSA frequently asks what the best practice is for a given scenario. The answer is almost always the most restrictive option that still allows the workload to function. Run as non-root. Drop all capabilities. Use read-only filesystems. Restrict network access. The theme is always least privilege.

Time is generous

90 minutes for a multiple-choice exam is comfortable. Do not rush. Read each question fully, consider all options, and flag anything you are unsure about. You will have time to review.

Best KCSA Study Resources

Free resources

Kubernetes official documentation (Security section). The docs at kubernetes.io/docs cover RBAC, Pod Security Standards, Network Policies, and Secrets management. Start here for the Kubernetes-specific material.

CNCF Cloud Native Security Whitepaper. Available free from the CNCF. Covers the 4Cs model, threat modeling, and security best practices for cloud native environments. This single document maps closely to the KCSA curriculum.

CKS study materials. If you have access to any CKS course or notes, the conceptual portions cover everything the KCSA tests. You just do not need the hands-on implementation details.

Paid resources

Linux Foundation official training. The Linux Foundation offers security-focused courses that align with the KCSA curriculum. Bundling a course with the exam saves money compared to buying each separately.

Online training platforms. Several platforms offer KCSA preparation courses with structured lessons and quizzes. Look for courses updated for the current exam objectives.

Practice tests

The KCSA does not include practice sessions (those are for professional exams only). Look for practice question sets from online training platforms. Aim to score above 80% consistently before scheduling your exam.

Study Timeline

Background	Study Time
Already passed the CKS	1 to 3 days (review only)
Passed CKA, familiar with security concepts	2 to 3 weeks
General Kubernetes experience, new to security	4 to 6 weeks
New to both Kubernetes and security	6 to 8 weeks
Already passed KCNA, adding security	3 to 4 weeks

If you are on the Kubestronaut path and taking the KCSA last (after CKA, CKAD, CKS, and KCNA), your study time is minimal. Everything on the KCSA is material you have already studied at a deeper level for the CKS.

How the KCSA Fits Into the Certification Path

The KCSA is one of five Kubernetes certifications. Here is where it fits:

For Kubestronaut candidates: The KCSA is typically the last certification you take. After passing the CKA, CKAD, and CKS, the KCSA security concepts are already deeply familiar. Add the KCNA and KCSA at the end to complete the set. See our Kubestronaut path guide for the full plan.

For security professionals entering Kubernetes: The KCSA validates that you understand Kubernetes security at a conceptual level. It is a reasonable starting point before pursuing the CKS, which proves hands-on skills. But if you are comfortable in a terminal, consider skipping straight to the CKA and then the CKS.

As a standalone credential: Honestly, the KCSA has limited standalone value in hiring. It is the newest and least recognized of the five certifications. Most job postings that mention Kubernetes security ask for the CKS, not the KCSA. The KCSA is most valuable as part of the full Kubestronaut set or as a personal learning milestone.

For a comparison of all five certifications, see Best Kubernetes Certifications. For the best order to take them, see the Kubernetes Certification Path.

FAQ

How hard is the KCSA exam?

The KCSA is one of the two easiest Kubernetes certifications, alongside the KCNA. It is a 90-minute, multiple-choice exam. If you study the security concepts for 4 to 6 weeks, most people pass on the first attempt. If you have already passed the CKS, the KCSA is significantly easier because it tests the same concepts at a surface level.

Is the KCSA worth it?

As a standalone credential, the KCSA has limited career impact. Most employers looking for Kubernetes security skills ask for the CKS. The KCSA is worth it if you are pursuing the Kubestronaut title (you need all five certifications), or if you are a security professional who wants a structured introduction to Kubernetes security before committing to the CKS.

What is the difference between KCSA and CKS?

The KCSA is a multiple-choice conceptual exam ($250, 90 minutes, no prerequisites). The CKS is a hands-on performance exam ($445, 2 hours, requires valid CKA). The CKS tests whether you can actually implement security controls in a live Kubernetes cluster. The KCSA tests whether you understand the concepts. The CKS carries significantly more weight in hiring.

Does the KCSA require the CKA?

No. The KCSA has no prerequisites. Anyone can take it. The only Kubernetes certification that requires a prerequisite is the CKS, which requires a valid CKA.

How long is the KCSA valid?

Three years, same as the KCNA. The professional certifications (CKA, CKAD, CKS) are valid for 2 years. The associate certifications (KCNA, KCSA) last an additional year.

What is the 4Cs model?

The 4Cs of cloud native security is a layered security model: Cloud, Cluster, Container, and Code. Each layer depends on the security of the layers beneath it. The KCSA uses this model as its organizing framework. Security controls at each layer protect against different types of threats, and all four layers must be secured for a system to be truly protected.

Should I take the KCSA or CKS?

If you want a credential that carries weight in hiring and proves hands-on skills, take the CKS. If you want a low-cost, low-pressure introduction to Kubernetes security concepts, or if you need the KCSA as part of the Kubestronaut path, take the KCSA. Many Kubestronaut candidates take both, with the CKS first and the KCSA as an easy follow-up.

Can I take the KCSA without any Kubernetes experience?

Yes, but you will need to learn Kubernetes fundamentals alongside the security concepts. The KCSA assumes basic familiarity with Kubernetes objects (Pods, Deployments, Services, Namespaces) and how a cluster is structured. If you are completely new to Kubernetes, consider starting with the KCNA first to build foundational knowledge.