CKA Multiple Select — 50 Questions

Question 1

Which three are possible reasons for a pod being in Pending state? (Choose three.)

Accepted Answer

PersistentVolumeClaim not bound. Pending means the pod hasn't been scheduled. Reasons include insufficient resources, persistent volume claim not bound, and taints/tolerations mismatch. Image pull issues cause ImagePullBackOff, not Pending.

Answer

Liveness probe failing

Answer

Container image does not exist

Question 2

Which THREE of the following are valid commands to troubleshoot network connectivity between pods? (Select 3)

Accepted Answer

kubectl exec pod-a -- nslookup service-name. kubectl exec can run networking tools inside a pod. curl is a common tool. nslookup tests DNS. ping tests basic connectivity.

Answer

kubectl describe node | grep Network

Answer

kubectl logs pod-a | grep network

Question 3

Which of the following are valid methods to debug a failing CoreDNS pod? (Select TWO)

Accepted Answer

kubectl logs -n kube-system -l k8s-app=kube-dns. `kubectl logs -n kube-system -l k8s-app=kube-dns` retrieves the logs from all CoreDNS pods (which are labeled `k8s-app=kube-dns` in the `kube-system` namespace). This is a direct method to inspect errors, crashes, or misconfigurations in the DNS service. Option C is correct because `kubectl get endpoints -n kube-system kube-dns` shows the IP addresses of the pods backing the `kube-dns` service; if the endpoint list is empty, it indicates that no CoreDNS pods are ready to serve DNS requests, which is a common failure point.

Answer

kubectl delete pod -n kube-system -l k8s-app=kube-dns

Answer

kubectl scale deployment coredns --replicas=2

Answer

kubectl run -it --rm test --image=busybox -- nslookup kubernetes.default

Question 4

Which TWO of the following are valid reasons to use a Headless Service?

Accepted Answer

To enable a client to discover all pod IPs for a StatefulSet.. A Headless Service (with `clusterIP: None`) does not provide a single stable IP or load balancing. Instead, it returns DNS A/AAAA records for all pod IPs that match the service's selector. This is essential for StatefulSets, where each pod has a unique identity and clients need to discover and connect to specific pods directly, such as in a database cluster.

Answer

To provide a single stable IP address for the service.

Answer

To expose a service externally via a cloud load balancer.

Answer

To provide load-balanced access to a set of pods.

Question 5

Which TWO actions can help troubleshoot a service that is not reachable from within a pod?

Accepted Answer

Use kubectl exec to curl the service IP from a pod. Checking endpoints and using curl from a pod are direct troubleshooting steps.

Answer

Use kubectl delete svc and recreate

Answer

Use kubectl logs on the service pod to see application logs

Answer

Use kubectl top nodes to check resource usage

Question 6

A node is NotReady. Which THREE conditions could cause this?

Accepted Answer

Network plugin (e.g., Calico) is not functioning. Kubelet stopped, network plugin issues, and disk pressure can all cause a node to become NotReady.

Answer

A pod is in CrashLoopBackOff

Answer

The API server is overloaded

Question 7

Which TWO commands show cluster events that can help in troubleshooting?

Accepted Answer

kubectl describe pod . Option E, `kubectl get events`, is correct because it directly lists the cluster's event stream (backed by the Events API), showing scheduling failures, image pull errors, probe failures, and other warnings tied to specific resources. Option D, `kubectl describe pod `, is correct because its output includes an Events section at the bottom that surfaces the same per-pod events with timestamps, reasons, and messages, which is essential for troubleshooting a specific pod. Option A, `kubectl cluster-info`, only prints the addresses of the control plane and core add-ons, providing no event data. Option B, `kubectl logs `, shows application/container stdout and stderr, not Kubernetes cluster events. Option C, `kubectl top pods`, reports CPU and memory usage metrics from the metrics server, which is resource data rather than events.

Answer

kubectl cluster-info

Answer

kubectl logs <pod-name>

Answer

kubectl top pods

Question 8

Which TWO of the following are correct methods to check the health of the kube-apiserver?

Accepted Answer

Run 'kubectl get pods -n kube-system -l component=kube-apiserver'. Option C is correct because kube-apiserver typically runs as a static pod in the kube-system namespace, so 'kubectl get pods -n kube-system -l component=kube-apiserver' lets you verify the pod's status, readiness, and restart count. Option E is correct because the kube-apiserver exposes a /healthz endpoint on its secure port (6443 by default), and 'curl -k https://localhost:6443/healthz' returns 'ok' when the API server is healthy. Option A is wrong because 'kubectl top nodes' reports CPU and memory usage from metrics-server, not API server health. Option B is wrong because kube-apiserver is usually a static pod managed by the kubelet, not a systemd unit, so 'systemctl status kube-apiserver' would typically fail. Option D is wrong because 'journalctl -u kubelet' shows kubelet logs, which may reveal pod issues but does not directly check the kube-apiserver's health.

