CKA Practice Test 14 — 15 Questions

Question 1

You need to test DNS resolution from within a pod. Which command should you run?

Accepted Answer

kubectl exec -- nslookup . `kubectl exec -- nslookup ` runs the `nslookup` command directly inside an existing pod, which tests DNS resolution from within the pod's network namespace. This is the most direct way to verify that the pod's DNS resolver (typically CoreDNS or kube-dns) can resolve a Kubernetes service name to a cluster IP, as it uses the pod's `/etc/resolv.conf` and the cluster DNS service.

Answer

kubectl describe svc <service-name>

Answer

kubectl logs <pod> | grep dns

Answer

kubectl run nslookup --image=busybox -- nslookup <service-name>

Question 2

You have a Deployment with 3 replicas. After updating the container image, the new pods are in 'ImagePullBackOff' state. You run 'kubectl describe pod <pod-name>' and see the event: 'Failed to pull image "myregistry/myapp:latest": rpc error: code = Unknown desc = Error response from daemon: manifest for myregistry/myapp:latest not found: manifest unknown: manifest unknown'. What is the MOST likely cause?

Accepted Answer

The image tag 'latest' does not exist in the registry. The error message 'manifest unknown' indicates that the registry successfully reached but the specific image tag 'latest' does not exist in the repository. This is a registry-side error, not a network or authentication issue. The container runtime can communicate with the registry but cannot find the manifest for the requested tag.

Answer

The registry is unreachable from the nodes

Answer

The registry requires authentication and the pod does not have an imagePullSecret

Answer

The container runtime is out of disk space

Question 3

You have a pod that is in 'Pending' state. Which command would you use to view detailed information about the pod's status, including events that may indicate why it is not running?

Accepted Answer

kubectl describe pod. C is correct because `kubectl describe pod` provides detailed information about the pod's current state, including status conditions, container statuses, and a chronological list of events associated with the pod. These events often contain error messages (e.g., 'FailedScheduling', 'ImagePullBackOff', 'CrashLoopBackOff') that directly explain why the pod is stuck in 'Pending' state, such as insufficient resources or persistent volume claim issues.

Answer

kubectl get endpoints

Answer

kubectl logs pod

Answer

kubectl get pod

Question 4

You deploy a pod with the following YAML:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

The pod starts, but after a few minutes it is killed with OOMKilled. What is the MOST likely reason?

Accepted Answer

The container's memory usage exceeds the configured limit. OOMKilled occurs when a container exceeds its memory limit. In this YAML, the memory limit is set to 128Mi. If the nginx container's memory usage surpasses 128Mi, the Linux kernel's Out-Of-Memory (OOM) killer terminates the container process, resulting in an OOMKilled status. This is a direct enforcement of the resource limit configured in the pod spec.

Answer

The memory limit is lower than the memory request

Answer

The node has swap enabled

Answer

The container is using too much CPU

Question 5

You run 'kubectl get pods' and see a pod in 'CrashLoopBackOff'. You want to see the logs of the last crashed instance. Which command should you run?

Accepted Answer

kubectl logs pod-name --previous. The `--previous` flag (or its shorthand `-p`) tells `kubectl logs` to retrieve logs from the previous instance of a container that has crashed and restarted. Since the pod is in `CrashLoopBackOff`, the current container has already exited, and you need to inspect the logs of the last terminated container to diagnose the crash. To avoid having two correct answers, Option C has been changed to an invalid flag.

Answer

kubectl logs pod-name --all-containers

Answer

kubectl logs pod-name --last

Answer

kubectl logs pod-name

Question 6

A node in your cluster is reporting a DiskPressure condition. Which kubectl command would you use to get details about the node's condition?

Accepted Answer

kubectl describe node . The `kubectl describe node ` command provides detailed information about a node, including its status, capacity, allocatable resources, and a list of conditions (e.g., DiskPressure, MemoryPressure, PIDPressure, Ready). This is the standard way to inspect the exact reason and timestamps for a DiskPressure condition, as well as related metrics like disk usage and inode consumption.

Answer

kubectl get nodes

Answer

kubectl logs <node-name>

Answer

kubectl get events --field-selector involvedObject.kind=Node

Question 7

A pod in namespace 'ns1' cannot resolve the DNS name 'svc.ns2.svc.cluster.local'. What is the most likely cause?

Accepted Answer

The service 'svc' does not exist in namespace 'ns2'.. In Kubernetes, CoreDNS dynamically creates DNS records for Services using the format '..svc.'. If a pod attempts to resolve the fully qualified domain name (FQDN) 'svc.ns2.svc.cluster.local' and fails, the most likely cause is that the Service named 'svc' does not exist in the namespace 'ns2', meaning no DNS record exists for it.

