KCSA Practice Test 4 — 10 Questions

Question 1

Which attack vector involves tricking a Kubernetes cluster user or service into executing unintended actions via authenticated sessions, frequently mitigated by robust CSRF defenses and proper API design?

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

Accepted Answer

Cross-Site Request Forgery (CSRF). Cross-Site Request Forgery (CSRF) tricks an authenticated user's browser or session into sending unintended requests to a trusted application — for example, a malicious page causing a logged-in Kubernetes dashboard user to issue API calls. Mitigations include CSRF tokens, SameSite cookies, and requiring re-authentication for sensitive operations, which is exactly what the question describes.

Answer

Denial of Service via memory leaks

Answer

Container escape via kernel flaw

Answer

Image tag mutation

Question 2

Which of the following describes a recommended security practice when managing Kubernetes Secrets?

Accepted Answer

Limit RBAC access so that only necessary users and service accounts can read secrets.. The recommended practice is to follow the principle of least privilege by restricting who can read Secrets. Kubernetes Secrets are not encrypted by default; they are only base64-encoded, so any user or service account with get/list/watch permissions on Secrets can easily decode and view sensitive data. Limiting RBAC access ensures that only authorized workloads and administrators can access specific Secrets, reducing the attack surface and potential for credential leakage.

Answer

Use ConfigMaps for passwords and Secrets for plain text configuration.

Answer

Store secret values in plain text inside public Git repositories for easy collaboration.

Answer

Disable authentication on the Kubernetes API server to simplify secret retrieval.

Question 3

A developer accidentally committed plain-text database passwords into a public Git repository. The password was stored in a Kubernetes Secret manifest. What immediate remediation step should be taken regarding the Secret?

Accepted Answer

Rotate the credential in the underlying database, then update the Kubernetes Secret with the new value.. Once a credential is exposed in a public repository, it must be treated as compromised — the only safe remediation is to rotate the password in the database and update the Kubernetes Secret with the new value. Deleting or re-encoding the Secret does nothing because the old password remains valid in the database and is already in Git history.

Answer

Apply a DenyAll NetworkPolicy to the namespace.

Answer

Delete the Secret object and restart all cluster nodes.

Answer

Change the Secret manifest encoding from base64 to hex format.

Question 4

Your team is storing sensitive database credentials in Kubernetes Secrets. A security review reveals that base64 encoding does not provide encryption at rest. What mechanism should you enable to ensure Secrets are encrypted when stored in etcd?

Accepted Answer

Configure an EncryptionConfiguration file and reference it via the '--encryption-provider-config' flag on the kube-apiserver.. To encrypt Secrets at rest in etcd, you must configure an EncryptionConfiguration file and pass it to the kube-apiserver via the --encryption-provider-config flag. This enables encryption of resources like Secrets before they are stored in etcd.

Answer

Apply a MutatingWebhookConfiguration to automatically hash passwords using bcrypt.

Answer

Enable TLS encryption for all intra-cluster communication using kubeadm configuration.

Answer

Set the secret type to 'kubernetes.io/encrypted-secret'.

Question 5

A security engineer is configuring a service mesh using Istio to ensure that all east-west traffic between microservices is mutually authenticated and encrypted. Which custom resource must be configured with a STRICT mTLS mode to enforce this requirement cluster-wide?

Accepted Answer

PeerAuthentication. PeerAuthentication is the Istio custom resource used to configure mTLS settings for workloads. Setting its mTLS mode to STRICT enforces mutual TLS for all traffic to and from the selected workloads, ensuring east-west traffic is authenticated and encrypted.

Answer

EnvoyFilter

Answer

AuthorizationPolicy

Answer

DestinationRule

Question 6

An engineer is reviewing the threat model of a Kubernetes cluster exposed to the public internet via a LoadBalancer service. Which configuration flaw most commonly leads to unintended external exposure of administrative dashboards?

Accepted Answer

