CKA Practice Test 22 — 15 Questions

Question 1

You create a Deployment with the following YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest
        resources:
          limits:
            cpu: "500m"
            memory: "256Mi"
          requests:
            cpu: "200m"
            memory: "128Mi"

After applying it, the pods are in 'CrashLoopBackOff'. You check logs and see 'Error: container process exited with error'. What is the MOST likely cause?

Accepted Answer

The application is crashing at startup due to a missing dependency. The error message 'container process exited with error' indicates the application itself is failing to start, not that it is being killed by Kubernetes. Since the container exits immediately after starting, the most likely cause is a missing dependency or misconfiguration in the application code, such as a missing environment variable, database connection, or file. Resource limits and probes affect running containers, not initial startup failures.

Answer

The container is being OOMKilled because memory limit is too low

Answer

The readiness probe is failing

Answer

The container has insufficient CPU resources

Question 2

You need to see the startup logs of the kubelet service. Which command should you use?

Accepted Answer

journalctl -u kubelet. `journalctl -u kubelet` retrieves the systemd journal logs for the kubelet service unit. Since kubelet runs as a systemd service on the node, its startup logs (including failures, configuration errors, or TLS bootstrap issues) are captured by journald and can be viewed with this command. This is the standard way to inspect kubelet's early boot-time behavior, which is not accessible via kubectl or systemctl status alone.

Answer

kubectl get events --all-namespaces

Answer

systemctl status kubelet

Answer

kubectl logs kubelet -n kube-system

Question 3

During a cluster upgrade, what is the correct order of operations for upgrading a node?

Accepted Answer

Drain the node, upgrade kubelet and kube-proxy, then uncordon. During a node upgrade, the node must first be drained to safely evict all pods and ensure workloads are rescheduled. Then, the kubelet and kube-proxy (which run as system services) are upgraded to match the control plane version. Finally, the node is uncordoned to make it schedulable again, allowing new pods to be placed on it.

Answer

Upgrade kubelet, drain the node, then uncordon

Answer

Drain the node, uncordon, then upgrade kubelet

Answer

Uncordon the node, drain, then upgrade

Question 4

Which command is used to create a backup of etcd data using etcdctl?

Accepted Answer

etcdctl snapshot save /backup/snapshot.db. `etcdctl snapshot save` is the command used to create a point-in-time backup of etcd data. This command captures the entire key-value store and writes it to a specified file path, which is essential for disaster recovery in Kubernetes clusters that use etcd as their backing store.

Answer

etcdctl endpoint status

Answer

etcdctl snapshot restore /backup/snapshot.db

Answer

etcdctl member list

Question 5

A Pod in a Deployment is CrashLoopBackOff. 'kubectl logs' shows the application exits with code 1 after printing one line. The Pod has a liveness probe that checks an HTTP endpoint. What should be checked first?

Accepted Answer

Check the application logs and configuration that causes the exit code 1.. The application exits with code 1 after printing one line, which indicates a runtime error in the application itself. The liveness probe only restarts the container after the application has already failed; it does not prevent the initial crash. Therefore, the first step is to examine the application logs and configuration to understand why the process exits with code 1, as this is the root cause of the CrashLoopBackOff.

Answer

Check if the liveness probe's initialDelaySeconds is too short.

Answer

Check if the liveness probe endpoint is correctly configured.

Answer

Check if the container has insufficient memory limits.

Question 6

After upgrading the control plane using kubeadm, you need to update the kubelet configuration on the node. Which command should you run on the node?

Accepted Answer

kubeadm upgrade node. `kubeadm upgrade node` is the command used on worker nodes (or secondary control-plane nodes) after the primary control plane has been upgraded. It upgrades the kubelet configuration and other node-specific components to match the new cluster version, ensuring the node can rejoin the upgraded cluster.

Answer

kubeadm upgrade apply

Answer

kubectl upgrade node

Answer

kubeadm upgrade plan

Question 7

You need to renew all certificates on a kubeadm-managed cluster. Which command accomplishes this?

Accepted Answer

kubeadm certs renew all. `kubeadm certs renew all` is the dedicated command to renew all PKI certificates in a kubeadm-managed cluster. It regenerates each certificate using the existing CA key, updating the certificate files in `/etc/kubernetes/pki/` without restarting control plane components; a manual restart or kubelet reload is required afterward.

Answer

kubeadm certs renew apiserver

Answer

kubeadm certs check-expiration

