KCSA Practice Test 1 — 30 Questions

Question 1

You are troubleshooting a container image vulnerability scan report that flagged a high-severity CVE in a base image layer. The development team wants to ensure that vulnerable container images are automatically prevented from being deployed to any namespace in the cluster. Which Kubernetes mechanism should you implement?

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

Accepted Answer

Configure a validating admission webhook to inspect image metadata and reject deployments with known CVEs. A validating admission webhook intercepts pod creation requests before they are persisted to etcd and can inspect image metadata (via registries or scanning tools) to reject deployments containing known CVEs. This enforces policy at the cluster level across all namespaces, preventing vulnerable images from ever running.

Answer

Enable resource quotas on the default namespace

Answer

Rotate the cluster certificate authority

Answer

Add network policies to restrict outbound CVE database queries

Question 2

Under NIST guidelines for continuous monitoring in cloud-native environments, which Kubernetes mechanism allows operators to enforce cryptographic integrity of container images at runtime?

Accepted Answer

Image signing and verification via admission controllers. Admission controllers in Kubernetes can intercept pod creation requests and validate that container images are signed by trusted authorities before allowing them to run. By integrating image signing (e.g., Cosign/Notary) with an admission controller (e.g., OPA Gatekeeper, Kyverno, or the Sigstore policy controller), operators enforce cryptographic integrity at runtime admission. This directly satisfies NIST continuous monitoring guidance for verifying artifact integrity in cloud-native environments.

Answer

Increasing pod memory limits

Answer

Disabling the default namespace

Answer

Using ClusterRoleBindings with wildcards

Question 3

Which THREE mechanisms are used in a zero-trust platform security model for cloud-native applications? (Choose three)

Accepted Answer

Implementing microsegmentation via Kubernetes NetworkPolicies and service mesh auth policies. Option B is correct because zero-trust requires microsegmentation, and Kubernetes NetworkPolicies restrict pod-to-pod traffic at L3/L4 while service mesh authorization policies (e.g., Istio AuthorizationPolicy) enforce identity-based L7 access controls between workloads. Option C is correct because enforcing mutual TLS for all internal service-to-service communications cryptographically verifies both client and server identities, eliminating implicit trust based on network location. Option D is correct because admission webhooks (ValidatingAdmissionWebhook) intercept API server requests before object persistence, allowing policies to reject non-compliant workloads and enforce security baselines at creation time. Option A is incorrect because granting cluster-admin to all service accounts violates least privilege and massively expands the blast radius, the opposite of zero-trust. Option E is incorrect because assuming the internal network is secure and trusting all pods by default is the classic perimeter-trust model that zero-trust explicitly rejects.

Answer

Granting cluster-admin permissions to all application service accounts

Answer

Assuming internal cluster networks are fully secure and trusting all pods by default

Question 4

An administrator wishes to defend against supply chain attacks involving malicious third-party Kubernetes operators installed from public catalogs. What security practice is most effective before installing such operators?

Accepted Answer

Reviewing requested RBAC permissions, operator manifests, and verifying image provenance. Before installing third-party operators, the most effective practice is to review the requested RBAC permissions, inspect the operator manifests for suspicious resources, and verify image provenance (e.g., signatures, trusted registries). This due diligence helps detect malicious intent, such as excessive privileges or backdoors, before the operator is deployed.

Answer

Enabling Horizontal Pod Autoscaling for CoreDNS replicas

Answer

Disabling the Kubernetes Dashboard service deployment

Answer

Configuring liveness probes on all worker nodes to check kubelet responsiveness

Question 5

Which TWO of the following principles are core tenets of cloud native security?

Accepted Answer

Shift-left security, integrating security checks early into the development and CI/CD pipeline.. Option A is correct because shift-left security is a foundational cloud native principle: security checks (SAST, SCA, container image scanning, IaC validation) are integrated early into development and the CI/CD pipeline so vulnerabilities are caught before deployment rather than after. Option D is correct because defense-in-depth is a core tenet of cloud native security, layering overlapping controls across the 4Cs (Cloud, Cluster, Container, Code) so that no single control failure compromises the workload. Option B is wrong because hardcoding administrative credentials in source code violates secrets management and least-privilege practices, creating a critical vulnerability rather than a security principle. Option C is wrong because implicit trust between microservices is an anti-pattern; cloud native security requires zero-trust, mutual authentication (e.g., mTLS) and explicit authorization between services. Option E is wrong because perimeter-only defense assumes a hard outer shell with a soft interior, which fails against lateral movement, insider threats, and compromised workloads in dynamic cloud environments.