Answer

The pod's DNS policy is set to None.

Answer

The pod is trying to resolve using only the short service name 'svc' without the namespace.

Answer

The pod's DNS policy is set to Default.

Question 8

What is the DNS name for a Service named 'api' in the 'default' namespace?

Accepted Answer

api.default.svc.cluster.local. The correct DNS name for a Service in Kubernetes follows the pattern `..svc.cluster.local`. For a Service named 'api' in the 'default' namespace, this resolves to `api.default.svc.cluster.local`. The `svc` subdomain is a fixed part of the cluster domain, and `cluster.local` is the default cluster domain suffix configured in kubelet and CoreDNS.

Answer

default.api.svc.cluster.local

Answer

api.svc.default.cluster.local

Answer

api.default.cluster.local

Question 9

Which command is used to take a snapshot of etcd using etcdctl?

Accepted Answer

etcdctl snapshot save. `etcdctl snapshot save` is the official command to create a point-in-time snapshot of an etcd datastore, which is essential for backup and disaster recovery in Kubernetes clusters. This command writes the snapshot to a specified file path, preserving all keys and metadata for later restoration via `etcdctl snapshot restore`.

Answer

etcdctl dump

Answer

etcdctl snapshot create

Answer

etcdctl backup

Question 10

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 11

A pod is running with the default DNS policy. The cluster DNS service is at 10.96.0.10. The node's /etc/resolv.conf has nameserver 8.8.8.8. When the pod tries to resolve an external hostname like 'example.com', which DNS server will it query first?

Accepted Answer

The cluster DNS service (10.96.0.10). With the default DNS policy (ClusterFirst), pods are configured to use the cluster DNS service (10.96.0.10) as the first nameserver in their /etc/resolv.conf. This is achieved by kubelet injecting the cluster DNS IP and a search domain into the pod's resolv.conf. Therefore, the pod will query the cluster DNS service first for any hostname resolution, including external names like 'example.com'.

Answer

The node's DNS server (8.8.8.8)

Answer

There is no DNS resolution; the pod cannot resolve external names by default

Answer

The pod's own /etc/resolv.conf which contains the node's DNS

Question 12

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 13

A node named 'worker-1' is unhealthy. You want to mark it as unschedulable and move workloads to other nodes. Which command sequence is correct?

Accepted Answer

kubectl cordon worker-1; kubectl drain worker-1. `kubectl cordon worker-1` marks the node as unschedulable, preventing new pods from being scheduled onto it, and `kubectl drain worker-1` safely evicts all existing pods from the node, respecting PodDisruptionBudgets and terminating pods gracefully. This sequence ensures workloads are moved to other nodes without disrupting running services.

Answer

kubectl uncordon worker-1; kubectl drain worker-1

Answer

kubectl delete node worker-1; kubectl cordon worker-1

Answer

kubectl drain worker-1; kubectl cordon worker-1

Question 14

A pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules'. What is the most likely cause?

Accepted Answer

The pod has a requiredDuringSchedulingIgnoredDuringExecution anti-affinity rule that is too restrictive. The event '0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules' directly indicates that the pod's scheduling is being blocked by anti-affinity constraints. Option B is correct because a `requiredDuringSchedulingIgnoredDuringExecution` anti-affinity rule is a hard constraint that must be satisfied at scheduling time; if no node meets the rule (e.g., the rule prevents co-location with other pods that are present on all nodes), the pod remains Pending.

Answer

The nodes have insufficient resources

Answer

The pod has a taint tolerance issue

Answer

The nodes are all cordoned

Question 15

You are troubleshooting a network connectivity issue between two pods in different namespaces. The pods have the following labels: pod-a in namespace 'foo' with labels {app: web}, pod-b in namespace 'bar' with labels {app: db}. You verify that both pods have IP addresses and can ping the Kubernetes service IP. However, pod-a cannot connect to pod-b on port 5432. What should you check first?

Accepted Answer

Check if a NetworkPolicy exists that denies ingress traffic to pod-b from namespace 'foo'. When pods can reach each other's IPs and services but a specific port connection fails, the most likely cause in a multi-namespace Kubernetes cluster is a NetworkPolicy restricting ingress to pod-b. NetworkPolicies are namespace-scoped and can deny cross-namespace traffic on specific ports, which perfectly matches the symptom of ICMP/service reachability succeeding while TCP/5432 fails.

Answer

Check if the kube-proxy is running on the node hosting pod-b

Answer

Check if the container runtime is Docker

Answer

Check if the DNS resolution for pod-b's service is correct