Answer

kubeadm upgrade apply

Question 8

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. What is the most likely cause?

Accepted Answer

The container image name is misspelled. The 'ImagePullBackOff' state indicates that the kubelet on the node is unable to pull the container image from the registry. The most common cause is an incorrect image name or tag, which results in a manifest not found error. This triggers exponential backoff retries by the kubelet, leading to the 'ImagePullBackOff' status.

Answer

The node is out of disk space

Answer

The pod exceeded its memory limit

Answer

The container command is invalid

Question 9

Which annotation is commonly used with the ExternalDNS project to manage DNS records for a Kubernetes service?

Accepted Answer

external-dns.alpha.kubernetes.io/hostname. The ExternalDNS project synchronizes exposed Kubernetes Services and Ingresses with DNS providers. The annotation `external-dns.alpha.kubernetes.io/hostname` is used to explicitly specify the DNS hostname that ExternalDNS should manage for a Service of type LoadBalancer or NodePort, overriding the default naming logic.

Answer

prometheus.io/scrape

Answer

kubernetes.io/ingress.class

Answer

cert-manager.io/cluster-issuer

Question 10

Which DNS record does CoreDNS create for a headless Service named 'headless-svc' in the namespace 'default'?

Accepted Answer

A records for each pod IP backing the Service. CoreDNS creates A records for each pod IP backing a headless Service because headless Services (with clusterIP set to None) are designed to return pod IPs directly via DNS, rather than a single Service IP. For a headless Service named 'headless-svc' in the 'default' namespace, CoreDNS performs a DNS lookup that returns multiple A records, one for each ready pod endpoint, enabling direct pod-to-pod communication without load balancing.

Answer

No DNS record

Answer

A CNAME record pointing to an external DNS

Answer

An A record for the Service IP (ClusterIP)

Question 11

You run 'kubectl get pods' and one pod shows 'ImagePullBackOff'. Which command would help you diagnose the issue?

Accepted Answer

kubectl describe pod . The 'ImagePullBackOff' error indicates that Kubernetes is unable to pull the container image from the registry. 'kubectl describe pod ' provides detailed pod events, including the exact error message from the kubelet (e.g., 'Failed to pull image', 'manifest not found', or 'unauthorized'), which directly reveals the root cause.

Answer

kubectl logs <pod-name>

Answer

kubectl top pod <pod-name>

Answer

kubectl exec -it <pod-name> -- sh

Question 12

A pod named 'web-app' is crashing repeatedly. You run 'kubectl describe pod web-app' and see that the container exited with code 137. What does this indicate?

Accepted Answer

The container was killed because it exceeded its memory limit. Exit code 137 (128 + 9) means the container was killed by SIGKILL (signal 9). In Kubernetes, this typically occurs when the container exceeds its memory limit (specified in `resources.limits.memory`), causing the OOM (Out-Of-Memory) killer to terminate the process. The `kubectl describe pod` output will also show `OOMKilled` in the `State` field under container status.

Answer

The container's entrypoint command failed

Answer

The container's readiness probe failed

Answer

The container image was not found

Question 13

You have a pod that is stuck in 'Pending' state. Running 'kubectl describe pod' shows the event: '0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 node(s) didn't match pod anti-affinity rules.' What is the MOST likely solution?

Accepted Answer

Remove or modify the pod anti-affinity rules. The pod is unschedulable because two nodes are excluded by pod anti-affinity rules, not because of the master taint (only one node has that taint). The most direct solution is to remove or modify the anti-affinity rules so the pod can be scheduled on those two nodes. Adding a toleration would only address the single master node, leaving the anti-affinity issue unresolved.

Answer

Cordon the master node to remove it from scheduling

Answer

Add a toleration for the master taint to the pod spec

Answer

Delete and recreate the pod

Question 14

A cluster administrator wants to provide storage for an application that requires reading and writing by multiple pods simultaneously. The storage backend is an NFS server that supports multiple writers. Which access mode should be specified in the PersistentVolume?

Accepted Answer

ReadWriteMany. The correct access mode is ReadWriteMany (RWX) because the application requires multiple pods to read and write simultaneously, and the NFS server supports multiple writers. RWX allows the PersistentVolume to be mounted as read-write by many nodes, which is the only access mode that satisfies the requirement for concurrent read-write access from multiple pods.

Answer

ReadOnlyMany

Answer

ReadWriteOnce

Answer

ReadWriteOncePod

Question 15

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