Pass the Linux Foundation Kubernetes and Cloud Native KCSA Questions and answers with ValidTests

gVisor:

Google-developed, implemented as auser-space kernelthat intercepts and emulates syscalls made by containers.

Providesstrong isolationwithout requiring a full VM.

Official docs: “gVisor is a user-space kernel, written in Go, that implements a substantial portion of the Linux system call interface.”

Source: https://gvisor.dev/docs/

Firecracker:

AWS-developed,lightweight virtualization technologybuilt on KVM, used in AWS Lambda and Fargate.

Optimized for running secure, multi-tenant microVMs (MicroVMs) for containers and FaaS.

Official docs: “Firecracker is an open-source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services.”

Source: https://firecracker-microvm.github.io/

Key difference:gVisor → syscall interception in userspace kernel (container isolation). Firecracker → lightweight virtualization with microVMs (multi-tenant security).

Therefore, optionAis correct.

The 4C’s model (Cloud, Cluster, Container, Code) is presented in the official Kubernetes documentation as alayeredmodel that explicitly maps todefense-in-depth.

Exact extracts from Kubernetes docs(security overview):

“The 4C’s of Cloud Native Security are Cloud, Clusters, Containers, and Code.”

“You can think of the 4C’s asa layered approach to security; applying security measures at each layer reduces risk.”

“This layered approach is commonly known asdefense in depth.”

etcdis Kubernetes’key-value storeforcluster state.

Stores: ConfigMaps, Secrets, Pod definitions, Deployments, RBAC policies, and metadata.

Exact extract (Kubernetes Docs – etcd):

“etcd is a consistent and highly-available key-value store used as Kubernetes’ backing store for all cluster data.”

Clarifications:

B: Logs/metrics are handled by logging/monitoring solutions, not etcd.

C: Secrets may be stored here but encoded in base64, not specifically "usernames/passwords" as primary use.

D: Persistent Volumes are external storage, not stored in etcd.

Kubernetes originally had a feature calledPodSecurityPolicy (PSP), which provided controls to restrict pod behavior.

Official docs:

“PodSecurityPolicy was deprecated in Kubernetes v1.21 and removed in v1.25.”

“Pod Security Standards (PSS) replace PodSecurityPolicy (PSP) with a simpler, policy-driven approach.”

PSP was often complex and hard to manage, so it was replaced by Pod Security Admission (PSA) which enforcesPod Security Standards.

Access control (RBAC, least privilege, user restrictions)is abaseline container security best practice.

Exact extract (Kubernetes Pod Security Standards – Baseline):

“The baseline profile is designed to prevent known privilege escalations. It prohibits running privileged containers or containers as root.”

Other options clarified:

B: Static IPs not a security measure.

C: Persistent storage is functionality, not security.

D: Running as root is explicitlyinsecure.

Starting a process in a running containerprovides an attacker withtemporary execution (foothold)inside the cluster, but once the container is stopped or restarted, that malicious process is lost. This means the attacker has nolong-term persistence.

Incorrect options:

(A) Modifying objects inetcdgrants persistent access since cluster state is stored in etcd.

(B) Modifying files on thehost filesystemcan create persistence across reboots or container restarts.

(D) Creating a restarting container directly on the host via Docker bypasses Kubernetes but persists across pod restarts if Docker restarts it.

Audit loggingrecords API server requests and responses for security monitoring.

TheRequestResponse levellogs the full request and response bodies, which can:

Significantly increasestorage and performance overhead.

Potentially log sensitive data (including Secrets).

Therefore, while comprehensive, it introduces risks of performance degradation and excessive log volume.

Inhigh-availability clusters, multiple API server instances run behind a load balancer.

Thisdistributes client requests across multiple API servers, preventing a single API server from being overwhelmed.

Exact extract (Kubernetes Docs – High Availability Clusters):

“A highly available control plane runs multiple instances of kube-apiserver, typically fronted by a load balancer, so that if one instance fails or is overloaded, others continue serving requests.”

Other options clarified:

A: Network segmentation does not directly mitigate API server DoS.

C: Adding resources helps, but doesn’t solve single-point-of-failure.

D: Rate limiting is a valid mitigation but not provided by HA alone.