CKA Practice Test 9 — 10 Questions

Question 1

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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