KCSA Practice Test 9 — 10 Questions

Question 1

You are troubleshooting a control plane failure where the Kubernetes API server cannot communicate with etcd because of expired client certificates. Which command-line flag on the kube-apiserver specifies the client TLS certificate used for authentication against etcd?

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

Accepted Answer

--etcd-certfile. The kube-apiserver flag --etcd-certfile specifies the client TLS certificate that the API server presents to etcd for mutual TLS authentication. When the API server connects to etcd, it must authenticate itself using a client certificate; this flag points to the PEM-encoded certificate file. Without it, the API server cannot establish a secure connection to etcd, leading to control plane failures. The correct flag is explicitly named for the etcd client certificate, not a generic client certificate.

Answer

--etcd-private-key

Answer

--client-cert-file

Answer

--etcd-ca-file

Question 2

An organization's security team mandates that all Kubernetes worker nodes must be scanned for Common Vulnerabilities and Exposures (CVEs) on a scheduled basis. Under the 4Cs, what layer does node vulnerability scanning address?

Accepted Answer

Cluster layer. Under the 4Cs (Cloud, Cluster, Container, Code), the cluster layer encompasses the control plane components, worker nodes, kubelet, container runtime, and node OS. Scanning worker nodes for CVEs addresses vulnerabilities in the node operating system, kernel, and installed packages — squarely a cluster-layer concern. This is distinct from scanning container images (container layer) or application source (code layer).

Answer

Container layer

Answer

Cloud layer

Answer

Code layer

Question 3

An administrator is designing a security posture for a microservices application deployed in a Kubernetes cluster. According to the 4Cs of Cloud Native Security, which component falls under the 'Code' layer?

Accepted Answer

Application dependency libraries in package.json. In the 4Cs of Cloud Native Security (Cloud, Cluster, Container, Code), the 'Code' layer refers to the application code and its dependencies. Application dependency libraries in package.json (B) are part of the code layer because they are directly included in the application's build and runtime. This layer focuses on securing the software supply chain and application logic.

Answer

Container base images like Alpine Linux

Answer

Kubernetes API server authorization policies

Answer

Cloud provider IAM roles

Question 4

A cluster administrator wants to mitigate supply chain risks stemming from vulnerable base images used by developers. Where in the software lifecycle should vulnerability scanning ideally be integrated first to shift-left security?

Accepted Answer

CI/CD pipeline build and image registry push stages. Shifting left means integrating security controls as early as possible in the software development lifecycle. Scanning base images during CI/CD build and at image registry push catches vulnerable packages before they are ever deployed to the cluster, allowing developers to remediate at the source. This is the earliest practical point where image vulnerabilities can be detected and blocked.

Answer

Manual inspection of etcd database backups

Answer

Configuring kube-dns forwarding rules to external resolvers

Answer

Setting up PersistentVolume backup retention policies

Question 5

Which THREE security controls can be enforced by admission webhook policy engines (like Kyverno or OPA Gatekeeper) regarding container images? (Choose three)

Accepted Answer

Verifying cryptographic image signatures using tools like Cosign. Admission webhook policy engines such as Kyverno and OPA Gatekeeper intercept Kubernetes API admission requests and can validate container image attributes before a workload is persisted. Option A is correct because policies can invoke signature verification (e.g., Cosign keyless or key-based attestations) and reject pods whose images lack a valid cryptographic signature. Option B is correct because these engines can enforce registry allow-lists, rejecting any image reference whose registry does not match the approved enterprise registries. Option E is correct because policies can query vulnerability scan results (e.g., from Trivy or Grype reports) and block deployment of images containing unmitigated high-severity CVEs. Option C is not applicable because admission webhooks only validate Kubernetes API objects; they cannot modify kernel modules on worker nodes. Option D is likewise outside their scope, since restarting unhealthy pods is a runtime remediation handled by controllers like the kubelet or ReplicaSet, not by an admission policy.

Answer

Automatically updating kernel modules on the underlying worker node

Answer

Manually restarting unhealthy pods across worker nodes

Question 6

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 7

You have deployed a NetworkPolicy in a namespace that selects backend pods, defining an 'ingress' rule with a 'from' block. No other NetworkPolicies exist in the namespace. What is the default behavior for traffic from pods not matched by the 'from' selector?

Accepted Answer

All ingress traffic from unmatched pods is denied.. When a NetworkPolicy selects a pod and defines an ingress rule with a 'from' block, it becomes an allow-list for that pod's ingress traffic. Any traffic not explicitly allowed by the 'from' selector is denied by default. This is the fundamental behavior of Kubernetes NetworkPolicy: once a pod is selected by a policy, all traffic not matching the allowed rules is blocked.

Answer

All ingress traffic remains allowed by default.

Answer

The policy fails to apply because an egress rule must also be defined.

Answer

Only traffic from other namespaces is denied; same-namespace traffic is still allowed.

Question 8

An enterprise security auditor is reviewing Kubernetes API server admission control configurations for compliance. Which THREE admission plugins or mechanisms are critical for enforcing security policies at admission time? (Choose THREE)

Accepted Answer

ValidatingAdmissionWebhook. ValidatingAdmissionWebhook (A) is correct because it lets the API server call external webhook endpoints to validate requests against custom security policies before persistence, enabling enforcement of organization-specific compliance rules. PodSecurity (B) is correct because it enforces the Pod Security Standards (privileged, baseline, restricted) at the namespace level via admission, blocking pods that violate the configured security profile. NodeRestriction (D) is correct because it is an admission plugin that limits kubelet credentials so a node can only modify its own Node object and Pods bound to it, preventing a compromised node from escalating cluster-wide. InsecureServing (C) is not an admission plugin but a deprecated API server serving option for unauthenticated/insecure port access, and AlwaysAllow (E) is an authorization mode that permits all requests, so neither enforces security policy at admission time.

Answer

InsecureServing

Answer

AlwaysAllow

Question 9

A security engineer configures a ValidatingWebhookConfiguration to intercept pod creations. The webhook service goes down due to a network partition. What happens to incoming pod creation requests by default if the webhook 'failurePolicy' is set to 'Fail'?

Accepted Answer

The API server rejects the pod creation request with an error.. When a ValidatingWebhookConfiguration has failurePolicy: Fail, the API server treats a webhook call failure (timeout, connection refused, network partition) as a denial and rejects the admission request with an error. This is the safe default for security-critical webhooks because it prevents unvalidated resources from being admitted during an outage.

Answer

The kubelet automatically bypasses the webhook and starts the container locally.

Answer

The API server allows the pod creation request and logs a warning.

Answer

The API server queues the request until the webhook service recovers.

Question 10

An auditor notices that kubelet authentication is set to always allow anonymous access in a cluster configuration. According to the CIS Benchmark, what should the kubelet configuration parameter "authentication.anonymous.enabled" be set to?

Accepted Answer

false. The CIS Kubernetes Benchmark explicitly requires that anonymous authentication to the kubelet be disabled. Setting authentication.anonymous.enabled to false ensures that unauthenticated requests to the kubelet's HTTPS endpoint are rejected, forcing all clients to authenticate. This prevents unauthorized users or workloads from querying sensitive node information or executing commands via the kubelet API.

Answer

strict

Answer

auto

Answer

true