KCSA Practice Test 16 — 15 Questions

Question 1

An attacker gains execution in a container and attempts to perform a denial of service attack on other workloads sharing the same Kubernetes node by consuming all available CPU and memory resources. What Kubernetes feature prevents this cross-workload resource exhaustion?

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

Accepted Answer

Container Resource Requests and Limits (CPU and memory). Container Resource Requests and Limits (CPU and memory) allow you to specify the minimum resources a container needs (requests) and the maximum it can consume (limits). By setting limits, you prevent a single container from monopolizing node resources, thus protecting other workloads from resource exhaustion and denial of service.

Answer

ValidatingWebhookConfiguration rejecting pod creations

Answer

NetworkPolicy egress blocking rules

Answer

ClusterRoleBindings restricting RBAC permissions

Question 2

Which TWO of the following kubelet security configurations are critical for preventing container escape and unauthorized node API access? (Choose TWO)

Accepted Answer

Configure kubelet authorization mode to Webhook.. Option C is correct because setting the kubelet authorization mode to Webhook delegates authorization decisions to the API server's SubjectAccessReview, ensuring that only authenticated and properly authorized subjects (such as nodes and system components) can perform actions against the kubelet's API, which prevents unauthorized node API access. Option E is correct because the kubelet's read-only port (default 10255) serves unauthenticated and unencrypted data; setting readOnlyPort to 0 disables it entirely, closing an anonymous access vector that could leak node and pod information or be abused. Option A is wrong because enabling anonymous authentication on the secure port would allow unauthenticated requests, directly undermining access control rather than preventing it. Option B is wrong because running kubelet containers in privileged mode grants broad host capabilities and increases container-escape risk instead of mitigating it. Option D is wrong because authorization.mode AlwaysAllow permits all requests without any authorization checks, which is the opposite of a secure configuration.

Answer

Enable anonymous authentication on the kubelet secure port.

Answer

Run kubelet containers in privileged mode.

Answer

Set authorization.mode to AlwaysAllow.

Question 3

An administrator needs to ensure that the Kubernetes API server does not allow insecure cipher suites during TLS handshakes. Which API server flag allows specifying the exact cipher suites permitted?

Accepted Answer

--tls-cipher-suites. The --tls-cipher-suites flag on the kube-apiserver allows administrators to specify a comma-separated list of allowed cipher suites for TLS handshakes. This directly controls which cipher suites the API server will accept, enabling compliance with security policies that require strong ciphers and disallow insecure ones.

Answer

--cipher-list

Answer

--secure-ciphers

Answer

--etcd-cipher-suites

Question 4

A security auditor is evaluating a cloud-native deployment. The team states they practice 'shift-left' security. Which of the 4Cs does this practice primarily target?

Accepted Answer

Code. 'Shift-left' security means moving security practices earlier in the software development lifecycle — into design, coding, and CI/CD — which maps to the 'Code' layer of the 4Cs (Cloud, Cluster, Container, Code). This includes SAST, dependency scanning, secrets detection, and secure coding standards applied before deployment.

Answer

Container

Answer

Cluster

Answer

Cloud

Question 5

When configuring a MutatingWebhookConfiguration, you notice that mutating webhooks are executed before validating webhooks. Why is this execution order critical for security and consistency?

Accepted Answer

It ensures that validating webhooks evaluate the final, mutated state of the object rather than the original input.. Mutating webhooks run before validating webhooks so that validating webhooks evaluate the final, mutated version of the object. This ensures that validation is performed against the actual state that will be persisted, preventing inconsistencies and security gaps where a mutation could bypass validation.

Answer

It prevents mutating webhooks from timing out while waiting for validation checks.

Answer

Mutating webhooks require encryption keys generated during the validation phase.

Answer

It allows validating webhooks to override any changes made by mutating webhooks if security violations occur.

Question 6

A security incident response team discovers that a vulnerability in a third-party Python library allowed remote code execution inside a pod. In the context of defense-in-depth and the 4Cs, which layer primarily failed or was unmitigated, requiring remediation at the source?

Accepted Answer

Code layer. A vulnerability in a third-party Python library that enables RCE inside a pod is a Code-layer failure. The Code layer encompasses application code, dependencies, libraries, and the software supply chain. Remediation must occur at the source — patching or replacing the vulnerable library, scanning dependencies, and rebuilding the image — because the flaw originates in the application's code/dependency stack, not in the cluster or container runtime.

