KCSA Exam Topics Breakdown: What to Study for 2026

Introduction

Understanding exactly what topics appear on the KCSA exam is essential for efficient study planning. This comprehensive breakdown details all six KCSA domains, the key concepts within each, and what you need to study to pass the certification.

The KCSA exam tests knowledge across six distinct domains, each with specific weightings. By understanding these domains deeply, you can allocate study time effectively and ensure comprehensive exam preparation.

Domain Weighting Quick Reference

Domain	Weight	Priority
Overview of Cloud Native Security	14%	Medium
Kubernetes Cluster Component Security	22%	High
Kubernetes Security Fundamentals	22%	High
Kubernetes Threat Model	16%	High
Platform Security	16%	High
Compliance and Security Frameworks	10%	Medium

Domain 1: Overview of Cloud Native Security (14%)

Purpose

This foundational domain establishes security concepts specific to cloud-native environments. Questions test your understanding of fundamental security principles and how they apply to containerized, orchestrated systems.

Key Topics

1.1 Security Principles and Best Practices

Topics to Study:

• Confidentiality, Integrity, Availability (CIA triad):

  • Confidentiality: Only authorized users access data
  • Integrity: Data remains accurate and uncorrupted
  • Availability: Systems remain accessible when needed

• Least Privilege Principle:

  • Users, applications, and services should have minimum necessary permissions
  • How RBAC implements least privilege
  • How network policies enforce least privilege

• Defense in Depth:

  • Layered security approach (multiple control layers)
  • No single point of failure
  • Example: RBAC + Network Policy + Pod Security Standard

• Zero Trust Architecture:

  • Never trust, always verify
  • Application in Kubernetes contexts
  • Continuous verification vs. perimeter security

Example Concepts:

• Why a default-deny network policy implements zero trust
• How RBAC roles should follow least privilege
• Why multiple security layers are necessary

1.2 Cloud Native Computing and Security

Topics to Study:

• Cloud Native Characteristics:

  • Microservices architecture
  • Container-based deployment
  • Orchestration platforms
  • Infrastructure as Code
  • Immutable infrastructure

• Shared Responsibility Model:

  • Cloud provider responsibilities (infrastructure, hypervisor, host OS)
  • Organization responsibilities (application, data, access control)
  • How this applies to managed Kubernetes services

• Cloud Native Threat Landscape:

  • External attackers (internet-facing services)
  • Insider threats (compromised credentials)
  • Supply chain attacks (malicious images, dependencies)
  • Misconfigurations (exposed secrets, open APIs)

• Security in the Software Development Lifecycle (SDLC):

  • Secure coding practices
  • Dependency scanning
  • Code review processes
  • Security testing (SAST, DAST)
  • Container image security
  • Deployment security

Example Concepts:

• Why container images are security concerns
• How cloud providers and organizations share responsibility
• Why SDLC security matters for cloud-native applications

1.3 Kubernetes and Cloud Native Ecosystem

Topics to Study:

• CNCF Ecosystem:

  • Cloud Native Computing Foundation
  • Projects within CNCF (Kubernetes, Prometheus, Helm, etc.)
  • Security-related CNCF projects

• Container Orchestration Security:

  • Kubernetes security features
  • Declarative configuration
  • Role-based access control
  • Network policies
  • Secrets management

• Microservices Security Considerations:

  • Service-to-service authentication
  • Distributed tracing for security
  • API security
  • Observability and security

Important Concepts for Domain 1

• The difference between security in cloud-native vs. traditional infrastructure
• Why least privilege is foundational to cloud-native security
• How Kubernetes implements core security principles
• The CI/CD pipeline’s role in security

Domain 2: Kubernetes Cluster Component Security (22%)

Purpose

This high-weight domain focuses on securing the Kubernetes control plane and the cluster components that manage the system. You must understand how each component works and its security implications.

Key Topics

2.1 API Server Security

Topics to Study:

• API Server Role:

  • Central control plane component
  • Handles all API requests
  • Enforces policy decisions
  • Manages cluster state

