KCSA Platform Security — Timed 10 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?

10 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