Answer

Cloud layer

Answer

Cluster layer

Answer

Container layer

Question 7

You are reviewing admission webhook configurations and notice that timeoutSeconds is set to 3 seconds for a critical validation webhook. If the webhook server takes 4 seconds to respond, what does the API server do when failurePolicy is 'Ignore'?

Accepted Answer

It allows the API request to proceed as if the webhook succeeded.. With failurePolicy set to Ignore, when the webhook exceeds timeoutSeconds (3s) and takes 4s to respond, the API server abandons the call and admits the request as if the webhook had allowed it. Ignore means failures — including timeouts — are non-blocking. The request proceeds without the webhook's validation result.

Answer

It quarantines the pod in a Pending state.

Answer

It rejects the API request immediately.

Answer

It retries the webhook request indefinitely until it responds.

Question 8

An enterprise is deploying a zero-trust architecture across their Kubernetes environments. They mandate that all container images must be signed using Cosign and verified at admission time using Kyverno. This technical control directly hardens which of the 4Cs layers?

Accepted Answer

Container layer. Cosign image signing combined with Kyverno admission-time verification is a container-layer control because it governs the integrity and provenance of the container image artifact itself before it is admitted to run. The Container layer of the 4Cs (Cloud, Cluster, Container, Code) covers image contents, image provenance, and runtime configuration of the container. Signing and verifying images ensures only trusted, unmodified images execute, which is a direct hardening of that layer.

Answer

Code layer

Answer

Cloud layer

Answer

Cluster layer

Question 9

An Ingress controller is deployed in a cluster, and security auditors request that incoming traffic must be restricted to specific trusted external CIDR blocks. Which standard Ingress annotation is commonly supported by popular Ingress controllers (such as ingress-nginx) to achieve IP-based allowlisting?

Accepted Answer

nginx.ingress.kubernetes.io/whitelist-source-range. The ingress-nginx controller supports the annotation nginx.ingress.kubernetes.io/whitelist-source-range, which accepts a comma-separated list of CIDR blocks. When set, the controller's NGINX configuration adds allow/deny directives so that only requests originating from those CIDRs are permitted; all other source IPs receive a 403. This is the standard, documented mechanism for IP allowlisting at the Ingress layer in ingress-nginx.

Answer

ingress.kubernetes.io/allowed-source-cidrs

Answer

networking.k8s.io/ip-filter

Answer

kubernetes.io/ingress.allow-ips

Question 10

A security team needs to ensure that Kubernetes nodes have secure file permissions for the kubelet configuration files, in alignment with CIS benchmarks. What should the file permissions on "/etc/kubernetes/kubelet.conf" typically be set to?

Accepted Answer

600. CIS Kubernetes Benchmark control 4.1.1 requires that kubelet configuration files such as /etc/kubernetes/kubelet.conf be owned by root:root and have permissions of 600 or more restrictive. The 600 permission means only the owner (root) can read and write the file, preventing non-privileged users from reading the kubelet's credentials — which include the client certificate and key used to authenticate to the API server. If these files were world-readable, any local user could impersonate the kubelet and potentially escalate privileges within the cluster.

Answer

777

Answer

755

Answer

644

Question 11

When considering the principle of least privilege within a cloud native architecture, what is the recommended approach for granting permissions to a Kubernetes application running in a Pod?

Accepted Answer

Create a dedicated ServiceAccount with strictly scoped RBAC roles granting only required API permissions.. Least privilege in Kubernetes is achieved by creating a dedicated ServiceAccount per workload and binding it to narrowly scoped Roles or ClusterRoles that grant only the specific API verbs and resources the application needs. This limits the blast radius if the Pod is compromised, since its mounted token can only perform the permitted actions.

Answer

Share a single global ServiceAccount across all namespaces in the cluster.

Answer

Mount the default ServiceAccount token with cluster-admin rights to ensure compatibility.

Answer

Disable authentication for the application namespace entirely.

Question 12

An auditor is assessing an organization's cloud-native supply chain security posture. Which THREE controls should be in place to ensure artifact integrity and safety across the Code and Container layers? (Choose THREE)

Accepted Answer