• Authentication Mechanisms:

  • X.509 certificate authentication
  • Bearer tokens
  • Bootstrap tokens
  • OpenID Connect (OIDC) integration
  • Webhook authentication
  • Service account tokens

  Key Concept: Understanding how API server verifies client identity before processing requests

• Authorization Methods:

  • RBAC (Role-Based Access Control)
  • ABAC (Attribute-Based Access Control)
  • Node authorization
  • Webhook authorization

  Key Concept: Authorization decides what authenticated users can do

• Transport Security:

  • TLS/SSL encryption for all API communication
  • Certificate generation and management
  • Certificate rotation procedures
  • Client certificate authentication

• API Server Hardening:

  • —insecure-port (should be disabled)
  • —bind-address (should bind to secure interface)
  • —authorization-mode (should require authorization)
  • —enable-admission-plugins (should enforce policies)
  • Audit logging configuration

Example Configuration:

# Secure API server flags
--secure-port=6443
--tls-cert-file=/etc/kubernetes/pki/apiserver.crt
--tls-private-key-file=/etc/kubernetes/pki/apiserver.key
--etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
--authorization-mode=RBAC
--enable-admission-plugins=PodSecurityPolicy,NodeRestriction
--audit-log-path=/var/log/kubernetes/audit.log

2.2 kubelet Security

Topics to Study:

• kubelet Role:

  • Node agent responsible for running pods
  • Communicates with API server
  • Manages container lifecycle
  • Reports node status

• kubelet API and Authentication:

  • Kubelet API server on port 10250
  • X.509 certificate authentication
  • Anonymous access (should be disabled)
  • Webhook authentication options

  Critical Concept: Kubelet API provides significant access; it must be secured

• kubelet Authorization:

  • AlwaysAllow (default, insecure)
  • Webhook (recommended)
  • RBAC for kubelet API access

  Security Implication: Unsecured kubelet allows attackers to execute commands on nodes

• Kubelet Configuration Security:

  • —read-only-port (should be disabled)
  • —anonymous-auth (should be false)
  • —authorization-mode (should be Webhook or RBAC)
  • Certificate rotation (—rotate-certificates=true)

• kubelet Certificate Rotation:

  • Automatic certificate renewal
  • Preventing certificate expiration
  • Bootstrap certificate process

Example Commands:

# Check kubelet security settings
ps aux | grep kubelet
cat /var/lib/kubelet/kubelet.conf

# Verify kubelet is running securely
curl -k https://localhost:10250/pods/
# Should fail without proper authentication

2.3 etcd Security

Topics to Study:

• etcd Role:

  • Distributed key-value store
  • Stores all cluster state
  • Single source of truth for cluster data
  • Critical security component (compromise = full cluster compromise)

• etcd Encryption at Rest:

  • By default, etcd stores data unencrypted
  • Enabling encryption-at-rest protects data on disk
  • Encryption providers (aescbc, aesgcm, secretbox)

  Critical Concept: Even with RBAC, unencrypted etcd can be compromised through disk access

• etcd Access Control:

  • Network access restrictions
  • TLS/SSL encryption for communication
  • Client certificate authentication
  • Only API server should communicate with etcd

• etcd Backup and Disaster Recovery:

  • Regular backups essential (contains all cluster secrets)
  • Encrypted backups recommended
  • Backup access control
  • Backup storage security

Security Checklist:

• Encryption-at-rest enabled in API server configuration
• etcd accessible only to API server (network policies)
• etcd uses TLS for communication
• Client certificates required for etcd access
• Regular encrypted backups taken
• Backups stored securely with access control

2.4 Control Plane Isolation and Protection

Topics to Study:

• Control Plane Namespace:

  • kube-system namespace contains control plane components
  • Network policies should restrict access
  • RBAC should limit service account permissions

• Protecting Control Plane from Worker Nodes:

  • Workers should not have control plane access
  • Node authorization restricts kubelet permissions
  • Network policies segment control plane

• Control Plane Pod Security:

  • Control plane pods should use restricted pod security standards
  • No privileged containers
  • Read-only root filesystem where possible

• Control Plane Health and Availability:

  • Monitoring for security incidents
  • Detecting unauthorized access attempts
  • Preventing denial of service

