CKA Practice Test 4 — 25 Questions

Question 1

An administrator runs 'kubectl run test-pod --image=nginx' and the pod is created but stays in 'Pending' state. Which command would BEST help diagnose why the pod is not running?

Accepted Answer

kubectl describe pod test-pod. `kubectl describe pod test-pod` provides a detailed summary of the pod's current state, including events, conditions, and status messages that reveal why the pod is stuck in 'Pending'. The 'Pending' state typically indicates that the pod has not been scheduled to a node, often due to resource constraints (CPU/memory), persistent volume claims not being bound, or node selector mismatches. The 'Conditions' and 'Events' sections in the output directly expose these issues, making it the most effective diagnostic command.

Answer

kubectl logs test-pod

Answer

kubectl exec -it test-pod -- /bin/bash

Answer

kubectl get events

Question 2

A DevOps team needs to deploy a stateful application that requires persistent storage with ReadWriteMany access mode across multiple pods running on different nodes. Which Kubernetes resource should they use to provision the storage?

Accepted Answer

A PersistentVolume with access mode ReadWriteMany. ReadWriteMany (RWX) is the only access mode that allows multiple pods across different nodes to simultaneously read and write to the same persistent storage volume. A PersistentVolume with access mode ReadWriteMany meets the requirement for a stateful application needing concurrent access from pods running on different nodes, typically backed by network filesystems like NFS, GlusterFS, or CephFS.

Answer

A hostPath volume

Answer

A PersistentVolume with access mode ReadWriteOnce

Answer

An emptyDir volume

Question 3

You are a platform engineer managing a Kubernetes cluster with 5 worker nodes (node1-node5). The cluster runs a mix of stateless web services and stateful databases. Users report that a critical database Pod (part of a StatefulSet) is frequently evicted during node maintenance. The StatefulSet has a single replica. You need to improve the availability of this database Pod. The current configuration: the Pod has resource requests (2 CPU, 4Gi memory) and limits (4 CPU, 8Gi memory). The cluster uses the default scheduler with no custom policies. Nodes have varying capacities: node1 and node2 have 8 CPU/32Gi memory, node3-node5 have 4 CPU/16Gi memory. During rolling node reboots, the database Pod gets evicted and takes a long time to reschedule because no node has enough resources. What should you do to minimize downtime and ensure the Pod is rescheduled promptly after eviction?

Accepted Answer

Assign a high priority class to the database Pod.. Assigning a high priority class (Option C) ensures that when the database Pod is evicted during node maintenance, the scheduler treats it as a higher-priority workload than other Pods. This allows it to preempt lower-priority Pods on nodes with sufficient capacity (e.g., node1 or node2), even if those nodes appear fully allocated, thereby minimizing downtime and ensuring prompt rescheduling.

Answer

Add nodeAffinity to prefer node1 and node2.

Answer

Create a PodDisruptionBudget with minAvailable: 1.

Answer

Increase the resource requests to match the limits.

Question 4

You have a ResourceQuota in a namespace that sets limits: pods: 10, requests.cpu: 4, requests.memory: 8Gi. You try to create a Pod with requests.cpu: 1, requests.memory: 2Gi, and no limits. The namespace currently has 8 pods using 3 CPUs and 5Gi memory in total requests. What happens?

Accepted Answer

The pod is created successfully.. The ResourceQuota only enforces the total sum of requests across all pods in the namespace. Currently, the namespace has 8 pods using 3 CPUs and 5Gi memory. Adding a pod with requests.cpu: 1 and requests.memory: 2Gi would bring totals to 4 CPUs (3+1) and 7Gi memory (5+2), both within the quota limits of 4 CPUs and 8Gi. The pod does not specify limits, but ResourceQuota does not require limits unless a LimitRange enforces default limits; here, no LimitRange is mentioned, so the pod is allowed.

Answer

The pod is rejected because it exceeds the memory request quota.

Answer

The pod is rejected because it exceeds the CPU request quota.

Answer

The pod is rejected because it does not specify CPU and memory limits.

Question 5

You run 'kubectl get nodes' and see that a node is 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. The output shows 'Active: inactive (dead)'. What is the most likely cause?

Accepted Answer

The kubelet service is stopped. The kubelet is the primary node agent that runs on every node and is responsible for maintaining pod lifecycles. When 'systemctl status kubelet' shows 'Active: inactive (dead)', it means the kubelet systemd service is not running. Since the kubelet must be active for the node to report its status to the control plane, a stopped kubelet directly causes the node to be 'NotReady'.

Answer

The network plugin is misconfigured

Answer

The node has been cordoned

Answer

The container runtime is not installed

Question 6

You run: kubectl expose deployment web --port=80 --target-port=8080 --type=LoadBalancer --name=web-svc. What is the effect of this command?

Accepted Answer

Creates a Service that selects pods with label 'app=web' and maps port 80 to 8080. The `kubectl expose deployment web --port=80 --target-port=8080 --type=LoadBalancer --name=web-svc` command creates a Service named 'web-svc' that automatically inherits the label selector from the 'web' deployment (typically `app=web`). It maps the Service's port 80 to the pods' container port 8080, and the `--type=LoadBalancer` sets the Service type to LoadBalancer, which provisions an external load balancer (if supported by the cluster) and also creates a NodePort and ClusterIP automatically.

