KCSA Practice Exam 2 — 20 Questions

Question 1

When configuring a Pod to run securely, which setting in the container's securityContext should be used to explicitly drop all default Linux capabilities and only retain required ones?

Accepted Answer

capabilities.drop: ["ALL"]. In the container's securityContext, capabilities.drop: ["ALL"] removes every default Linux capability (like NET_RAW, CHOWN, SETUID) from the container process, after which you can selectively add back only what the workload needs via capabilities.add. This follows the principle of least privilege and is the canonical hardening pattern for Pods.

Answer

runAsNonRoot: true

Answer

capabilities.add: ["ALL"]

Answer

privileged: true

Question 2

A cluster administrator needs to grant read-only access to pods within the 'development' namespace using Kubernetes RBAC. Which resource kind should be used to define the permissions?

Accepted Answer

Role. A Role is a namespaced Kubernetes resource that defines permissions within a specific namespace. Since the requirement is to grant read-only access to pods in the 'development' namespace, a Role scoped to that namespace is the correct choice. It can be bound to a user, group, or service account via a RoleBinding to grant the necessary permissions.

Answer

SecurityContextConstraints

Answer

PodSecurityPolicy

Answer

ClusterRole

Question 3

A platform engineer wants to configure a container runtime security tool that monitors system calls and sends alerts about potential threats in a Kubernetes cluster. Which component of the container runtime architecture intercepts these system calls?

Accepted Answer

eBPF kernel probes. eBPF (extended Berkeley Packet Filter) kernel probes are the correct answer because they allow programs to run in the Linux kernel without changing kernel source code or loading modules. In container runtime security, tools like Falco, Tetragon, and Cilium use eBPF to hook into system calls (syscalls) and other kernel events, monitoring container behavior for threats. This interception happens at the kernel level, providing deep visibility into syscalls made by containers.

Answer

The coreDNS plugin

Answer

The Kubernetes storage controller

Answer

The kube-apiserver admission webhook

Question 4

An administrator wants to verify that etcd database defragmentation is performed periodically to reclaim storage space after large amounts of data churn. Which etcdctl command defragments an etcd member?

Accepted Answer

etcdctl defrag. The etcdctl defrag command defragments an etcd member's database, reclaiming storage space after data churn (e.g., many writes and deletes). Defragmentation compacts the underlying BoltDB file, reducing its size and improving performance. It is typically run periodically on each etcd member, often after compaction.

Answer

kubectl etcd-clean

Answer

etcdctl compact

Answer

etcdctl cleanup storage

Question 5

A compliance team is adopting the NIST SP 800-190 standard to secure their container image pipeline. Which THREE practices are recommended in this framework for managing container images? (Choose THREE)

Accepted Answer

Employ trusted base images from verified publishers. NIST SP 800-190 Section 3.1 (Image Vulnerabilities) recommends using trusted base images from verified publishers (A) to reduce the risk of inheriting vulnerabilities or malicious code from untrusted sources, since every layer of a container image becomes part of the running container. The framework also calls for vulnerability scanning throughout the image lifecycle, including in the CI/CD pipeline and the registry (B), so that known CVEs are detected before deployment and continuously re-evaluated as new vulnerabilities are disclosed. Additionally, NIST SP 800-190 recommends digitally signing images and verifying those signatures (E) to establish provenance and integrity, ensuring that only images from authorized sources are deployed and that images have not been tampered with. Option C is incorrect because storing plaintext passwords in Dockerfile ENV directives exposes secrets in image layers and metadata, directly violating NIST guidance on protecting secrets. Option D is incorrect because relying exclusively on public unverified base images increases supply-chain risk and contradicts the recommendation to use trusted, verified image sources.

Answer

Store plaintext passwords directly inside Dockerfile ENV directives

Answer

Rely exclusively on public unverified base images to speed up development

Question 6

An administrator wants to prevent users from creating pods that mount the host network ('hostNetwork: true'). Which tool or feature is best suited to enforce this restriction natively across the cluster?

Accepted Answer

Pod Security admission controller with baseline or restricted profile. Pod Security admission (PSA) is the built-in Kubernetes admission controller that enforces Pod Security Standards at the namespace level using labels. The baseline and restricted profiles explicitly disallow hostNetwork: true, so labeling the namespace with pod-security.kubernetes.io/enforce: baseline (or restricted) blocks pods that request host networking. This is the native, cluster-wide enforcement mechanism.

Answer

ResourceQuota limiting network interfaces

Answer

RBAC ClusterRole restricting pod creation

Answer

NetworkPolicy with a deny-all rule

Question 7

A platform engineer needs to secure an Ingress resource using TLS termination, ensuring that sensitive private keys are stored securely within the cluster and referenced safely. Which Kubernetes resource should be created to store the TLS certificate and private key pair?

Accepted Answer

Secret of type kubernetes.io/tls. A Secret of type kubernetes.io/tls is the correct resource because it is specifically designed to hold a TLS certificate and its private key. The Ingress resource references this Secret in its tls section, and the ingress controller uses it to terminate TLS. Kubernetes treats this Secret type with appropriate handling for the required tls.crt and tls.key fields.

Answer

PersistentVolumeClaim

Answer

CertificateSigningRequest

Answer

ConfigMap

Question 8

You are performing a security review of etcd cluster membership. You need to list all active members of the etcd cluster and check their health status using the command line. Which etcdctl command is correct?

Accepted Answer

etcdctl member list and etcdctl endpoint health. etcdctl provides two distinct subcommands for this task: 'etcdctl member list' enumerates all cluster members with their IDs, peer URLs, and client URLs, while 'etcdctl endpoint health' queries each endpoint to verify it can serve requests and is not lagging. Together they satisfy the requirement to list active members and check their health.

Answer

etcdctl check membership

Answer

etcdctl cluster status

Answer

kubectl get etcdmembers

Question 9

You want to ensure that a newly created Role in namespace 'finance' cannot be modified or deleted by regular developers who have edit permissions. Which RBAC feature or design prevents unauthorized privilege escalation through Role manipulation?

Accepted Answer

The API server's built-in privilege escalation prevention check, which blocks users from granting permissions they do not hold.. Kubernetes RBAC has a built-in privilege escalation prevention check: the API server blocks a user from creating or updating a Role/ClusterRole that grants permissions the user does not already hold (unless they have the 'escalate' or 'bind' verb). This prevents a developer with edit rights from crafting a Role that grants cluster-admin and then binding to it.

Answer

Enabling Pod Security Standards on the finance namespace.

Answer

Setting the Role resource to immutable via 'immutable: true'.

Answer

A mandatory MutatingWebhookConfiguration that strips administrative verbs.

Question 10

An enterprise cluster requires that all incoming NetworkPolicies must default to denying all traffic unless explicitly allowed. A developer creates a namespace but forgets to apply any policies. What is the default behavior of Kubernetes regarding inter-pod traffic within a namespace when no NetworkPolicies are present?

Accepted Answer

All traffic between pods is allowed by default.. Kubernetes NetworkPolicies operate on an additive allow-list model: if no policy selects a pod, that pod is non-isolated and all ingress/egress traffic is permitted. The default-deny posture only takes effect once at least one NetworkPolicy selects the pod and does not explicitly allow the traffic. Therefore, a namespace with zero policies allows unrestricted inter-pod communication.

Answer

Only traffic originating from the kube-system namespace is allowed.

Answer

Traffic is allowed only if the pods share the same node.

Answer

All traffic between pods is denied by default.

Question 11

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?

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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