Important Concepts for Domain 2

• API server is the central security gatekeeper
• Each component has specific security configurations
• Defense in depth: multiple layers protecting control plane
• etcd compromise means full cluster compromise
• Kubelet security is often overlooked but critical

Domain 3: Kubernetes Security Fundamentals (22%)

Purpose

This equally-weighted domain covers the day-to-day security controls: RBAC, network policies, pod security, and admission control. These topics appear most frequently on KCSA exams.

Key Topics

3.1 Role-Based Access Control (RBAC)

Topics to Study:

• RBAC Components:

  • Roles and ClusterRoles: Define permissions (what can be done)
  • RoleBindings and ClusterRoleBindings: Assign roles to subjects
  • Subjects: Users, Groups, or Service Accounts

• Role Definition:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:
    namespace: default
    name: pod-reader
  rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

• RBAC Verbs:

  • get, list, watch (read)
  • create, update, patch (write)
  • delete, deletecollection (delete)
  • • (all verbs)

  Critical Concept: “get” and “list” are both read; “list” returns all resources, “get” returns one

• API Groups and Resources:

  • Core API group: "" (empty string)
  • Named API groups: “apps”, “batch”, “networking.k8s.io”, etc.
  • Understanding resource names (pods, services, deployments, etc.)

• Service Accounts:

  • Default service account in each namespace
  • Service account tokens mounted in pods
  • Service account names in RBAC bindings

• Common RBAC Mistakes:

  • Overly permissive roles (verbs: [”*”])
  • Cluster-wide permissions when namespace-scoped suffice
  • Default service account with cluster-admin
  • Wildcard resources (*) instead of specific resources

• Testing RBAC:

  # Check what a service account can do
  kubectl auth can-i get pods --as=system:serviceaccount:default:mysa
  kubectl auth can-i create deployments --as=system:serviceaccount:default:mysa

3.2 Network Policies

Topics to Study:

• Network Policy Purpose:

  • Control traffic flow between pods
  • Implement microsegmentation
  • Default deny = least privilege network access

• Default Deny Policy:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: default-deny
  spec:
    podSelector: {}
    policyTypes:
    - Ingress
    - Egress

  Effect: All traffic blocked; must explicitly allow

• Ingress Policies (Inbound):

  • Allow traffic from specific pods
  • Allow traffic from specific namespaces
  • Allow traffic on specific ports

  Example:

  spec:
    podSelector:
      matchLabels:
        app: frontend
    ingress:
    - from:
      - podSelector:
          matchLabels:
            app: backend
      ports:
      - protocol: TCP
        port: 8080

• Egress Policies (Outbound):

  • Restrict outgoing traffic
  • Allow DNS queries
  • Allow communication to specific services
  • Prevent data exfiltration

• Label Selectors:

  • Pod selectors within same namespace
  • Namespace selectors for cross-namespace policies
  • Combined selectors (from: [podSelector AND namespaceSelector])

• Network Policy Limitations:

  • Requires network plugin support (Flannel, Calico, Weave)
  • Operates at network layer (cannot inspect application layer)
  • Cannot match on IP addresses (only labels)

• Best Practices:

  • Start with deny-all policy
  • Add explicit allow rules
  • Document traffic requirements
  • Test policies before production

3.3 Pod Security Standards (PSS)

Topics to Study:

• Three PSS Profiles:

  1. Restricted (Most Stringent)

     • No privileged containers
     • No root user
     • Read-only root filesystem
     • No host access
     • Limited capabilities
     • Suitable for production workloads

  2. Baseline (Permissive)

     • Allows known vulnerabilities
     • Some host access permitted
     • Privileged container escalation allowed
     • Suitable for non-security-critical applications

  3. Unrestricted

     • No restrictions
     • Legacy equivalent to absent policies
     • Should be avoided

• PSS Enforcement Modes:

  • enforce: Rejects pods violating the profile
  • audit: Logs violations but allows pod
  • warn: Warns on violations but allows pod

  Example:

  apiVersion: v1
  kind: Namespace
  metadata:
    name: production
    labels:
      pod-security.kubernetes.io/enforce: restricted
      pod-security.kubernetes.io/audit: restricted
      pod-security.kubernetes.io/warn: restricted