Answer

Creates a Service of type ClusterIP which is later changed to LoadBalancer

Answer

Creates a Service that selects all pods in the namespace regardless of labels

Answer

Creates a Service that exposes port 8080 on the node

Question 7

Which command creates a ConfigMap named 'app-config' from the file 'config.properties'?

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. `kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the content of the file 'config.properties'. The `--from-file` flag reads the file and stores its entire content as a single key-value pair, where the key defaults to the filename (config.properties) and the value is the file's content. This is the standard syntax for creating a ConfigMap from a file in Kubernetes.

Answer

kubectl create configmap app-config --file=config.properties

Answer

kubectl create configmap app-config --from-env-file=config.properties

Answer

kubectl create configmap app-config --from-literal=config.properties

Question 8

You run 'kubectl get nodes' and see that one node is marked as 'NotReady'. Which component is likely failing on that node?

Accepted Answer

kubelet. The kubelet is the primary node agent that runs on every node and is responsible for registering the node with the cluster and reporting its status via periodic heartbeats (NodeStatus updates). When a node is marked as 'NotReady', it means the kubelet has failed to send these heartbeats to the control plane (specifically, the node controller) within the --node-monitor-grace-period (default 40s), indicating the kubelet process is likely down, unresponsive, or misconfigured.

Answer

kube-proxy

Answer

kube-scheduler

Answer

container runtime (e.g., containerd)

Question 9

Which control plane component is responsible for storing the cluster state and configuration?

Accepted Answer

etcd. etcd is the distributed key-value store that serves as the single source of truth for the entire cluster, storing all cluster state data such as configurations, secrets, service endpoints, and resource specifications. The kube-apiserver reads from and writes to etcd exclusively, making it the only component that directly persists the cluster's desired and current state.

Answer

kube-controller-manager

Answer

kube-apiserver

Answer

kube-scheduler

Question 10

You are debugging a DNS issue from within a pod. The pod is running 'busybox'. Which command would you use to test DNS resolution for 'kubernetes.default.svc.cluster.local'?

Accepted Answer

kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local. `kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local` runs the `nslookup` command directly inside the running pod, which uses the pod's configured DNS resolver (typically CoreDNS) to resolve the Kubernetes service FQDN. This is the standard method to test DNS resolution from within a pod, as it bypasses any external DNS and validates the cluster's internal DNS chain.

Answer

kubectl describe svc kubernetes -n default

Answer

kubectl exec -it my-pod -- curl kubernetes.default.svc.cluster.local

Answer

kubectl run test --image=busybox -- nslookup kubernetes.default.svc.cluster.local

Question 11

A Pod is stuck in 'Pending' state. You run 'kubectl describe pod my-pod' and see the event: '0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 Insufficient cpu.' The pod has resource requests: cpu: 2, memory: 1Gi. The cluster has 3 nodes: one control-plane with taint node-role.kubernetes.io/master:NoSchedule, and two worker nodes each with 1 CPU. What is the most likely cause?

Accepted Answer

The pod requests more CPU than any available node can provide.. The pod requests 2 CPU, but each worker node has only 1 CPU, making them insufficient. The control-plane node has the taint `node-role.kubernetes.io/master:NoSchedule` which the pod does not tolerate, so it is also unavailable. The event explicitly states '2 Insufficient cpu', confirming that the CPU request cannot be satisfied by any node.

Answer

The pod requests more memory than any available node can provide.

Answer

The pod has a higher priority than other pods and is preempting them.

Answer

The control-plane node has insufficient resources.

Question 12

A user reports that they cannot access a Service of type ClusterIP from within the cluster. The Service selects pods that are running and responding. Which of the following is the MOST likely cause?

Accepted Answer

The Service's targetPort does not match the container's containerPort. The Service's `targetPort` must match the `containerPort` defined in the pod's container spec. Even if the pods are running and responding, if the `targetPort` points to a different port than the one the container is listening on, traffic will be forwarded to the wrong port and the connection will fail. The `port` field on the Service is the port the Service itself listens on, while `targetPort` is the port on the pod where traffic is actually sent.

Answer

The Service's port does not match the container's containerPort

Answer

The Service type is NodePort instead of ClusterIP

Answer

The Service selector does not match any pod labels

Question 13

You run 'kubectl get nodes' and see that one node is in the 'NotReady' state. Which command would you use FIRST to investigate the kubelet status on that node?

Accepted Answer

systemctl status kubelet. The kubelet is the primary node agent that registers the node with the cluster and reports its status via periodic heartbeats. When a node is NotReady, the first step is to check if the kubelet service is running on that node using `systemctl status kubelet` (or `journalctl -u kubelet`), because a stopped or unhealthy kubelet will directly cause the node to lose connectivity with the control plane. This command is the most direct way to verify the kubelet's process state and recent logs on the node itself.

Answer

ssh to the node and run 'docker ps'

Answer

kubectl describe node <node-name>

Answer

kubectl logs kubelet -n kube-system

Question 14

A pod with an init container that runs a database migration fails. The init container exits with code 1. What is the pod's status?

Accepted Answer

Init:CrashLoopBackOff. When an init container exits with a non-zero exit code (code 1), Kubernetes considers the init container to have failed. By default, the pod restarts the init container according to the pod's restart policy (which defaults to Always for pods, but init containers always restart on failure regardless of the pod's restart policy). This repeated failure and restart cycle places the pod in the Init:CrashLoopBackOff status, indicating that the init container is crashing in a loop.

Answer

Pending

Answer

Failed

Answer

Running

Question 15

An administrator runs 'kubectl get nodes' and sees that one node is in the 'NotReady' state. Which component should be checked FIRST to diagnose the issue?

Accepted Answer

kubelet on the worker node. The kubelet is the primary node agent that runs on every worker node and is responsible for registering the node with the cluster and periodically reporting its status via NodeStatus updates. When a node is in 'NotReady' state, it means the kubelet has failed to send heartbeats or report readiness to the control plane, typically due to a crash, misconfiguration, or resource exhaustion. Checking the kubelet's logs and service status (e.g., 'systemctl status kubelet' or 'journalctl -u kubelet') is the first diagnostic step because it directly controls node health reporting.

Answer

kube-apiserver on the control plane

Answer

kube-controller-manager

Answer

etcd cluster health

Question 16

Which access mode allows multiple pods on different nodes to mount a PersistentVolume as read-write?

Accepted Answer

ReadWriteMany (RWX). ReadWriteMany (RWX) is the only access mode that allows multiple pods across different nodes to mount a PersistentVolume as read-write simultaneously. This is achieved through shared filesystem protocols such as NFS, GlusterFS, or CephFS, which support concurrent access from multiple clients. The RWX mode is essential for workloads like clustered databases or shared storage applications where multiple instances need to write to the same volume.

Answer

ReadWriteOncePod (RWOP)

Answer

ReadWriteOnce (RWO)

Answer

ReadOnlyMany (ROX)

Question 17

You are troubleshooting a DNS issue. From within a pod, you run 'nslookup kubernetes.default.svc.cluster.local' and get 'connection timed out; no servers could be reached'. What is the most likely cause?

Accepted Answer

The kube-dns service is not running or is misconfigured. The error 'connection timed out; no servers could be reached' from nslookup indicates that the DNS resolver (typically the kube-dns or CoreDNS service) is unreachable. Since the query targets the standard Kubernetes service name 'kubernetes.default.svc.cluster.local', the most likely cause is that the kube-dns service (or its backend pods) is not running or is misconfigured, preventing the pod from resolving cluster-internal DNS names.

Answer

The pod's /etc/resolv.conf has incorrect nameservers

Answer

The node's network plugin is misconfigured

Answer

The pod's DNS policy is set to 'None'

Question 18

You update a NetworkPolicy to add an egress rule. After applying, pods affected by the policy can no longer reach external IPs. What is the most likely reason?

Accepted Answer

NetworkPolicy egress rules deny all traffic by default unless explicitly allowed. NetworkPolicy in Kubernetes follows a default-deny model for traffic. When any egress rule is added to a NetworkPolicy, it implicitly denies all egress traffic that is not explicitly allowed by that rule. Therefore, if the egress rule does not include a rule allowing traffic to external IPs (e.g., via an IPBlock or a namespace selector), those destinations become unreachable. This is by design, as NetworkPolicies are additive whitelists.

Answer

The egress rule has a typo in the IP block

Answer

The pods are not running

Answer

The CNI plugin does not support egress rules

Question 19

You create a ConfigMap named 'app-config' with key 'database.url'. Which command correctly creates a pod that injects this ConfigMap value as an environment variable named 'DB_URL'?

Accepted Answer

Create a pod YAML with env.valueFrom.configMapKeyRef. To inject a specific key from a ConfigMap as a pod environment variable with a custom name, you must use a pod YAML with `env.valueFrom.configMapKeyRef`. This allows you to reference the ConfigMap key `database.url` and map it to the environment variable `DB_URL`. The `kubectl run` command does not support directly mapping a ConfigMap key to a custom environment variable name in a single command.

Answer

kubectl run my-pod --image=nginx --envFrom=configmap/app-config

Answer

kubectl run my-pod --image=nginx --env="DB_URL=configmap:app-config:database.url"

Answer

kubectl run my-pod --image=nginx --from-configmap=app-config

Question 20

You are performing a backup of etcd using the command: 'ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db'. You get an error: 'Error: context deadline exceeded'. What is the most likely cause?

Accepted Answer

The endpoint flag is missing or incorrect, causing the client to timeout trying to connect. The error 'context deadline exceeded' indicates that the etcdctl client attempted to connect to the etcd endpoint but the request timed out before a connection could be established. This is most commonly caused by the --endpoints flag being omitted or pointing to an incorrect address (e.g., localhost:2379 instead of the actual etcd listener), so the client cannot reach the etcd server within the default timeout period.

Answer

The etcdctl version is incompatible with etcd

Answer

The etcd cluster is not running

Answer

The snapshot file already exists and is locked