Using automated dependency scanners (SCA) to identify vulnerable libraries in source code. Option B is correct because Software Composition Analysis (SCA) tools automatically scan source code and dependency manifests (e.g., package-lock.json, pom.xml) to detect known-vulnerable open-source libraries, directly protecting the Code layer of the supply chain. Option D is correct because cryptographically signing container images (e.g., with Sigstore/Cosign or Notary) and enforcing signature verification via an admission controller (e.g., OPA Gatekeeper, Kyverno) ensures only trusted, untampered images are deployed to the Container layer. Option E is correct because generating and storing Software Bills of Materials (SBOMs, e.g., in SPDX or CycloneDX format) provides a verifiable inventory of components in each build, enabling rapid vulnerability tracing and integrity auditing across both layers. Option A is incorrect because granting root SSH access to all developers on production worker nodes violates least privilege and expands the attack surface rather than ensuring artifact integrity. Option C is incorrect because manually configuring physical server rack layouts is a data-center facilities task unrelated to cloud-native Code and Container supply chain security controls.

Answer

Granting root SSH access to all developers on production worker nodes

Answer

Manually configuring physical server rack layouts in the data center

Question 13

Which TWO of the following scenarios represent severe security misconfigurations in a Kubernetes cluster control plane? (Choose TWO)

Accepted Answer

The API server is configured with --insecure-port pointing to an active HTTP listener.. Option C is correct because configuring the API server with --insecure-port to an active HTTP listener exposes an unauthenticated, unencrypted endpoint that bypasses TLS and normal authentication/authorization, which is a severe control-plane misconfiguration. Option D is correct because enabling anonymous authentication (--anonymous-auth=true) on the API server or kubelet allows unauthenticated requests to be treated as the system:anonymous user, potentially granting access to sensitive endpoints or cluster resources. Option A is not a misconfiguration because client certificate authentication with mTLS is a recommended secure configuration for etcd. Option B is not a misconfiguration because Webhook authorization mode is a valid and secure kubelet authorization setting. Option E is not a misconfiguration because encrypting Secrets at rest with an EncryptionConfiguration file is a security best practice.

Answer

Etcd is configured with client certificate authentication and mTLS enabled.

Answer

Kubelet authorization mode is set to Webhook.

Answer

Secrets are encrypted at rest using an EncryptionConfiguration file.

Question 14

Which TWO of the following actions are risks associated with leaving the Kubernetes API server's insecure port enabled? (Choose TWO)

Accepted Answer

Complete bypass of all authentication mechanisms.. The insecure port (historically --insecure-port, default 8080) on the Kubernetes API server serves requests over plain HTTP with no TLS, and by design it does not perform any authentication, so option B is correct: any client that can reach that port is treated as an anonymous, unauthenticated user. Because requests arriving on the insecure port are also not subjected to authorization checks, option E is correct: the usual RBAC evaluation is skipped, effectively granting the caller full access to the API as if they were an administrator. Options A and C are wrong because TLS 1.3 enforcement and mutual TLS client certificate verification are properties of the secure port (6443), not the insecure one, which uses no encryption or client certs at all. Option D is wrong because etcd encryption at rest is configured separately via EncryptionConfiguration on the kube-apiserver and is never automatically activated by the insecure port.

Answer

Enforcement of strict TLS 1.3 encryption on all connections.

Answer

Mandatory mutual TLS client certificate verification.

Answer

Automatic activation of etcd encryption at rest.

Question 15

Which THREE configurations should be applied to a Kubernetes Pod Security Standard 'restricted' profile compliance checklist? (Choose three)

Accepted Answer

Restricting container capabilities to drop ALL and only permit essential ones like NET_BIND_SERVICE. The Kubernetes Pod Security Standard 'restricted' profile is the most hardened policy, so option B is correct because it mandates dropping ALL Linux capabilities and only adding back the minimal ones actually needed (e.g., NET_BIND_SERVICE), which follows the least-privilege principle. Option C is correct because the restricted profile explicitly requires allowPrivilegeEscalation: false in the container securityContext to prevent processes from gaining more privileges than their parent (e.g., via setuid binaries or file capabilities). Option E is correct because runAsNonRoot: true is required so the kubelet validates that containers do not run as UID 0, blocking root-owned processes. Option A does not belong because privileged: true is forbidden by the restricted profile, as it grants nearly all host capabilities and device access. Option D does not belong because mounting the host root filesystem read-write is prohibited; the restricted profile disallows hostPath volumes and requires read-only root filesystems where applicable.

Answer

Allowing privileged: true for all application containers

Answer

Mounting the host root filesystem in read-write mode