Free Practice Questions for Linux Foundation KCSA Exam

CWPP (Cloud Workload Protection Platform):As defined by Gartner and adopted across cloud security practices, CWPPs are designed tosecure workloads(VMs, containers, serverless functions) in hybrid and cloud environments.

They providevulnerability scanning, runtime protection, compliance checks, and malware detection.

Exact extract (Gartner CWPP definition):“Cloud workload protection platforms protect workloads regardless of location, including physical machines, VMs, containers, and serverless workloads. They provide vulnerability management, system integrity protection, intrusion detection and prevention, and malware protection.”

Thekube-schedulerexposes aprofiling/debugging endpointwhen --profiling=true (default).

This can unnecessarily increase the attack surface.

Best practice: set --profiling=false in production.

Exact extract (Kubernetes Docs – kube-scheduler flags):

“--profiling (default true): Enable profiling via web interface host:port/debug/pprof/.”

Why others are wrong:

--scheduler-name: just identifies the scheduler, not a security risk.

--secure-kubeconfig: not a valid flag.

--bind-address: changing it limits exposure but is not the default risk parameter for profiling.

Grafana:An open-source analytics and visualization platform widely used with Prometheus, Loki, etc.

Exact extract (Grafana Docs):“Grafana is the open-source analytics and monitoring solution for every database. It allows you to query, visualize, alert on, and understand your metrics no matter where they are stored.”

A is wrong:That describesJaeger(distributed tracing).

B is wrong:That’sKubernetesitself.

D is wrong:That’sTrivy/Aqua/Prismatype tools.

The4C’s of Cloud Native Security(Cloud, Cluster, Container, Code) model starts withCloudas the base layer.

If the Cloud (infrastructure layer) is compromised, every higher layer (Cluster, Container, Code) inherits that compromise.

Exact extract (Kubernetes Security Overview):

“The 4C’s of Cloud Native security are Cloud, Clusters, Containers, and Code. You can think of the 4C’s as a layered approach. A Kubernetes cluster can only be as secure as the cloud infrastructure it is deployed on.”

This means the cloud is part of thetrusted computing baseof a Kubernetes cluster.

MicroVM-based runtimes(e.g., Firecracker, Kata Containers) use lightweight VMs to provide strong isolation between workloads.

Compared touser-space kernel implementations(e.g., gVisor), microVMs generally:

Offerhigher isolation and security(due to VM-level separation).

Come with ahigher memory and resource overhead per instancethan user-space approaches.

Incorrect options:

(A) Orchestration is handled by Kubernetes, not inherently easier with microVMs.

(C) Compatibility is typically better with microVMs, not worse.

(D) Isolation is stronger, not weaker.

Thekubeletis the primary agent that runs on each node in a Kubernetes cluster and communicates with the control plane.

Kubeletsupports TLS (Transport Layer Security)for both authentication and encryption when interacting with the API server. This is a core security feature that ensures secure node-to-control-plane communication.

Incorrect options:

(A) Kubelet does not run as a privileged container by default; it runs as a system process (typically systemd-managed) on the host.

(B) Kubelet does include built-in security features such asTLS authentication, authorization modes, and read-only vs secured ports.

(D) While kubelet interacts with the host system (e.g., cgroups, container runtimes), it does not inherently require root access for communication security; RBAC and TLS handle authentication.

Defining policiesas code (declarative)is a best practice in Kubernetes and cloud-native security.

This is aligned withGitOpsandPolicy-as-Codeprinciples (OPA Gatekeeper, Kyverno, etc.).

Exact extract (CNCF Security Whitepaper):

“Policy-as-Code enables declarative definition and enforcement of security policies, bringing consistency, automation, and reducing misconfiguration risk.”

Manual audits, ad-hoc scripting, or individual configurations are error-prone and inconsistent.

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.