KCSA Platform Security Practice Test 2 — 15 Questions

Question 1

An administrator needs to restrict a container from accessing any devices on the host system via device nodes. By default, how does Docker or containerd handle device access for containers when no custom security profile is applied?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

By applying a default device allowlist that restricts access to essential devices like /dev/null and /dev/random. By default, Docker and containerd apply a default device allowlist that permits access only to essential devices like /dev/null, /dev/zero, /dev/random, and /dev/urandom, while denying access to all other host devices. This is implemented via the default cgroup device controller policy.

Answer

By disabling all system calls related to file I/O

Answer

By routing all device access requests through kube-proxy

Answer

By mounting the entire host /dev directory in read-write mode

Question 2

Your team is implementing image caching and proxying to protect against external container registry rate limits and security incidents. Which upstream project acts as a CNCF-compliant registry proxy and caching mechanism?

Accepted Answer

Harbor. Harbor is a CNCF-graduated project that provides a container image registry with a built-in proxy cache. It can be configured to proxy and cache images from external registries like Docker Hub, mitigating rate limits and ensuring a local copy for security scanning. This makes it the correct answer for a CNCF-compliant registry proxy and caching mechanism.

Answer

Fluentd

Answer

Jaeger

Answer

Prometheus

Question 3

An enterprise Kubernetes cluster uses a service mesh with strict authorization policies configured. A developer complains that their frontend service cannot communicate with the backend database service. Upon inspecting the mesh configuration, you notice a PeerAuthentication resource set to STRICT mode. What does this setting enforce?

Accepted Answer

All incoming traffic to the targeted workloads must use mutual TLS encryption. A PeerAuthentication resource in STRICT mode enforces mutual TLS (mTLS) for all incoming traffic to the targeted workloads, meaning both client and server must present valid certificates. This ensures encryption and identity verification between services in the mesh, and plaintext traffic is rejected. It is a core Istio security primitive for zero-trust service-to-service communication.

Answer

Pod security standards must be enforced at the baseline level

Answer

Network policies must block all traffic from outside the namespace

Answer

All external ingress traffic must pass through a Web Application Firewall

Question 4

What is the primary security benefit of implementing Ingress TLS termination at the ingress controller rather than inside the application pods?

Accepted Answer

Centralized certificate management and reduced cryptographic overhead on application pods. Ingress TLS termination at the ingress controller centralizes TLS certificate management and offloads cryptographic operations from application pods. This means certificates are stored and rotated in one place (the ingress controller), and pods can handle plain HTTP, reducing their CPU overhead and simplifying certificate distribution. It also enables consistent TLS policies across multiple services.

Answer

Automatically encrypting persistent volume storage

Answer

Preventing the container runtime from executing untrusted binaries

Answer

Ensuring that all pod-to-pod communication is blocked

Question 5

What role does image scanning play in a shift-left security strategy for platform security?

Accepted Answer

Detecting vulnerabilities and misconfigurations in container images during development and CI/CD. Image scanning in a shift-left strategy involves analyzing container images during development and CI/CD to detect vulnerabilities and misconfigurations before deployment. This early detection reduces risk and remediation costs by catching issues before they reach production.

Answer

Automatically encrypting secrets stored in etcd

Answer

Generating TLS certificates for ingress controllers

Answer

Enforcing role-based access control policies

Question 6

A security engineer wants to inspect container runtime logs for potential security violations or runtime errors. Which log file or mechanism on a worker node managed by systemd and containerd provides container lifecycle events?

Accepted Answer

journalctl -u containerd. On a worker node managed by systemd and containerd, container lifecycle events and runtime logs are captured by the containerd service. Using journalctl -u containerd retrieves these logs from the systemd journal, providing visibility into container start, stop, and errors. This is the correct mechanism for inspecting runtime logs at the node level.

Answer

kubectl get events --all-namespaces

Answer

/var/log/coredns.log

Answer

/var/log/kube-apiserver.log

Question 7

Why is running containers as the root user discouraged in Kubernetes platform security best practices?

Accepted Answer

It increases the impact of potential container breakout or compromise by granting root privileges inside the container. Running containers as root is discouraged because if an attacker compromises the container, they gain root privileges inside it. This significantly increases the impact of a container breakout or lateral movement, as root can modify files, install tools, and potentially exploit kernel vulnerabilities to escape to the host. Kubernetes security best practices, such as those in the CIS Benchmarks and Pod Security Standards, therefore recommend running containers as non-root users to enforce least privilege.

Answer

It prevents the kubelet from starting the pod

Answer

It disables network policy enforcement

Answer

It stops container image vulnerability scanning

Question 8

An administrator needs to configure an Ingress resource to route traffic securely to a backend service using HTTPS (TLS between the ingress controller and the backend pod). Which NGINX Ingress annotation enables this backend HTTPS communication?

Accepted Answer

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS". The annotation nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" tells the NGINX Ingress Controller to speak HTTPS when connecting to the backend service, enabling TLS between the controller and the pod. This is the standard way to terminate TLS at the ingress and re-encrypt to the backend, satisfying end-to-end encryption requirements. Without this annotation, NGINX defaults to HTTP for backend connections even if the Service port is named 'https'.

Answer

nginx.ingress.kubernetes.io/ssl-redirect: "true"

Answer

nginx.ingress.kubernetes.io/proxy-connect-timeout

Answer

nginx.ingress.kubernetes.io/cors-allow-origin