Exposing management dashboards via LoadBalancer or NodePort services without authentication or IP whitelisting. The most common cause of unintended external exposure of administrative dashboards (Kubernetes Dashboard, kube-state-metrics, Prometheus, Argo CD, etc.) is exposing them via a LoadBalancer or NodePort Service without authentication or IP whitelisting. This publishes the dashboard to the public internet, and if it lacks strong auth or has default credentials, attackers can reach it directly — this is the pattern behind many real-world Kubernetes breaches. The fix is to use ClusterIP with an authenticating ingress, or restrict access via IP allowlists and strong auth.

Answer

Configuring liveness probes with HTTP GET requests instead of TCP socket checks

Answer

Setting imagePullPolicy to IfNotPresent on production deployments

Answer

Using ClusterIP service types for internal database connectivity

Question 7

Which open-source auditing tool provides compliance scores and checks against Kubernetes security frameworks such as NSA-CISA and CIS?

Accepted Answer

Kubescape. Kubescape is an open-source Kubernetes security platform that scans clusters and manifests against frameworks like NSA-CISA, MITRE ATT&CK, and CIS Benchmarks, producing compliance scores and remediation guidance. It is specifically designed for Kubernetes posture management and is widely used in CNCF-aligned environments. The other options are Kubernetes components or networking tools, not auditing/compliance scanners.

Answer

Kube-dns

Answer

Metric-server

Answer

Cilium

Question 8

A security auditor discovers that anonymous authentication is accidentally enabled on the Kubernetes API server, allowing unauthenticated read access to cluster health endpoints. Which API server flag must be modified to disable anonymous requests?

Accepted Answer

--anonymous-auth=false. The --anonymous-auth flag on kube-apiserver controls whether unauthenticated requests are treated as anonymous users (system:anonymous). Setting --anonymous-auth=false rejects requests without valid credentials with a 401 Unauthorized response, closing the exposure of health/version endpoints to unauthenticated clients. This is the documented, supported way to disable anonymous access and is enforced by CIS Kubernetes Benchmark control 1.2.1.

Answer

--secure-port=0

Answer

--authorization-mode=AlwaysAllow

Answer

--disable-anonymous=true

Question 9

Which TWO types of selectors can be used within a Kubernetes NetworkPolicy ingress rule to specify allowed traffic sources?

Accepted Answer

namespaceSelector. In a Kubernetes NetworkPolicy ingress rule, the from field accepts three selector-based peer types: ipBlock, namespaceSelector, and podSelector. Option B (namespaceSelector) is correct because it selects entire namespaces by their labels, allowing traffic from all pods in matching namespaces (or, when combined with a podSelector in the same from element, only matching pods in matching namespaces). Option E (podSelector) is correct because it selects pods by their labels within the policy's own namespace, defining which pods may send traffic to the selected pods. Option A (serviceSelector) is incorrect because NetworkPolicy peers are never defined by Service; Services are not valid peer selectors in the API. Option C (ingressSelector) is incorrect because no such selector type exists in the NetworkPolicy spec. Option D (nodeSelector) is incorrect because NetworkPolicy operates at the pod/namespace/IP level and cannot select peers by node labels.

Answer

serviceSelector

Answer

ingressSelector

Answer

nodeSelector

Question 10

Which of the following best describes the principle of 'Defense-in-Depth' in cloud native security architectures?

Accepted Answer

Implementing multiple overlapping security controls across the 4Cs so that a single failure does not lead to compromise. Defense-in-Depth means layering multiple independent, overlapping security controls across the 4Cs (Cloud, Cluster, Container, Code) so that the failure of any single control does not result in full compromise. In cloud native terms this includes network policies, RBAC, Pod Security Admission, image scanning, mTLS, runtime detection, and secrets encryption — each compensating for gaps in the others.

Answer

Outsourcing all security responsibilities to the cloud provider

Answer

Ensuring every developer has cluster admin access for rapid debugging

Answer

Relying entirely on a strong perimeter firewall to block all malicious actors