• Pod Security Policy (Deprecated):

  • Replaced by Pod Security Standards (as of Kubernetes 1.25)
  • Exam may reference PSP for context, but PSS is current
  • Understand the relationship between PSP and PSS

• Pod Security Standard Requirements:

  Requirement	Restricted	Baseline
  Privileged	No	No
  Root user	No	Allowed
  Capabilities	Drop all	Allowed
  Host paths	No	Allowed
  Host networking	No	No
  securityContext	Required	Optional

3.4 Admission Control

Topics to Study:

• Admission Controllers:

  • Intercept requests after authentication/authorization
  • Can validate (ValidatingAdmissionWebhooks)
  • Can mutate/modify (MutatingAdmissionWebhooks)
  • Enable using —enable-admission-plugins flag

• Important Built-in Admission Controllers:

  • PodSecurityPolicy (deprecated, replaced by PSS)
  • ResourceQuota: Enforce resource limits
  • LimitRanger: Enforce resource constraints
  • ServiceAccount: Service account defaulting
  • DefaultStorageClass: Default storage class selection

• Webhook Admission Controllers:

  ValidatingAdmissionWebhook:

  apiVersion: admissionregistration.k8s.io/v1
  kind: ValidatingWebhookConfiguration
  metadata:
    name: validate-pod-resources
  webhooks:
  - name: validate.example.com
    clientConfig:
      service:
        name: webhook-service
        namespace: webhook-namespace
        path: "/validate"
    rules:
    - operations: ["CREATE"]
      apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]

  MutatingAdmissionWebhook:

  • Automatically modifies resources
  • Add default labels
  • Inject sidecars
  • Enforce naming conventions

• Policy Enforcement:

  • OPA/Gatekeeper as policy engine
  • Rego language for policy rules
  • Enforcing compliance policies
  • Audit policies

Important Concepts for Domain 3

• RBAC is fundamental to Kubernetes security
• Network policies provide microsegmentation
• Pod Security Standards protect workloads
• Admission control enforces policies
• These controls work together for defense in depth

Domain 4: Kubernetes Threat Model (16%)

Purpose

This domain focuses on understanding threats and attack scenarios specific to Kubernetes. Rather than memorizing attacks, understand the threat landscape and mitigation strategies.

Key Topics

4.1 Container Security

Topics to Study:

• Container Escape Vectors:

  • Kernel vulnerabilities allowing host access
  • Privileged containers bypassing isolation
  • Insecure container runtimes
  • Misconfigured security contexts

  Mitigation:

  • Run containers with limited privileges
  • Use restricted PSS profiles
  • Update kernel regularly
  • Use secure container runtimes

• Privilege Escalation:

  • From unprivileged container user to root
  • From container to host
  • Using SUID binaries in containers

  Prevention:

  • Drop unnecessary capabilities
  • Use restrictive securityContext
  • Remove SUID binaries from images
  • Run as non-root user

• Runtime Security:

  • Falco for runtime threat detection
  • Syscall monitoring
  • Detecting suspicious behavior
  • Responding to threats

4.2 Cluster Attack Vectors

Topics to Study:

• Compromised Pod to Node:

  • Accessing node through volume mounts
  • Attacking kubelet API
  • Exploiting node privileges

• Lateral Movement:

  • Pod-to-pod communication
  • Service-to-service attacks
  • Cross-namespace attacks
  • Network policy segmentation

• Data Exfiltration:

  • Stealing secrets from etcd
  • Exfiltrating application data
  • Detecting exfiltration attempts
  • Network egress controls

• Denial of Service (DoS):

  • Resource exhaustion attacks
  • API server overload
  • Resource quotas as mitigation
  • Quality of service classes

4.3 Supply Chain Attacks

Topics to Study:

• Image-based Attacks:

  • Malicious container images
  • Compromised registries
  • Image scanning limitations

