KCSA sample questions with answers

KCSA sample questions

Kubernetes and Cloud Native Security Associate (KCSA), CNCF / The Linux Foundation.

1. Question 1

   Domain: Overview of Cloud Native Security

   Which of the following is a detective control rather than a preventive control?

   1. A Pod Security Admission policy that rejects privileged pods at creation time
   2. A default-deny NetworkPolicy in a namespace
   3. An admission policy that blocks unsigned images
   4. Runtime alerts raised by Falco when a shell starts inside a container
   Show the answer

   Answer: D. Runtime alerts raised by Falco when a shell starts inside a container

   Detective controls observe and report events after they happen, as Falco does when it spots unexpected behaviour at runtime. Admission rules and network policies are preventive: they stop the action in the first place. Image-signature blocking is sometimes mistaken for detection because it involves verification, but it rejects the request before anything runs.

   Checked against: https://falco.org/docs/

2. Question 2

   Domain: Kubernetes Cluster Component Security

   In what order does the kube-apiserver process a request to create a pod?

   1. Authorisation, then authentication, then admission control, then persistence to etcd
   2. Authentication, then authorisation, then admission control, then persistence to etcd
   3. Admission control, then authentication, then authorisation, then persistence to etcd
   4. Authentication, then admission control, then persistence to etcd, then authorisation
   Show the answer

   Answer: B. Authentication, then authorisation, then admission control, then persistence to etcd

   The API server first establishes who is calling, then decides whether that identity may perform the action, then runs mutating and validating admission before storing the object. Putting authorisation first is a common slip, but authorisation needs the user and group information that authentication produces.

   Checked against: https://kubernetes.io/docs/concepts/security/controlling-access/

3. Question 3

   Domain: Kubernetes Cluster Component Security

   Which isolation approach gives each pod its own lightweight virtual machine and guest kernel?

   1. Kata Containers
   2. runc with a seccomp profile
   3. AppArmor in enforce mode
   4. Linux cgroups v2
   Show the answer

   Answer: A. Kata Containers

   Kata Containers runs containers inside lightweight VMs, so workloads do not share the host kernel directly. seccomp, AppArmor and cgroups are all valuable, but they restrict or measure processes that still share the host kernel; seccomp with runc is the most tempting choice, yet it only filters system calls.

   Checked against: https://katacontainers.io/

4. Question 4

   Domain: Kubernetes Security Fundamentals

   Which namespace label makes Pod Security Admission reject pods that do not meet the Restricted standard?

   1. pod-security.kubernetes.io/warn: restricted
   2. pod-security.kubernetes.io/restricted: enforce
   3. pod-security.kubernetes.io/enforce: restricted
   4. pod-security.kubernetes.io/audit: restricted
   Show the answer

   Answer: C. pod-security.kubernetes.io/enforce: restricted

   The enforce mode rejects violating pods; warn only returns a warning to the client, and audit only adds an annotation to the audit event. The warn label is the tempting choice because it uses the correct prefix, but it never blocks anything.

   Checked against: https://kubernetes.io/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces

5. Question 5

   Domain: Kubernetes Security Fundamentals

   An EncryptionConfiguration for secrets lists its providers in this order: identity: {}, then aescbc with a key. What happens to newly written Secrets?

   1. They are encrypted with aescbc, because the strongest configured provider is always chosen
   2. They are written twice, once in plain text and once encrypted
   3. The API server refuses to start because identity cannot appear in the list
   4. They are stored unencrypted, because the first provider in the list is used for writes
   Show the answer

   Answer: D. They are stored unencrypted, because the first provider in the list is used for writes

   The first provider encrypts new writes and every listed provider is tried for reads, so placing identity first means no encryption. Listing identity after the real provider is valid and is how you keep reading data written before encryption was enabled; assuming the strongest provider wins is the tempting error.

   Checked against: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers

