KCSA Practice Test 2 — 10 Questions

Question 1

Which TWO statements are true regarding Kubernetes NetworkPolicy default behaviors?

Accepted Answer

By default, all pods in a cluster are non-isolated and accept traffic from any source.. Option B is correct because Kubernetes starts with a flat, non-isolated network model: unless a NetworkPolicy selects a pod, that pod is non-isolated and accepts ingress from any source and sends egress to any destination. Option C is correct because once a NetworkPolicy selects a pod and defines ingress rules, the pod becomes isolated for ingress, so only traffic explicitly allowed by those rules (plus established return traffic) is permitted and all other ingress is denied. Option A is wrong because NetworkPolicies are namespaced, additive, and opt-in; installing a cluster does not create any policies or block cross-namespace traffic by default. Option D is wrong because egress is also non-isolated by default—egress is only restricted when a policy selects the pod and includes egress rules (egress isolation). Option E is wrong because NetworkPolicies select pods (via podSelector) within a namespace, not cluster nodes; node-level filtering is handled by other mechanisms such as iptables, nftables, or cloud security groups.

Answer

NetworkPolicies automatically block all traffic across all namespaces upon cluster installation.

Answer

Egress traffic is blocked by default even if no NetworkPolicy is created.

Answer

NetworkPolicies apply to cluster nodes rather than individual pods.

Question 2

An auditor is inspecting a Kubernetes cluster for compliance with the CIS Benchmark for etcd security. Which THREE configurations must be verified for the etcd cluster? (Choose THREE)

Accepted Answer

Peer communication is encrypted using TLS certificates. Option A is correct because the CIS Benchmark for etcd requires that peer (server-to-server) communication be encrypted with TLS certificates to protect cluster traffic between etcd members from eavesdropping or tampering. Option B is correct because enabling client certificate authentication via the --client-cert-auth=true flag ensures that only clients presenting a valid certificate signed by the trusted CA can connect to etcd, which is a core CIS control. Option E is correct because the etcd data directory (typically /var/lib/etcd) must have restrictive permissions such as 700 so that only the etcd process owner can read or write the sensitive key-value store and its WAL files. Option C does not belong because auto-compaction is a maintenance feature and the benchmark does not require it to be permanently disabled. Option D is clearly wrong because exposing etcd directly to the public internet without authentication is a severe misconfiguration that the CIS Benchmark explicitly prohibits.

Answer

etcd auto-compaction is permanently disabled

Answer

etcd is exposed directly on the public internet without authentication

Question 3

Which THREE of the following mechanisms are used by the Kubernetes API server to authorize requests after authentication succeeds? (Choose THREE)

Accepted Answer

RBAC (Role-Based Access Control) authorizer.. The Kubernetes API server supports multiple authorization modes that are evaluated in order after authentication: RBAC (A) grants or denies access based on Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings, making it the standard mechanism for user and service account permissions. The Node authorizer (B) is a specialized authorizer that restricts what kubelets can do, allowing each node to access only the resources (such as its own Pods, Secrets, and ConfigMaps) needed to run its workloads. The Webhook authorizer (E) sends SubjectAccessReview requests to an external HTTP service for authorization decisions, enabling integration with third-party policy engines like OPA/Gatekeeper. Etcd consensus authorizer (C) does not exist; etcd is the backing datastore and has no role in authorizing API requests. Kube-proxy IPVS routing authorizer (D) is fictitious; kube-proxy implements Service load balancing via iptables or IPVS but is not an authorization mechanism.

Answer

Etcd consensus authorizer.

Answer

Kube-proxy IPVS routing authorizer.

Question 4

Which TWO of the following mechanisms help secure the kubelet API from unauthorized access and container inspection? (Choose TWO)

Accepted Answer

Enabling Webhook authorization mode so kubelet requests are validated against API server RBAC.. Option A is correct because setting the kubelet's authorization mode to Webhook makes the kubelet send SubjectAccessReview requests to the API server, so access decisions are evaluated against API server RBAC policies rather than being granted blindly. Option D is correct because disabling anonymous authentication (--anonymous-auth=false) forces unauthenticated requests to the kubelet's HTTPS endpoint to be rejected with 401, preventing anonymous users from querying endpoints like /pods that could expose container details. Option B is wrong because removing TLS certificates would break kubelet authentication and encryption, making the API less secure, not more. Option C is wrong because AlwaysAllow authorizes every request without any check, which is the opposite of securing the kubelet. Option E is wrong because the read-only port 10255 serves unauthenticated, unencrypted data and should be disabled, not enabled.

Answer

Removing all TLS certificates from the kubelet configuration.

Answer

Setting kubelet authorization mode to AlwaysAllow.

Answer

Enabling the kubelet read-only port 10255.

Question 5

A security team is implementing Pod Security Standards (restricted, baseline, privileged) across namespaces. Which THREE controls are enforced under the Restricted Pod Security profile? (Choose THREE)

Accepted Answer