• Dependency Vulnerabilities:

  • Known vulnerabilities in dependencies
  • Transitive dependencies
  • SBOM (Software Bill of Materials)

• Build Pipeline Attacks:

  • Compromised build systems
  • Injected malicious code
  • Securing build pipelines

Important Concepts for Domain 4

• Understand realistic threat scenarios
• Know mitigation strategies for each threat
• Recognize that kubernetes security is defense in depth
• Understand blast radius of various attack types

Domain 5: Platform Security (16%)

Purpose

Security beyond the cluster, including image security, supply chain, vulnerability management, and runtime monitoring.

Key Topics

5.1 Image Security

Topics to Study:

• Image Scanning:

  • Vulnerability databases (CVE)
  • Scanning tools (Trivy, Grype, Clair)
  • Severity ratings
  • Scan frequency requirements

• Image Signing:

  • Cosign for container image signing
  • Signature verification
  • Key management
  • Attestations

• Registry Security:

  • Private vs. public registries
  • Registry authentication
  • Image pull policies
  • ImagePullSecrets

• Minimal Base Images:

  • Alpine Linux (minimal)
  • Distroless images (no shell)
  • Scratch images (application only)
  • Benefits of minimal images

5.2 Supply Chain Security

Topics to Study:

• SLSA Framework:

  • Build system security
  • Artifact integrity
  • Provenance
  • Completeness levels

• Software Bill of Materials (SBOM):

  • Listing all components in software
  • Vulnerability tracking in components
  • Compliance requirements
  • Tools: syft, cyclonedx

• Artifact Signatures:

  • Signing images
  • Signing deployments
  • Verification workflows
  • Key rotation

• Binary Authorization:

  • Only allow signed, authorized images
  • Policy enforcement
  • GCP Binary Authorization
  • OPA/Gatekeeper alternatives

5.3 Vulnerability Management

Topics to Study:

• Vulnerability Lifecycle:

  • Discovery (scanning)
  • Assessment (severity, impact)
  • Remediation (patching, updating)
  • Verification (re-scanning)

• Continuous Scanning:

  • Scanning during build
  • Scanning at runtime
  • Periodic re-scanning
  • Alerting on new vulnerabilities

• Patch Management:

  • Regular image rebuilds
  • Dependency updates
  • Security patches
  • Testing patches before deployment

5.4 Runtime Security and Monitoring

Topics to Study:

• Observability and Security:

  • Logging security events
  • Monitoring for anomalies
  • Alerting on suspicious activity

• Falco for Runtime Security:

  • System call monitoring
  • Anomaly detection
  • Policy enforcement
  • Integration with Kubernetes

• Container Runtime Security:

  • containerd security
  • CRI-O security
  • Runtime policies
  • Container isolation

Important Concepts for Domain 5

• Image security is critical first defense
• Supply chain security is increasingly important
• Vulnerability management is continuous process
• Runtime monitoring catches issues not found statically

Domain 6: Compliance and Security Frameworks (10%)

Purpose

Understanding how to apply security standards and maintain compliance in Kubernetes environments.

Key Topics

6.1 Compliance Standards

Topics to Study:

• PCI-DSS (Payment Card Industry Data Security Standard):

  • Applies to credit card processing
  • Network segmentation requirements
  • Encryption requirements
  • Access control requirements

• HIPAA (Health Insurance Portability and Accountability Act):

  • Applies to protected health information
  • Encryption at rest and in transit
  • Access controls
  • Audit logging requirements

• SOC 2 (Service Organization Control):

  • Security, availability, confidentiality standards
  • Controls testing
  • Audit procedures
  • Compliance reporting

• GDPR (General Data Protection Regulation):

  • Data protection and privacy
  • Right to be forgotten
  • Data breach notification
  • Data processing agreements

• Industry-Specific Requirements:

  • Financial services (PCI-DSS)
  • Healthcare (HIPAA, BAA)
  • Government (FedRAMP)
  • Cloud Act compliance

6.2 Auditing and Logging

Topics to Study:

• Kubernetes Audit Logs:

  • API request logging
  • Audit log format
  • Event levels (Metadata, RequestResponse)
  • Filtering and policies