Answer

Run 'kubectl top nodes'

Answer

Run 'systemctl status kube-apiserver'

Answer

Run 'journalctl -u kubelet'

Question 9

Which THREE components must be present in a high-availability control plane setup?

Accepted Answer

kube-controller-manager. In a highly available Kubernetes control plane, the three essential components are the kube-controller-manager (C), etcd (D), and kube-apiserver (E). The kube-apiserver (E) is the central management endpoint that all clients and internal components communicate with, and it must be replicated behind a load balancer for HA. etcd (D) is the distributed key-value store that holds all cluster state; running it as an odd-numbered quorum across multiple nodes provides fault tolerance. The kube-controller-manager (C) runs the control loops that reconcile cluster state, and in HA it is typically deployed on multiple control-plane nodes with leader election so one active instance drives reconciliation. kubelet (A) and kube-proxy (B) are node-level components that run on every worker node, not control-plane HA components, so they are not required for a high-availability control plane setup.

Answer

kubelet

Answer

kube-proxy

Question 10

Which THREE of the following are CNI plugins?

Accepted Answer

Flannel. Flannel is a CNI plugin that provides a simple overlay network for Kubernetes clusters, typically using VXLAN or host-gw to encapsulate and route pod traffic across nodes. It implements the Container Network Interface (CNI) specification by installing a binary and configuration file on each node, enabling pod-to-pod communication without requiring a separate network daemon.

Answer

kube-proxy

Answer

CoreDNS

Question 11

You are applying the following RBAC manifest:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Which TWO statements are true about this Role? (Choose TWO.)

Accepted Answer

It allows reading pod details in the 'development' namespace. The Role explicitly defines rules for the 'pods' resource with verbs 'get', 'watch', and 'list' in the 'development' namespace. These verbs allow reading pod details such as their specifications, status, and metadata. The Role is scoped to the 'development' namespace, so it only grants these read permissions within that namespace.

Answer

It also grants access to secrets in the 'development' namespace

Answer

It grants permissions across all namespaces

Answer

It allows creating pods in the 'development' namespace

Question 12

You are troubleshooting a node that is 'NotReady'. Which THREE of the following are possible causes? (Choose three.)

Accepted Answer

The kubelet cannot contact the API server. The kubelet is the primary node agent that communicates with the API server to report node status, heartbeats, and pod lifecycle events. If the kubelet cannot reach the API server (e.g., due to network partition, TLS certificate issues, or API server downtime), it cannot send the periodic NodeStatus updates, and the control plane marks the node as 'NotReady' after the `node-monitor-grace-period` (default 40 seconds) expires.

Answer

The node has disk pressure

Answer

A pod on the node is consuming excessive memory

Question 13

You have a pod that is in CrashLoopBackOff. Which two troubleshooting steps should you take first? (Choose two.)

Accepted Answer

kubectl describe pod pod-name. `kubectl describe pod pod-name` provides detailed information about the pod's current state, including recent events, container restart counts, and the reason for the CrashLoopBackOff (e.g., exit code 137 from OOMKill or 1 from application error). This is the first step to understand the root cause of the crash loop.

Answer

kubectl delete pod pod-name

Answer

kubectl exec -it pod-name -- sh

Answer

kubectl rollout restart deployment

Question 14

Which TWO of the following are valid commands to view cluster events sorted by timestamp?

Accepted Answer

kubectl get events. Options A and B are correct. 'kubectl get events' shows events sorted by last timestamp by default, which satisfies the requirement. 'kubectl get events --sort-by=.metadata.creationTimestamp' explicitly sorts by creation timestamp, also valid. Option C uses -w to watch, not sort. Option D sorts by name, not timestamp. Option E shows events from all namespaces but does not sort by timestamp.

Answer

kubectl get events -w

Answer

kubectl get events --sort-by=.metadata.name

Answer

kubectl get events --all-namespaces

Question 15

You are troubleshooting a node that shows 'NotReady' status. Which TWO commands can help you investigate the kubelet state?

Accepted Answer

journalctl -u kubelet. journalctl -u kubelet (C) retrieves kubelet logs from the systemd journal, showing errors and warnings. systemctl status kubelet (D) displays the current status of the kubelet service, including whether it is running, enabled, and recent log entries. The other options: 'kubectl get nodes' (A) shows node status but not kubelet details; 'journalctl -u docker' (B) shows container runtime logs, not kubelet; 'kubectl describe pod' (E) is for pod details, not node-level kubelet troubleshooting.

Answer

kubectl get nodes

Answer

journalctl -u docker

Answer

kubectl describe pod

Question 16

You are troubleshooting a scenario where a pod cannot communicate with another pod in the same namespace via service name. Which THREE steps would you take to diagnose the issue? (Select 3)

