CKA Practice Test 18 — 15 Questions

Question 1

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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

Question 15

Which reclaim policy will cause the underlying storage to be deleted when the associated PersistentVolume is released from a PersistentVolumeClaim?

Accepted Answer

Delete. The Delete reclaim policy instructs the system to remove the underlying storage asset (e.g., an AWS EBS volume, GCE Persistent Disk, or NFS export) when the PersistentVolume is released from a PersistentVolumeClaim. This is the only policy that automatically cleans up the physical storage, ensuring no orphaned resources remain.

Answer

Recycle

Answer

Retain

Answer