KCSA Platform Security — Timed 15 Questions

Question 1

A security administrator wants to prevent container processes from writing to any part of their root filesystem except for designated ephemeral volumes. Which security context field should be configured?

15 minute time limit — choose an answer to begin.

Accepted Answer

readOnlyRootFilesystem: true. The readOnlyRootFilesystem: true field in a Pod's securityContext mounts the container's root filesystem as read-only, preventing any writes to the image layers. Writable locations must then be explicitly provided via emptyDir, persistentVolumeClaim, or tmpfs volume mounts, which is exactly the requirement described.

Answer

runAsUser: 1000

Answer

allowPrivilegeEscalation: false

Answer

privileged: false

Question 2

What is the primary function of a container runtime interface (CRI) security boundary in Kubernetes?

Accepted Answer

To separate the management of container lifecycles from the kubelet while maintaining isolation. The primary function of a container runtime interface (CRI) security boundary in Kubernetes is to separate the management of container lifecycles from the kubelet while maintaining isolation (C). CRI allows kubelet to interact with different container runtimes via a standardized API, and the boundary ensures that runtime operations are isolated from the kubelet's core logic.

Answer

To provision persistent block storage volumes

Answer

To manage DNS lookups across cluster namespaces

Answer

To encrypt all secrets stored within Kubernetes Secrets objects

Question 3

Which TWO mechanisms are commonly used by container runtime security tools to monitor container activity? (Choose two)

Accepted Answer

eBPF (Extended Berkeley Packet Filter) programs attached to kernel tracepoints. Modern container runtime security tools monitor container behavior using Linux kernel tracing mechanisms such as eBPF and kernel modules or security hooks.

Answer

Kubernetes persistent volume snapshotting

Answer

CoreDNS query log analysis

Question 4

A platform team runs a multi-tenant Kubernetes cluster. They must guarantee that a workload in namespace `team-a` can never consume more than 2 CPU cores and 4Gi of memory, regardless of how many pods it schedules, and that pods are rejected at admission time if they omit resource requests. Which combination of resources should they configure?

Accepted Answer

A ResourceQuota with `requests.cpu`, `requests.memory`, `limits.cpu`, and `limits.memory` set in namespace `team-a`.. Namespace-scoped ResourceQuota objects are the native Kubernetes mechanism for enforcing aggregate compute ceilings per tenant. By defining requests and limits for CPU and memory, the platform team caps total consumption at 2 cores and 4Gi and causes the API server to reject pods that do not declare the mandated resource fields. LimitRange, PodDisruptionBudget, and NetworkPolicy address different concerns entirely.

Answer

A LimitRange with `max` CPU and memory values applied to namespace `team-a`.

Answer

A PodDisruptionBudget referencing the tenant's deployments in namespace `team-a`.

Answer

A NetworkPolicy with ingress and egress rules applied to namespace `team-a`.

Question 5

A security engineer is configuring a seccomp profile for a critical application pod running in a hardened Kubernetes cluster to restrict system calls. The pod requires access to the networking stack but must block module loading. Where must this custom JSON seccomp profile be placed on a worker node running containerd so that it can be referenced via the pod security spec?

Accepted Answer

/var/lib/kubelet/seccomp/. Custom seccomp profiles referenced by kubelet must be placed in the kubelet's seccomp root directory, which defaults to /var/lib/kubelet/seccomp/ on the worker node. The pod spec then references the profile via securityContext.seccompProfile with type Localhost and a relative path under that directory. This is the documented location for local seccomp profiles in Kubernetes.

Answer

/var/log/containers/

Answer

/etc/kubernetes/manifests/

Answer

/etc/containerd/certs.d/

Question 6

When configuring a container to run securely in a Kubernetes cluster, you want to ensure that the container process cannot gain any new privileges during its lifecycle, even if it runs as root or exploits a setuid binary. Which Linux kernel feature should be enabled in the container security context?

Accepted Answer

allowPrivilegeEscalation: false. The allowPrivilegeEscalation: false setting directly controls whether a container process can gain more privileges than its parent process. It sets the Linux no_new_privs flag on the container process, which prevents setuid/setgid binaries and file capabilities from elevating privileges. This is the exact kernel feature that blocks privilege escalation even when running as root.

Answer

readOnlyRootFilesystem: false

Answer

privileged: true

Answer

runAsNonRoot: false

Question 7

You are troubleshooting a container image vulnerability scan report that flagged a high-severity CVE in a base image layer. The development team wants to ensure that vulnerable container images are automatically prevented from being deployed to any namespace in the cluster. Which Kubernetes mechanism should you implement?

Accepted Answer

Configure a validating admission webhook to inspect image metadata and reject deployments with known CVEs. A validating admission webhook intercepts pod creation requests before they are persisted to etcd and can inspect image metadata (via registries or scanning tools) to reject deployments containing known CVEs. This enforces policy at the cluster level across all namespaces, preventing vulnerable images from ever running.

Answer

Enable resource quotas on the default namespace

Answer

Rotate the cluster certificate authority

Answer

Add network policies to restrict outbound CVE database queries

Question 8

Your security team has discovered that an application container image contains outdated packages with known remote code execution vulnerabilities. Which phase of the software development lifecycle is the most effective place to initially scan and remediate these vulnerabilities?

Accepted Answer

CI/CD pipeline build stage. Scanning in the CI/CD pipeline build stage catches vulnerable packages before the image is pushed to a registry or deployed, enabling remediation at the earliest point where the development team can act. This shifts security left, prevents vulnerable artifacts from propagating, and integrates with build gates that fail the pipeline on critical CVEs. Tools like Trivy, Clair, or Snyk run here.

Answer