Accepted Answer

Run 'kubectl get endpoints' to verify the service has healthy endpoints. Options B, C, and E are correct. Checking endpoints (B) verifies the service has healthy pods. Exec into the pod and using curl (C) tests connectivity to the service's cluster IP. Exec into the pod and running nslookup (E) checks DNS resolution of the service name. Option A checks node status, which is not directly related to pod-to-pod communication via service name. Option D checks logs of the target pod, which may not reveal network issues.

Answer

Run 'kubectl get nodes' to check node status

Answer

Run 'kubectl logs' on the target pod to check application logs

Question 17

Which TWO commands can be used to test DNS resolution for a Service named 'my-svc' in namespace 'default' from within a temporary pod? (Choose 2)

Accepted Answer

kubectl run test --image=busybox --rm -it --restart=Never -- nslookup my-svc. Option B is correct because nslookup is a DNS query tool included in busybox that resolves the Service name 'my-svc' to its ClusterIP by querying the cluster DNS (CoreDNS), directly testing DNS resolution from inside a temporary busybox pod. Option E is incorrect because the standard busybox image does not include dig; the command would fail with 'dig: not found'. To use dig, you must use an image that contains it, such as gcr.io/kubernetes-e2e-test-images/dnsutils:1.3. Options A and D are incorrect because wget and curl are HTTP clients that test connectivity to a web endpoint, not DNS resolution itself, and they would fail if the Service has no HTTP listener. Option C is incorrect because ping tests ICMP reachability, not DNS resolution, and many Service ClusterIPs do not respond to ICMP even when DNS works.

Answer

kubectl run test --image=busybox --rm -it --restart=Never -- wget my-svc

Answer

kubectl run test --image=busybox --rm -it --restart=Never -- ping my-svc

Answer

kubectl run test --image=busybox --rm -it --restart=Never -- curl my-svc

Answer

kubectl run test --image=busybox --rm -it --restart=Never -- dig my-svc

Question 18

An administrator needs to expand an existing PersistentVolumeClaim. Which TWO conditions must be met?

Accepted Answer

The StorageClass used by the PVC must have 'allowVolumeExpansion: true'.. The StorageClass must have `allowVolumeExpansion: true` to permit resizing of a PersistentVolumeClaim. This field is a prerequisite in the StorageClass definition; without it, the PVC cannot be expanded even if the underlying volume supports resizing. The CKA exam expects you to know that volume expansion is gated by this StorageClass setting.

Answer

The PVC must be currently mounted by at least one pod.

Answer

The underlying PersistentVolume must be deleted first.

Answer

The PersistentVolume's reclaim policy must be Recycle.

Question 19

Which TWO statements about Ingress in Kubernetes are correct?

Accepted Answer

Ingress can terminate TLS connections for backend Services.. Option B is correct because an Ingress resource can reference a TLS Secret via spec.tls, allowing the Ingress controller to terminate TLS connections and forward decrypted HTTP traffic to the backend Services. Option E is correct because Ingress rules use the host field to match the HTTP Host header and route requests to different backend Services accordingly. Option A is wrong because spec.ingressClassName selects which Ingress controller should handle the resource; it does not disable the default controller. Option C is wrong because gRPC support is not native to Ingress and typically requires controller-specific annotations or a Gateway API/HTTPRoute setup. Option D is wrong because Ingress operates at Layer 7 (HTTP/HTTPS), while Layer 4 TCP/UDP load balancing requires a Service of type LoadBalancer or a Gateway API TCPRoute.

Answer

Setting spec.ingressClassName to 'nginx' disables the default Ingress controller.

Answer

Ingress natively supports gRPC services without any additional configuration.

Answer

Ingress can provide Layer 4 (TCP/UDP) load balancing.

Question 20

Which TWO of the following are valid ways to expose a Service externally in a Kubernetes cluster running on-premises (no cloud provider)?

Accepted Answer

NodePort. NodePort (B) is correct because it exposes a Service on each node's IP at a static port in the 30000-32767 range, which works on any on-premises cluster without a cloud provider's load-balancer integration. Ingress (C) is correct because an Ingress resource plus an Ingress controller (e.g., NGINX, Traefik) provides HTTP/HTTPS routing from outside the cluster to internal Services, and it functions on-premises as long as the controller is deployed and reachable. LoadBalancer (A) is not valid here because it relies on a cloud provider's load-balancer implementation (or a bare-metal solution like MetalLB) to allocate an external IP, which is absent in a plain on-premises cluster. ClusterIP (D) only provides an internal virtual IP reachable within the cluster, so it does not expose the Service externally. ExternalName (E) merely returns a CNAME DNS record pointing to an external hostname and does not expose a Service running in the cluster.

Answer

LoadBalancer

Answer

ClusterIP

Answer

ExternalName