• Audit Log Policy:

  apiVersion: audit.k8s.io/v1
  kind: Policy
  rules:
  - level: RequestResponse
    verbs: ["delete", "create"]
    resources: ["pods", "secrets"]
  - level: Metadata
    omitStages:
    - RequestReceived

• Log Storage and Retention:

  • Central log aggregation
  • Encryption for stored logs
  • Retention policies
  • Compliance with standards

• Log Analysis:

  • Identifying suspicious activity
  • Investigating security incidents
  • Compliance reporting

6.3 Security Policies and Documentation

Topics to Study:

• Security Policy Documentation:

  • RBAC policies documented
  • Network policies documented
  • Security baselines
  • Procedures and runbooks

• Disaster Recovery and Business Continuity:

  • Backup procedures
  • Recovery time objectives (RTO)
  • Recovery point objectives (RPO)
  • Testing recovery procedures

• Change Management:

  • Change control procedures
  • Approval workflows
  • Rollback procedures
  • Documentation of changes

6.4 Incident Response

Topics to Study:

• Incident Response Procedures:

  • Detection and alerting
  • Investigation and analysis
  • Containment and remediation
  • Recovery and restoration
  • Post-incident review

• Forensics in Kubernetes:

  • Collecting evidence
  • Preserving logs and states
  • Timeline reconstruction
  • Root cause analysis

• Communication and Escalation:

  • Incident classification
  • Notification procedures
  • Escalation paths
  • External communications

Important Concepts for Domain 6

• Compliance varies by industry and data type
• Auditing provides trail for compliance
• Documentation supports compliance demonstration
• Incident response is critical for compliance

Study Strategy by Domain

High-Weight Domains (22% each)

Focus 30% of study time on each:

• Kubernetes Security Fundamentals (RBAC, network policies, PSS, admission)
• Kubernetes Cluster Components (API server, kubelet, etcd)

Why: These domains cover fundamental controls you must understand deeply.

Medium-Weight Domains (16% each)

Focus 20% of study time on each:

• Kubernetes Threat Model (realistic scenarios)
• Platform Security (images, supply chain, runtime)

Why: These are increasingly important for real-world security.

Other Domains

Focus 15% on each:

• Cloud Native Security Overview (14%)
• Compliance and Frameworks (10%)

Why: Important context and governance, but less frequently tested.

Frequently Asked Questions

Q: What’s the difference between RBAC verbs “list” and “get”? A: “get” retrieves a single named resource; “list” retrieves all resources in a scope. Both are read operations but have different implications.

Q: How deep do I need to understand etcd encryption? A: Understand that encryption-at-rest is configured via API server flags and that unencrypted etcd is a security risk. You don’t need to understand encryption algorithms.

Q: Will the exam have questions about specific security tools? A: Possibly, but focus on Kubernetes-native controls (RBAC, network policies, PSS). Tools like Falco, OPA, Cosign are important context but not required.

Q: How many questions per domain on the exam? A: Approximately:

• 13-14 questions on 22%-weight domains
• 10-11 questions on 16%-weight domains
• 8-9 questions on 14%-weight domain
• 6 questions on 10%-weight domain

Q: Should I memorize RBAC rules? A: Don’t memorize; understand the concepts. Know that RBAC uses rules with apiGroups, resources, and verbs. Know common mistakes.

Q: What’s the most important topic? A: RBAC (Role-Based Access Control). It appears across multiple domains and questions. Master RBAC first.

Ready to Study These Topics?

Now that you understand all six KCSA domains and their key topics, it’s time to begin focused preparation.

Next steps:

1. Assess your baseline: Take a free practice exam on Sailor.sh and see which domains you need to focus on
2. Follow the domain study strategy: Allocate study time based on domain weights
3. Use structured resources: Sailor.sh’s KCSA study bundle covers all domains with appropriate depth
4. Practice domain-specific questions: Use Sailor.sh’s practice platform to drill specific topics
5. Track your progress: Monitor improvement across all six domains

Master these topics, and you’ll be well-prepared to pass the KCSA exam and become a certified cloud-native security professional. Start your study today.