Requiring all capabilities to be dropped except NET_BIND_SERVICE or dropping all (capabilities.drop: [ALL]). The Restricted Pod Security profile is the most stringent of the three Pod Security Standards and enforces hardening controls on every container. Option A is correct because Restricted requires that Linux capabilities be dropped, either by dropping ALL (capabilities.drop: [ALL]) or by dropping all except NET_BIND_SERVICE, preventing containers from retaining dangerous privileges. Option B is correct because Restricted mandates runAsNonRoot: true, ensuring containers do not run as UID 0 (root), which limits the impact of a container compromise. Option C is correct because Restricted requires allowPrivilegeEscalation: false, blocking processes from gaining more privileges than their parent (for example via setuid binaries or file capabilities). Options D and E are incorrect because allowing host network/host PID namespaces and enabling privileged mode are explicitly forbidden by the Restricted profile (and privileged mode is only permitted under the Privileged profile), so they do not represent enforced Restricted controls.

Answer

Allowing unrestricted use of the host network and host PID namespaces

Answer

Enabling privileged mode for all standard workloads

Question 6

An organization wants to prevent supply chain attacks where compromised base images are pulled from public registries. Which control directly addresses this risk in a cloud native environment?

Accepted Answer

Restricting container image pulls to approved, scanned internal registries using admission controllers. Restricting container image pulls to approved, scanned internal registries using admission controllers directly prevents compromised base images from public registries from being deployed. Admission controllers can enforce policies that reject pods referencing untrusted registries, ensuring only vetted images run in the cluster. This is a targeted supply chain control.

Answer

Implementing Kubernetes Horizontal Pod Autoscalers

Answer

Disabling all outbound internet access from cluster worker nodes

Answer

Enabling audit logging on the Kubernetes API server

Question 7

Which THREE of the following are official Pod Security Standard enforcement levels recognized by Kubernetes?

Accepted Answer

baseline. The three official Pod Security Standard enforcement levels defined by Kubernetes are privileged, baseline, and restricted. Option A (baseline) is correct because it is the minimally restrictive policy that prevents known privilege escalations while allowing default pod configurations. Option C (privileged) is correct because it is the unrestricted policy allowing the widest possible permissions, intended for trusted workloads such as system-level components. Option D (restricted) is correct because it is the most restrictive policy, enforcing current hardening best practices like requiring non-root users and dropping capabilities. Options B (isolated) and E (secure) are not recognized enforcement levels; they are not part of the Kubernetes Pod Security Standards, which only define privileged, baseline, and restricted.

Answer

isolated

Answer

secure

Question 8

You are performing a security assessment on an existing Kubernetes cluster. You discover that the kubelet API permits users with valid service account tokens to read sensitive container environment variables and logs. How should you configure the kubelet authorization mode to prevent unauthorized token holders from reading arbitrary pod data?

Accepted Answer

Set kubelet authorization mode to Webhook so the API server evaluates RBAC permissions for kubelet requests.. Setting the kubelet authorization mode to Webhook delegates authorization decisions to the API server, which evaluates RBAC policies for the requesting user or service account. This ensures that only identities with explicit RBAC permissions can access kubelet endpoints like /pods, /logs, or /exec. By default, kubelet may use AlwaysAllow, which grants full access to any authenticated user, including service account tokens, leading to the vulnerability described.

Answer

Set kubelet authorization mode to AlwaysAllow.

Answer

Enable anonymous access on port 10250.

Answer

Disable the kubelet authentication certificate.

Question 9

In the context of Kubernetes API server security, which TWO mechanisms are used to authenticate incoming API requests?

Accepted Answer

X509 Client Certificates presented during TLS handshakes. Option C is correct because the Kubernetes API server supports X509 client certificate authentication, where the client presents a certificate during the mutual TLS handshake and the certificate's Common Name (CN) is used as the username and Organization (O) as group membership. Option E is correct because bearer tokens, including ServiceAccount JWT tokens mounted into pods, are passed in the Authorization: Bearer <token> header and validated by the API server via the TokenReview API or configured token authenticators. The other options do not belong: NetworkPolicy egress CIDR blocks (A) control pod-level network traffic, not API request authentication; PersistentVolume claim capacity metadata (B) is storage resource information; and container image pull secrets (D) are registry credentials used by kubelet to pull images, not API server authentication mechanisms.

Answer

Kubernetes NetworkPolicy egress CIDR blocks

Answer

PersistentVolume claim capacity metadata

Answer

Container image pull secrets stored in private registries

Question 10

A security engineer is reviewing the security posture of an enterprise Kubernetes deployment. They note that developers push container images directly to a private registry without vulnerability scanning. Which of the 4Cs is directly impacted by this gap?

Accepted Answer

Container layer. The Container layer is correct because the gap described — pushing images to a registry without vulnerability scanning — directly concerns the contents and integrity of container images. In the 4Cs model (Cloud, Cluster, Container, Code), the Container layer covers image provenance, image scanning, minimal base images, and runtime hardening. Unscanned images may contain known CVEs in OS packages or libraries, which is precisely a Container-layer concern.

Answer

Code layer

Answer

Cluster layer

Answer

Cloud layer