KCSA Practice Test 22 — 15 Questions

Question 1

Which protocol and default secure port does the kubelet use to listen for incoming authenticated requests from the API server and metrics collectors?

Accepted Answer

HTTPS on port 10250. The kubelet listens on HTTPS port 10250 by default for authenticated requests from the API server (e.g., kubectl logs, exec) and from metrics collectors like the metrics-server. This port requires authentication and authorization (via the kubelet's --authorization-mode and client CA), and it is the standard secure endpoint for kubelet API access. Port 10255 is the read-only, unauthenticated HTTP port that is disabled by default in modern Kubernetes due to security concerns.

Answer

HTTPS on port 6443

Answer

TCP on port 2379

Answer

HTTP on port 10255

Question 2

Your cluster uses the Pod Security admission controller with the 'restricted' profile enforced. A legacy application pod fails to start because it requires running as root (runAsNonRoot: false). How should you handle this securely without disabling the standard?

Accepted Answer

Configure the Pod Security admission configuration file on the control plane to exempt the specific ServiceAccount or namespace from the restricted check.. The Pod Security admission configuration file (passed to kube-apiserver via --admission-control-config-file) supports per-namespace and per-ServiceAccount exemptions from a given Pod Security level. Exempting the specific ServiceAccount or namespace that runs the legacy root-requiring workload lets that pod start while the 'restricted' profile remains enforced everywhere else. This is the least-privilege, targeted approach that preserves cluster-wide security posture.

Answer

Disable the Pod Security admission controller entirely across the cluster.

Answer

Set the namespace enforce level to 'privileged' permanently.

Answer

Mount the host socket inside the pod to bypass user namespace restrictions.

Question 3

A security engineer wants to apply Pod Security Standards globally across an entire namespace using the modern built-in admission mechanism. Which approach should be used?

Accepted Answer

Apply labels such as 'pod-security.kubernetes.io/enforce=restricted' to the namespace metadata.. The correct approach is to apply labels to the namespace metadata, such as 'pod-security.kubernetes.io/enforce=restricted'. This is the built-in Pod Security Admission (PSA) mechanism introduced in Kubernetes 1.23, which enforces Pod Security Standards (PSS) at the namespace level. By labeling the namespace, the PSA controller automatically validates pod creation against the specified policy (privileged, baseline, or restricted) without needing external webhooks or node-level changes. This method is the modern, native way to apply PSS globally across a namespace.

Answer

Create a MutatingWebhookConfiguration that injects security contexts into every pod spec.

Answer

Modify the kubelet configuration file on every worker node to enable restricted mode.

Answer

Deploy a custom PodSecurityPolicy object targeting the namespace selector.

Question 4

An organization mandates that all traffic entering the service mesh must be decrypted at the ingress gateway, inspected by a Web Application Firewall (WAF), and then re-encrypted using mTLS before reaching backend pods. What is this architectural pattern called within service mesh security?

Accepted Answer

TLS re-encryption (or edge termination with backend mTLS). TLS re-encryption (also called edge termination with backend mTLS) is the pattern where the ingress gateway terminates external TLS, passes traffic to a WAF or inspection layer in plaintext, then re-encrypts with mTLS before forwarding to backend pods. This preserves end-to-end encryption inside the mesh while allowing inspection at the edge.

Answer

HTTP plaintext tunneling

Answer

Pod security standard restriction

Answer

DNS-based load balancing

Question 5

An application pod requires read access to secrets in the 'production' namespace. You need to bind a pre-existing ClusterRole named 'secret-reader' to a service account named 'app-sa' in that namespace. Which RBAC resource accomplishes this?

Accepted Answer

RoleBinding referencing the ClusterRole 'secret-reader'. A RoleBinding grants the permissions defined in a referenced Role or ClusterRole to subjects within a specific namespace. Binding the pre-existing ClusterRole 'secret-reader' via a RoleBinding in the 'production' namespace grants those permissions only in that namespace to the 'app-sa' service account. This is the standard pattern for reusing a ClusterRole's permission set in a single namespace.

Answer

ClusterRoleBinding referencing the Role 'secret-reader'

Answer

NamespaceRoleBinding referencing the ClusterRole

Answer

ServiceAccountBinding referencing the ClusterRole

Question 6

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 7

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 8

Which of the following represents a common cloud-native supply chain attack vector where malicious actors publish packages with names similar to popular libraries?

Accepted Answer

Typosquatting. Typosquatting is a supply chain attack where adversaries publish malicious packages with names closely resembling legitimate, popular libraries (e.g., 'lodahs' instead of 'lodash'). Developers who mistype the package name during installation inadvertently pull in malicious code. This is a well-documented cloud-native supply chain threat affecting npm, PyPI, and container registries.

Answer

Kernel memory exploitation via unprivileged user namespaces

Answer

Denial of Service via packet flooding

Answer

Man-in-the-Middle etcd keystore sniffing

Question 9

You are troubleshooting a custom controller that fails to read ConfigMaps in the 'kube-system' namespace despite having a ClusterRole bound via a ClusterRoleBinding. What is the most likely reason for this failure?

Accepted Answer

The ClusterRole lacks the required verbs ('get', 'list', 'watch') or resources ('configmaps') for that API group.. A ClusterRole defines permissions on cluster-scoped resources or across all namespaces. If the ClusterRole bound to the controller's ServiceAccount does not include 'get', 'list', 'watch' on 'configmaps' in the relevant API group, the controller cannot read ConfigMaps in any namespace, including kube-system.

Answer

ClusterRoleBindings cannot be used with ConfigMaps.

Answer

ClusterRoleBindings are automatically disabled in 'kube-system'.

Answer

ConfigMaps in 'kube-system' can only be accessed using ServiceAccounts named 'default'.

Question 10

You are deploying a ValidatingWebhookConfiguration to inspect incoming pod creations. What happens if the webhook fails and the 'failurePolicy' in the webhook configuration is set to 'Fail'?

Accepted Answer

The API request is rejected.. When failurePolicy is set to Fail, the API server treats any webhook call failure (network error, timeout, non-2xx response) as a denial, so the pod creation request is rejected. This is the safe default for security-critical validation because it prevents unvalidated resources from being admitted. The request fails closed rather than open.

Answer

The API request is allowed to proceed without validation.

Answer

The pod is created in a suspended state until the webhook recovers.

Answer

The kube-apiserver restarts automatically.

Question 11

An auditor notices that the kubelet on worker nodes is configured with --protect-kernel-defaults=true. What is the security purpose of this flag?

Accepted Answer

It ensures that critical kernel parameters match expected secure baseline settings and prevents unauthorized modification.. The --protect-kernel-defaults flag in the kubelet enforces that certain kernel parameters (sysctls) and kernel module settings match the kubelet's expected secure defaults. When enabled, the kubelet will fail to start or will refuse to run pods if it detects that critical kernel tunables—such as those related to IP forwarding, memory overcommit, or panic settings—have been changed from the kubelet's built-in safe values. This prevents accidental or malicious modification of kernel settings that could weaken container isolation or destabilize the node.

Answer

It encrypts all kernel log (kmsg) outputs.

Answer

It prevents the Linux kernel from running container workloads as root.

Answer

It forces the kubelet to run inside an isolated kernel container.

Question 12

Under the cloud native shared responsibility model, who is responsible for ensuring that the underlying physical servers and hardware security modules (HSMs) are secure and compliant?

Accepted Answer

The cloud service provider. Under the cloud native shared responsibility model, the cloud service provider (CSP) owns and operates the physical infrastructure layer — data centers, physical servers, networking hardware, and hardware security modules (HSMs). Customers consume these as abstracted services and cannot patch, inspect, or physically secure them, so the CSP is contractually and technically responsible for their security and compliance (e.g., FIPS 140-2 validated HSMs, SOC 2, ISO 27001 attestations).

Answer

The container registry administrator

Answer

The application developer

Answer

The Kubernetes administrator

Question 13

A developer builds a Docker container image using an outdated base image that contains known critical operating system vulnerabilities. Before deploying this image to a production Kubernetes cluster, which security practice should be enforced to detect this issue?

Accepted Answer

Configuring static container image vulnerability scanning in the CI/CD pipeline.. Configuring static container image vulnerability scanning in the CI/CD pipeline is correct because it inspects the image's OS packages and application dependencies against CVE databases before the image is deployed. This directly detects outdated base images with known critical vulnerabilities, allowing the pipeline to fail the build or block promotion. It is the earliest and most cost-effective control point for this class of issue.

Answer

Enabling Kubernetes Role-Based Access Control (RBAC).

Answer

Deploying a network mesh like Istio with mutual TLS.

Answer

Applying Pod Security Standards at the Restricted level.

Question 14

A security architect is designing role-based access control (RBAC) to comply with NIST access control principles of least privilege. Which THREE best practices should be followed when creating Roles and ClusterRoles? (Choose THREE)

Accepted Answer

Scrutinize and restrict the use of ClusterRoleBindings to cluster-wide resources. Option A is correct because ClusterRoleBindings grant permissions across the entire cluster, so they should be tightly scrutinized and reserved for genuinely cluster-scoped resources to uphold least privilege. Option B is correct because wildcards (*) in API groups, resources, or verbs grant far broader access than intended, violating least privilege and increasing blast radius; explicit permissions should be enumerated instead. Option E is correct because RBAC permissions drift over time as roles and bindings accumulate, so regular auditing is essential to detect and remove excessive or stale privileges. Options C and D are incorrect: allowing all users to read Secrets by default and granting cluster-admin to all service accounts both directly violate least privilege by providing excessive, unnecessary access.

Answer

Allow all users to read Kubernetes Secrets by default

Answer

Grant cluster-admin permissions to all application service accounts for ease of deployment

Question 15

An organization wants to enforce that no containers run with privileged security contexts across multiple clusters. They implement admission control validation. In the context of cloud native security principles, what type of control is this?

Accepted Answer

Preventative automated policy control. Admission control validation in Kubernetes intercepts API requests before an object is persisted, and if the validating webhook rejects the request, the privileged pod is never created. This is a preventative control because it stops the non-compliant configuration from ever reaching the cluster, rather than detecting it after the fact. In cloud native security terms, it is automated (policy-as-code, e.g., OPA Gatekeeper or Kyverno) and preventative by design.

Answer

Detective manual control

Answer

Corrective physical control

Answer

Compensating detective control