6. Question 6

   Domain: Kubernetes Threat Model

   A web application has a remote code execution vulnerability that cannot be patched for two weeks.

   Which pod configuration best limits what an attacker could do after exploiting it?

   1. Non-root, read-only root filesystem, all capabilities dropped and no mounted API token
   2. More replicas behind the Service so the attacker's container is replaced more often
   3. A LoadBalancer Service instead of a NodePort so the application is behind a cloud proxy
   4. imagePullPolicy: Always so that the image is re-pulled every time the container restarts
   Show the answer

   Answer: A. Non-root, read-only root filesystem, all capabilities dropped and no mounted API token

   These settings reduce the attacker's ability to change files, use privileged kernel features, or call the Kubernetes API with the pod's identity. Adding replicas is tempting, but the vulnerable code runs in every replica, and replacement does not stop an attacker who can simply exploit it again.

   Checked against: https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted

7. Question 7

   Domain: Kubernetes Threat Model

   A compromised container runs a fork bomb that exhausts process IDs on the node, and other pods on that node begin to fail.

   Which control directly limits this impact?

   1. A memory limit on the container that runs the fork bomb
   2. A per-pod PID limit on the kubelet (podPidsLimit)
   3. A default-deny NetworkPolicy in the pod's namespace
   4. allowPrivilegeEscalation: false on the container
   Show the answer

   Answer: B. A per-pod PID limit on the kubelet (podPidsLimit)

   PID limits cap how many processes a pod can create, so one pod cannot exhaust the node's process table. Memory limits are tempting because fork bombs use memory, but many tiny processes can exhaust PIDs before the memory limit is reached.

   Checked against: https://kubernetes.io/docs/concepts/policy/pid-limiting/

8. Question 8

   Domain: Platform Security

   An Istio AuthorizationPolicy on the orders workload contains: principals: ["cluster.local/ns/shop/sa/checkout"].

   What does this principal identify, and how is it checked?

   1. Any pod whose name starts with checkout in namespace shop, verified from the pod's IP address
   2. Human users in the shop group, verified from the OIDC token they send with each request
   3. Workloads using the checkout ServiceAccount in shop, verified from the mTLS peer certificate
   4. The checkout Deployment's image digest, verified from the container registry
   Show the answer

   Answer: C. Workloads using the checkout ServiceAccount in shop, verified from the mTLS peer certificate

   Istio identities follow the SPIFFE format spiffe://<trust-domain>/ns/<namespace>/sa/<serviceaccount>, and principals are taken from the certificate presented during mTLS, so the policy only works when mTLS is in use. IP-based matching is tempting but is exactly what cryptographic identity replaces, since pod IPs change and can be spoofed.

   Checked against: https://istio.io/latest/docs/reference/config/security/authorization-policy/

9. Question 9

   Domain: Platform Security

   In the SLSA Build track, what distinguishes Build L3 from Build L2?

   1. Provenance exists for the first time, even though it is unsigned
   2. The source repository requires two-person review of every change before building
   3. A third party must reproduce the artifact bit for bit
   4. A hardened build platform that prevents tampering during the build
   Show the answer

   Answer: D. A hardened build platform that prevents tampering during the build

   Build L1 requires provenance, Build L2 requires signed provenance from a hosted platform, and Build L3 adds a hardened platform that prevents tampering during the build. Two-person review is a tempting pick, but it is a source control practice rather than a Build-track requirement, and bit-for-bit reproducibility is not a Build L3 requirement.

   Checked against: https://slsa.dev/spec/v1.2/build-track-basics

10. Question 10

    Domain: Compliance and Security Frameworks

    A security operations team wants to map its Falco detections to a common catalogue of adversary tactics and techniques for containerised environments, such as Initial Access, Execution, Persistence and Privilege Escalation.

    Which framework provides this?

    1. MITRE ATT&CK and its Containers matrix
    2. The CIS Kubernetes Benchmark for worker nodes
    3. The SLSA supply chain Build track
    4. NIST SP 800-63 Digital Identity
    Show the answer

    Answer: A. MITRE ATT&CK and its Containers matrix

    ATT&CK organises observed adversary behaviour into tactics and techniques, and its Containers matrix covers orchestration-specific techniques; Falco rules commonly carry ATT&CK tags. The CIS Benchmark is tempting as a well-known Kubernetes framework, but it lists configuration checks, not attacker behaviour.

    Checked against: https://attack.mitre.org/matrices/enterprise/containers/