Question 9

You are troubleshooting a service mesh traffic split policy where telemetry shows that unauthorized external clients are bypassing the service mesh ingress gateway and directly accessing backend services via NodePort services. Which Kubernetes feature should you configure to prevent direct NodePort access to these sensitive pods?

Accepted Answer

NetworkPolicies restricting pod ingress traffic exclusively to the service mesh gateway pod selector. NetworkPolicies restricting pod ingress traffic exclusively to the service mesh gateway pod selector (D) prevents direct NodePort access by only allowing traffic from the gateway. This enforces that all external traffic must go through the mesh ingress, where policies like mTLS and authorization are applied.

Answer

Enabling anonymous authentication in kube-apiserver

Answer

Changing the service type from NodePort to ClusterIP

Answer

Increasing the API server request rate limit

Question 10

A security engineer is hardening a Kubernetes cluster and wants to ensure that all container images are pulled only from an approved internal container registry (e.g., registry.internal.corp). Which Kubernetes mechanism can enforce this restriction across all namespaces?

Accepted Answer

Deploying a validating admission policy or webhook to check image registry URLs. A validating admission policy or webhook is the correct mechanism because Kubernetes admission controllers intercept API requests before objects are persisted, allowing enforcement of image registry restrictions cluster-wide. Tools like OPA Gatekeeper, Kyverno, or the built-in ValidatingAdmissionPolicy (K8s 1.26+) can reject any Pod whose image field does not match an approved registry prefix such as registry.internal.corp. This enforcement applies across all namespaces without modifying individual workloads.

Answer

Configuring NodePort service selectors

Answer

Enabling horizontal pod autoscaling

Answer

Modifying the kube-proxy IPVS configuration

Question 11

You are configuring a runtime security agent that uses Falco to detect unexpected shell execution inside containers. The security rule triggers when a process spawns a shell binary (e.g., bash or sh) inside a container namespace. Which underlying Linux kernel mechanism allows Falco to detect this event with minimal overhead?

Accepted Answer

eBPF system call tracing and kernel event capture. Falco uses eBPF system call tracing and kernel event capture (B) to detect process executions like shell spawning with minimal overhead. eBPF allows Falco to hook into kernel tracepoints and syscalls without modifying the kernel or using heavy agents.

Answer

Periodic polling of container logs using kubectl logs

Answer

Analyzing CoreDNS lookup history

Answer

Inspecting etcd database keys every second

Question 12

An enterprise cluster utilizes a service mesh with AuthorizationPolicies. You need to configure a policy that allows GET requests from service A to service B while explicitly denying DELETE requests on all paths. How are Istio AuthorizationPolicies evaluated when both allow and deny rules are present?

Accepted Answer

DENY rules take precedence and are evaluated before ALLOW rules. Istio AuthorizationPolicies follow a deny-first evaluation model: any matching DENY rule is enforced before ALLOW rules are considered. If a request matches a DENY rule, it is rejected regardless of whether an ALLOW rule would otherwise permit it. This ensures that explicit denials act as hard security boundaries that cannot be overridden by permissive allow policies.

Answer

Only the most recently created authorization policy is evaluated

Answer

ALLOW rules take precedence and override any DENY rules

Answer

Rules are evaluated in alphabetical order of their object names

Question 13

You are configuring an Ingress object with TLS termination. The TLS certificate and private key are stored in a Kubernetes Secret. Which specific secret type must be used to ensure the ingress controller recognizes and validates the TLS credentials correctly?

Accepted Answer

kubernetes.io/tls. The kubernetes.io/tls secret type is specifically designed to hold a TLS certificate and its private key, with required keys 'tls.crt' and 'tls.key'. Ingress controllers look for this type to correctly load and validate the certificate for TLS termination.

Answer

kubernetes.io/service-account-token

Answer

Opaque

Answer

kubernetes.io/dockerconfigjson

Question 14

Why should container images be built using multi-stage builds in Dockerfiles from a security perspective?

Accepted Answer

They exclude build-time tools, package managers, and source code from the final production image, reducing attack surface. Multi-stage builds let you use one stage (with compilers, package managers, source code, and build tools) to produce artifacts, then copy only the final binaries into a minimal runtime stage. The production image therefore excludes build-time tooling and source, shrinking the attack surface and eliminating many CVEs that come from build dependencies.

Answer

They encrypt the container image layer storage in the registry

Answer

They automatically enable kernel-level eBPF monitoring

Answer

They enforce mTLS encryption for all container network traffic

Question 15

You are reviewing a security alert indicating that a container running in your Kubernetes cluster attempted to modify host kernel parameters via /proc/sys. Which security configuration was likely missing or misconfigured for this container?

Accepted Answer

The container was run in privileged mode or lacked necessary capability and filesystem hardening. Modifying host kernel parameters via /proc/sys requires write access to the host's sysctl interface, which is only possible if the container is running in privileged mode or has been granted dangerous capabilities (e.g., CAP_SYS_ADMIN) and lacks filesystem hardening such as a read-only /proc/sys mount or seccomp/AppArmor restrictions. A properly hardened container using Pod Security Standards (restricted) or a securityContext with readOnlyRootFilesystem, dropped capabilities, and no privileged flag would block this.

Answer

The CoreDNS deployment had too few replicas

Answer

The Ingress controller did not enable TLS termination

Answer

The PersistentVolumeClaim lacked a storage class