Answer

Hardcoding administrative credentials directly into source code for operational simplicity.

Answer

Implicit trust of internal microservices communicating within the same cluster network.

Answer

Perimeter-only defense, relying exclusively on an external corporate firewall.

Question 6

An application pod needs to mount a Secret as environment variables. Which section of the Pod manifest should be configured to achieve this securely?

Accepted Answer

Using 'env' with 'valueFrom.secretKeyRef' or 'envFrom' with 'secretRef' in the container specification.. To expose a Secret as environment variables, you reference it in the container's env or envFrom block using valueFrom.secretKeyRef (for a single key) or envFrom.secretRef (for all keys). This is the standard, supported mechanism for injecting Secret data as environment variables in a Pod manifest.

Answer

Using 'volumeMounts' pointing to a PersistentVolumeClaim bound to the Secret.

Answer

Adding the Secret name directly to the container imagePullSecrets field.

Answer

Declaring the Secret in the container securityContext block.

Question 7

An organization requires compliance auditing of etcd access to ensure unauthorized clients cannot communicate with the data store. According to CIS benchmarks, how should etcd client communication be secured?

Accepted Answer

Mutual TLS (mTLS) client certificates. CIS Kubernetes Benchmark requires that etcd client communication be encrypted and mutually authenticated. Mutual TLS (mTLS) ensures both the client and the etcd server present certificates signed by a trusted CA, preventing unauthorized clients from connecting. This is enforced via flags like --cert-file, --key-file, --client-cert-auth, and --trusted-ca-file on the etcd server.

Answer

IPsec tunnel encapsulation

Answer

HTTP with token bearer headers

Answer

Plaintext loopback interface binding

Question 8

Which TWO of the following files or directories on a control plane node contain critical static pod manifests for core components? (Choose TWO)

Accepted Answer

/etc/kubernetes/manifests/etcd.yaml. Option A is correct because /etc/kubernetes/manifests/etcd.yaml is the static pod manifest that the kubelet on a control plane node watches and instantiates to run the etcd datastore as a static pod. Option E is correct because /etc/kubernetes/manifests/kube-apiserver.yaml is likewise a static pod manifest in the kubelet's configured staticPodPath, used to launch the kube-apiserver as a static pod. Option B is incorrect because /var/lib/kubelet/config.yaml is the kubelet's own configuration file (KubeletConfiguration), not a pod manifest. Option C is incorrect because /etc/default/kube-proxy is a service environment/defaults file for kube-proxy, not a static pod manifest. Option D is incorrect because ~/.kube/config is the client kubeconfig file used by kubectl to authenticate to the cluster, not a static pod manifest.

Answer

/var/lib/kubelet/config.yaml

Answer

/etc/default/kube-proxy

Answer

~/.kube/config

Question 9

An administrator needs to configure an Ingress resource to route traffic securely to a backend service using HTTPS (TLS between the ingress controller and the backend pod). Which NGINX Ingress annotation enables this backend HTTPS communication?

Accepted Answer

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS". The annotation nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" tells the NGINX Ingress Controller to speak HTTPS when connecting to the backend service, enabling TLS between the controller and the pod. This is the standard way to terminate TLS at the ingress and re-encrypt to the backend, satisfying end-to-end encryption requirements. Without this annotation, NGINX defaults to HTTP for backend connections even if the Service port is named 'https'.

Answer

nginx.ingress.kubernetes.io/ssl-redirect: "true"

Answer

nginx.ingress.kubernetes.io/proxy-connect-timeout

Answer

nginx.ingress.kubernetes.io/cors-allow-origin

Question 10

A DevOps team is building container images using Dockerfiles. They decide to use official minimal distroless base images instead of standard Ubuntu images containing package managers and shell utilities. Which security benefit does this provide?

Accepted Answer

It reduces the container attack surface by removing unused binaries and shells. Distroless images contain only the application and its runtime dependencies — no package manager, no shell, no standard Linux utilities. Removing these components eliminates entire classes of attack vectors such as shell injection, package-manager abuse, and exploitation of unpatched utilities like bash or curl. This directly reduces the container attack surface, which is exactly what option A states.

Answer

It encrypts the container image layers at rest in the registry

Answer

It automatically configures cloud IAM roles for the container

Answer

It guarantees zero vulnerabilities in application code dependencies

Question 11

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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