Node OS package manager updates

Answer

Kubelet container startup phase

Answer

Kubernetes API server audit logging

Question 9

You are configuring an Ingress resource using the NGINX Ingress Controller to expose a sensitive internal application. To prevent unauthorized clients from connecting, you want to enable mutual TLS authentication at the ingress layer. Which annotation is required in the Ingress resource definition to specify the Kubernetes Secret containing the trusted Client CA certificate?

Accepted Answer

nginx.ingress.kubernetes.io/auth-tls-secret. The annotation nginx.ingress.kubernetes.io/auth-tls-secret is the NGINX Ingress Controller directive that specifies the Kubernetes Secret containing the CA certificate used to verify client certificates for mutual TLS. When set, the controller enforces client certificate authentication at the ingress layer, rejecting connections that do not present a certificate signed by the trusted CA. This is the correct annotation for enabling mTLS with a trusted Client CA.

Answer

ingress.kubernetes.io/backend-protocol

Answer

kubernetes.io/ingress.class

Answer

nginx.ingress.kubernetes.io/ssl-redirect

Question 10

An organization requires that all container images pulled into a Kubernetes cluster are cryptographically signed and verified before execution. Which tool integrates with Kubernetes admission control to enforce signature verification using Cosign?

Accepted Answer

Kyverno policy engine. Kyverno is a Kubernetes-native policy engine that runs as a dynamic admission controller and can validate, mutate, and generate resources. It supports verifying Cosign signatures on container images via its verifyImages rule, rejecting any pod whose image lacks a valid signature from a trusted key or keyless identity. This makes it the correct tool for enforcing cryptographic image verification at admission time.

Answer

Cilium CNI plugin

Answer

Metrics-server

Answer

Helm package manager

Question 11

An administrator needs to enforce mTLS (Mutual TLS) across all microservices within a service mesh without modifying application code. Which component is automatically injected into each application pod to handle the encryption and decryption of traffic?

Accepted Answer

Sidecar proxy. A sidecar proxy is a secondary container deployed alongside the application container within the same pod. In service meshes like Istio or Linkerd, the sidecar proxy (e.g., Envoy) intercepts all inbound and outbound traffic, handles mTLS handshakes, certificate rotation, and encryption/decryption transparently — no application code changes are needed. This is the core mechanism for zero-trust networking in Kubernetes service meshes.

Answer

Container runtime shim

Answer

Kube-proxy

Answer

Ingress controller

Question 12

A platform engineer wants to configure a container runtime security tool that monitors system calls and sends alerts about potential threats in a Kubernetes cluster. Which component of the container runtime architecture intercepts these system calls?

Accepted Answer

eBPF kernel probes. eBPF (extended Berkeley Packet Filter) kernel probes are the correct answer because they allow programs to run in the Linux kernel without changing kernel source code or loading modules. In container runtime security, tools like Falco, Tetragon, and Cilium use eBPF to hook into system calls (syscalls) and other kernel events, monitoring container behavior for threats. This interception happens at the kernel level, providing deep visibility into syscalls made by containers.

Answer

The coreDNS plugin

Answer

The Kubernetes storage controller

Answer

The kube-apiserver admission webhook

Question 13

An auditor is reviewing container image registries used by a Kubernetes cluster. They notice that public images are pulled directly without verification. Which security best practice should be implemented for image registries?

Accepted Answer

Use private registries with integrated vulnerability scanning and image pull policies. Using private registries with integrated vulnerability scanning and image pull policies ensures that only vetted, scanned images are deployed, and that the cluster enforces image provenance. This directly addresses the auditor's finding that public images are pulled without verification, because private registries can require authentication, enforce image signing (e.g., Cosign/Notary), and integrate scanners like Trivy or Clair. Kubernetes admission controllers (e.g., OPA Gatekeeper, Kyverno) can then enforce imagePullPolicy and registry allowlists.

Answer

Grant cluster-admin permissions to all developers

Answer

Store plaintext passwords in ConfigMaps

Answer

Disable all network policies in the cluster

Question 14

You need to ensure that an ingress controller processing TLS termination uses strong cryptographic ciphers and disables outdated protocols such as TLSv1.0 and TLSv1.1. Where are these TLS configuration settings typically managed in an NGINX Ingress deployment?

Accepted Answer

Ingress controller ConfigMap parameters such as ssl-ciphers and ssl-protocols. In an NGINX Ingress deployment, TLS settings for the ingress controller are configured globally via ConfigMap parameters such as ssl-ciphers and ssl-protocols. These parameters allow administrators to specify the cipher suite and the minimum TLS version (e.g., TLSv1.2) that the controller will accept, ensuring strong cryptography and disabling outdated protocols like TLSv1.0 and TLSv1.1. This ConfigMap is typically named nginx-configuration and resides in the ingress-nginx namespace, and changes are applied by reloading the controller.

Answer

The core DNS configuration map

Answer

The kube-apiserver static pod manifest file

Answer

Persistent Volume Claim storage classes

Question 15

A platform engineer is hardening a container runtime setup on worker nodes. They want to ensure that containers cannot make unauthorized changes to network configurations or mount host filesystems. Which capability must be explicitly dropped from the default container capabilities set?

Accepted Answer

CAP_SYS_ADMIN. CAP_SYS_ADMIN is the most powerful Linux capability, granting broad administrative privileges including mounting filesystems, modifying network configuration, and accessing kernel features. Dropping it prevents containers from performing privileged operations like mounting host filesystems or reconfiguring network interfaces, which are common container-escape and node-compromise vectors.

Answer

CAP_CHOWN

Answer

CAP_NET_BIND_SERVICE

Answer

CAP_DAC_OVERRIDE