Courseiva

Certified Kubernetes Administrator CKA (CKA) — Questions 301–375

726 questions total · 10pages · All types, answers revealed

Take a mock examExam hub
Page 4

Page 5 of 10

Page 6
301
MCQhard

A pod is in CrashLoopBackOff. The YAML for the initContainer is: apiVersion: v1 kind: Pod metadata: name: myapp spec: initContainers: - name: init image: busybox command: ['sh', '-c', 'sleep 5 && exit 1'] containers: - name: app image: nginx What is the most likely reason for the CrashLoopBackOff?

A.The main container image nginx is not pulled successfully
B.The init container command is misspelled
C.The init container exits with non-zero exit code
D.The pod has insufficient memory
AnswerC

The init container's role is to run to completion before the main container starts; if it fails, the pod cannot proceed. When an init container exits with a non-zero exit code, the kubelet restarts the pod according to the restartPolicy, causing the pod to enter CrashLoopBackOff after repeated failures. This is the standard mechanism for Init:CrashLoopBackOff, so a non-zero exit code is the correct explanation.

Why this answer

Init containers must complete successfully (exit 0) before the main container starts. An exit code 1 causes the pod to fail and restart.

Full explanation →
302
MCQhard

A developer needs to access the Kubernetes API from a pod using a ServiceAccount. Which of the following is the recommended way to mount the ServiceAccount token into a pod?

A.Use the downward API to inject the token as an environment variable.
B.Set the token in the pod spec using the 'serviceAccountToken' field.
C.Mount the secret directly using a volume.
D.Use a projected service account token with a mount path.
AnswerD

Use a projected volume with a serviceAccountToken source and set a mountPath—such as /var/run/secrets/kubernetes.io/serviceaccount—to expose a TokenRequest-based token file in the pod. The kubelet requests the token with a configurable audience and expirationSeconds, writes it to the specified path, and automatically rewrites it as expiry approaches, enabling client libraries to reload the credential. This is the recommended approach because it minimizes token lifetime, allows audience restriction, and avoids the security drawbacks of environment variables or unmanaged, long-lived secrets.

Why this answer

The recommended way to mount a ServiceAccount token into a pod is by using a projected service account token volume. This approach, introduced in Kubernetes 1.20, provides a time-bound, audience-scoped, and automatically rotated token that is mounted as a file at a specified mount path, enhancing security over static secrets.

Exam trap

The trap here is that candidates often think mounting the ServiceAccount's secret directly (Option C) is still the recommended method, but the CKA exam expects knowledge of the newer, more secure projected token approach introduced in Kubernetes 1.20+.

How to eliminate wrong answers

Option A is wrong because the Downward API cannot inject the ServiceAccount token as an environment variable; it only exposes pod metadata (e.g., labels, annotations, namespace) and not secrets or tokens. Option B is wrong because there is no 'serviceAccountToken' field in the pod spec; the token is automatically mounted via the 'serviceAccountName' field, but the token itself is not directly specified in the pod spec. Option C is wrong because mounting the secret directly (e.g., the token secret created by Kubernetes for the ServiceAccount) is deprecated and less secure, as it lacks automatic rotation and audience binding, unlike projected tokens.

Full explanation →
303
MCQmedium

An administrator notices that traffic to a Service is not being forwarded to any pod. The Service has selector 'app: web' and there are pods with that label. However, 'kubectl get endpoints' shows no endpoints. What is the most likely cause?

A.The Service port name does not match the container port name.
B.The Service type is ClusterIP.
C.The Service targetPort is not specified.
D.The pods are not in Ready state (e.g., failing readiness probes).
AnswerD

Readiness probes determine whether a pod is included in the Service's EndpointSlices. The endpoint controller monitors pod readiness and only adds pods whose readiness probe is currently passing; pods failing readiness (or running a container that never becomes ready) are excluded. If all matching pods fail their readiness probe, the endpoint list is empty, and traffic to the Service's ClusterIP or DNS name is dropped. This directly explains why traffic is not reaching the application when the selector matches but no endpoints exist.

Why this answer

The most likely cause is that the pods are not in Ready state, often due to failing readiness probes. Kubernetes endpoints are only populated for pods that pass their readiness checks; if a pod is not Ready, it is removed from the Service's endpoint list, even if it is running and has the correct labels.

Exam trap

The trap here is that candidates often assume label matching alone guarantees endpoint creation, but Kubernetes requires pods to be in the Ready state (determined by readiness probes) before they are added to the Service's endpoints.

How to eliminate wrong answers

Option A is wrong because the Service port name and container port name do not need to match; the Service selects pods by label, and port mapping is done by port number or targetPort, not by name. Option B is wrong because ClusterIP is the default Service type and does not affect endpoint population; endpoints are created regardless of the Service type as long as there are matching Ready pods. Option C is wrong because if targetPort is not specified, it defaults to the same value as the Service's port, which still allows traffic to reach the container port; missing targetPort does not prevent endpoints from being created.

Full explanation →
304
MCQmedium

A cluster administrator wants to expand an existing PersistentVolumeClaim (PVC) that is bound to a PersistentVolume (PV) with reclaim policy Delete and storage class 'fast'. The PV was dynamically provisioned. Which condition is required for the PVC expansion to succeed?

A.The PV must be in Released state.
B.The StorageClass 'fast' must have allowVolumeExpansion: true.
C.The reclaim policy must be changed to Retain before expansion.
D.The PVC must be using access mode ReadWriteOnce.
AnswerB

This statement is correct because volume expansion is a feature that must be explicitly enabled at the StorageClass level. The `allowVolumeExpansion: true` parameter within the StorageClass definition signals to Kubernetes and the underlying storage provisioner that volumes provisioned by this class are capable of being resized. Without this setting, any attempt to expand a PersistentVolumeClaim (PVC) will be rejected by the API server, regardless of the underlying storage system's capabilities.

Why this answer

For PVC expansion to succeed with a dynamically provisioned PV, the StorageClass must have the `allowVolumeExpansion: true` field set. This field explicitly enables volume expansion for all PVCs using that StorageClass. Without it, the PVC expansion request will be rejected even if other conditions are met.

Exam trap

The trap here is that candidates often confuse PV reclaim policy (Delete/Retain) with expansion capabilities, or assume the PV must be in a specific state like Released, when in fact the StorageClass setting is the sole gatekeeper for volume expansion.

How to eliminate wrong answers

Option A is wrong because the PV must be in Bound state (not Released) to allow PVC expansion; a Released PV indicates the PVC was deleted, and expansion is not possible. Option C is wrong because the reclaim policy (Delete/Retain) does not affect the ability to expand a PVC; expansion is controlled by the StorageClass setting, not the reclaim policy. Option D is wrong because PVC expansion is supported for all access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) as long as the underlying volume plugin supports it; ReadWriteOnce is not a requirement.

Full explanation →
305
MCQmedium

A node in the cluster is showing status 'NotReady'. You run 'kubectl describe node worker1' and see that the kubelet has not posted node status for more than 1 minute. Which command should you run on the node to check the kubelet logs?

A.cat /var/log/kubelet/kubelet.log
B.kubectl logs kubelet -n kube-system
C.systemctl restart kubelet
D.journalctl -u kubelet
AnswerD

journalctl -u kubelet is the correct command on systemd-based systems because the kubelet runs as a systemd service and writes its logs to the systemd journal. This command filters the journal to show only kubelet entries, revealing errors such as failed API server connectivity, CNI plugin failures, or node lease renewal problems. These logs are essential for diagnosing why the node is NotReady, as they contain the actual failure messages that file-based logs or kubectl cannot provide.

Why this answer

On systemd-based systems, 'journalctl -u kubelet' is the standard command to view kubelet logs. 'journalctl -f -u kubelet' follows the log, but the question asks for checking logs, not following.

Full explanation →
306
Multi-Selectmedium

Which TWO statements are correct regarding DaemonSets?

Select 2 answers
A.DaemonSets do not support rolling updates.
B.DaemonSets can be scaled up and down using kubectl scale.
C.DaemonSets use a replica count to determine how many pods to run.
D.DaemonSets are often used for cluster monitoring or logging agents.
E.DaemonSets ensure that all (or some) nodes run a copy of a pod.
AnswersD, E

DaemonSets are the standard workload type for node-level agents because they guarantee coverage on every node. Common use cases include log shippers like Fluentd or Filebeat, which must run locally to forward each node's logs, and monitoring agents such as Prometheus Node Exporter or Datadog, which collect per-node metrics. Running such agents as a DaemonSet ensures they automatically appear on newly added nodes and are removed when nodes are deleted.

Why this answer

DaemonSets are designed to run a copy of a pod on every node (or a subset of nodes based on node selectors), making them ideal for cluster-wide infrastructure services such as monitoring agents (e.g., Prometheus Node Exporter), logging agents (e.g., Fluentd), and network plugins (e.g., Calico). This pattern ensures that each node has the necessary agent running without manual intervention.

Exam trap

The trap here is that candidates confuse DaemonSets with Deployments or StatefulSets, mistakenly thinking they support scaling via `kubectl scale` or use a replica count, when in fact DaemonSets are node-driven and scale automatically based on node membership.

Full explanation →
307
MCQhard

A developer runs 'kubectl port-forward service/my-svc 8080:80' and reports that connections to localhost:8080 fail. The service is a ClusterIP service that selects pods with label 'app: my-app'. What is the most likely cause?

A.The service type is ClusterIP, which does not support port forwarding.
B.No pods match the service selector, so the service has no endpoints.
C.kubectl port-forward cannot forward to services, only to pods.
D.The port forward command requires the --address flag to bind to localhost.
AnswerB

This is the correct explanation. For a Service, kubectl port-forward requires at least one ready endpoint, which is created automatically when pod labels match the service's selector. When no pods match, the Endpoints object is empty, causing the API server to fail with an error such as 'Unable to connect to a frontend pod'. The developer must verify the selector against existing pod labels or manually define endpoints for selector-less services.

Why this answer

B is correct because if no pods match the service selector 'app: my-app', the service will have no endpoints. Without endpoints, the service cannot route traffic, and kubectl port-forward will fail to establish a connection to localhost:8080. The port-forward command relies on the service having at least one endpoint to forward traffic to.

Exam trap

The trap here is that candidates may assume port forwarding only works with pods, but Kubernetes actually supports port forwarding to services by automatically selecting a pod from the service's endpoints.

How to eliminate wrong answers

Option A is wrong because ClusterIP services do support port forwarding; the service type does not affect the ability to use kubectl port-forward. Option C is wrong because kubectl port-forward can forward to services (as well as pods) by resolving the service to its endpoints. Option D is wrong because the --address flag is optional and defaults to localhost; the failure is not due to missing the --address flag.

Full explanation →
308
MCQmedium

Which of the following is the default DNS name for a Service named 'my-svc' in namespace 'my-ns'?

A.my-svc.my-ns.svc.cluster.local
B.my-svc.my-ns.cluster.local
C.my-svc.my-ns.svc
D.my-svc.my-ns.pod.cluster.local
AnswerA

This represents the fully qualified domain name (FQDN) for a Kubernetes Service. It strictly adheres to the standard format `<service-name>.<namespace>.svc.<cluster-domain>`, where the `svc` segment explicitly identifies the resource type as a service and `cluster.local` represents the default cluster-wide domain suffix.

Why this answer

A is correct because Kubernetes uses a built-in DNS system (CoreDNS) that automatically creates DNS records for Services. The fully qualified domain name (FQDN) for a Service follows the pattern `<service-name>.<namespace>.svc.cluster.local`, where `svc` is a fixed label indicating it's a Service record, and `cluster.local` is the default cluster domain. This allows pods to resolve the Service by name within the cluster.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or the `cluster.local` suffix, confusing the Service DNS pattern with the Pod DNS pattern or assuming a shorter name will work due to search domain expansion.

How to eliminate wrong answers

Option B is wrong because it omits the `svc` subdomain, which is a required component in the DNS name for a Service; without it, the DNS query would not match the Service's A/AAAA record. Option C is wrong because it lacks the cluster domain suffix `cluster.local`, making it an incomplete FQDN that would not be resolved by CoreDNS unless a search domain is appended. Option D is wrong because it uses `pod` instead of `svc`, which is the subdomain for Pod DNS records (e.g., `pod-ip.namespace.pod.cluster.local`), not for Services.

Full explanation →
309
MCQmedium

You suspect the kubelet on a worker node has stopped. Which two commands should you run to confirm the kubelet status and check its logs?

A.systemctl status docker and tail -f /var/log/syslog
B.kubectl get nodes and kubectl describe node <node>
C.systemctl restart kubelet and journalctl -u containerd
D.systemctl status kubelet and journalctl -u kubelet
AnswerD

This is the standard diagnostic pair for a systemd-managed kubelet. `systemctl status kubelet` shows whether the unit is active (running), failed, or inactive, and gives the last few log lines plus the main process PID; it also returns a non-zero exit code when the service is not running, which is useful for scripting. `journalctl -u kubelet` retrieves the full journal for the kubelet unit, allowing you to see startup errors, crashed state, or repeated restarts—critical for identifying why the kubelet stopped, such as a bad kubelet config, certificate expiry, or a missing CSI driver.

Why this answer

To check if the kubelet is running, use 'systemctl status kubelet'. To view logs, use 'journalctl -u kubelet'. The other options target the wrong service or are not applicable.

Full explanation →
310
MCQmedium

You have a headless service named 'my-headless' with clusterIP: None. A pod in the same namespace queries the DNS name 'my-headless'. What will the DNS response contain?

A.An error because headless services cannot be queried by DNS.
B.A single A record with the service's IP.
C.The ClusterIP of the service (which is None).
D.A list of A records for each pod matching the service selector.
AnswerD

A headless Service with a selector creates Endpoints (or EndpointSlices) from the ready pods that match the labels. When a client looks up this Service name, CoreDNS returns one A record for each such pod IP, allowing direct pod discovery. This behavior is fundamental to StatefulSets, where each pod gets its own DNS name from this list.

Why this answer

A headless service (clusterIP: None) does not have a ClusterIP or load-balance traffic. Instead, DNS queries for the service name return A records for the individual pod IPs that match the service's selector. This allows direct pod-to-pod communication without a proxy, as defined by Kubernetes DNS specification.

Exam trap

The trap here is that candidates confuse headless services with normal ClusterIP services, assuming DNS will return a single virtual IP or an error, rather than understanding that headless services return multiple pod IPs for direct pod-to-pod resolution.

How to eliminate wrong answers

Option A is wrong because headless services are specifically designed to be queried by DNS, returning pod IPs rather than an error. Option B is wrong because a headless service does not have a single service IP; it returns multiple A records for each matching pod. Option C is wrong because the ClusterIP is explicitly set to 'None', and the DNS response does not return this value; it returns pod IPs instead.

Full explanation →
311
MCQeasy

You need to check the current resource usage of nodes in your cluster. Which command should you use?

A.kubectl top pods
B.kubectl get events
C.kubectl get nodes -o wide
D.kubectl top nodes
AnswerD

kubectl top nodes is the correct command because it queries the metrics.k8s.io API provided by metrics-server to return each node’s current total CPU and memory usage, along with the percentage relative to allocatable capacity. It aggregates pod usage plus node-level system reservations from cAdvisor and presents a concise per-node snapshot, making it the standard built-in way to assess current node resource consumption.

Why this answer

`kubectl top nodes` retrieves and displays real-time CPU and memory usage metrics for all nodes in the cluster, directly answering the question about current resource usage. This command relies on the metrics server being deployed in the cluster to collect resource utilization data from kubelets via the Summary API.

Exam trap

The trap here is that candidates confuse `kubectl top nodes` with `kubectl get nodes -o wide`, mistakenly thinking the latter shows resource usage when it only shows network and OS details, not utilization metrics.

How to eliminate wrong answers

Option A is wrong because `kubectl top pods` shows resource usage for pods, not nodes, so it does not meet the requirement to check node-level resource usage. Option B is wrong because `kubectl get events` lists cluster events (e.g., scheduling failures, pod lifecycle changes) and does not provide any resource utilization metrics. Option C is wrong because `kubectl get nodes -o wide` displays node metadata such as internal IP, external IP, and OS image, but not real-time CPU or memory usage.

Full explanation →
312
MCQeasy

Which command can you run to see the events related to a specific pod?

A.kubectl logs pod-name
B.kubectl get pod pod-name
C.kubectl get events
D.kubectl describe pod pod-name
AnswerD

kubectl describe pod pod-name retrieves the Pod's full configuration along with a dedicated 'Events' section that records timestamped, sequential notifications from the kubelet and controller-manager about that Pod. These events describe actions like scheduling decisions, container creation, image pulling, probe failures, and restarts, which are exactly what you need when debugging why a Pod is stuck or repeatedly crashing. The describe command aggregates just the events for that specific Pod, making it the direct answer to the question.

Why this answer

`kubectl describe pod pod-name` includes a dedicated 'Events' section that lists all lifecycle events for that specific pod, such as scheduling, container pulls, and restarts. This command filters events to only those relevant to the pod, making it the most direct way to view pod-specific events without needing to parse all cluster events.

Exam trap

The trap here is that candidates often confuse `kubectl logs` (application output) with `kubectl describe` (cluster events), or assume `kubectl get events` is the only way to view events, missing that `kubectl describe` automatically filters events for the specified resource.

How to eliminate wrong answers

Option A is wrong because `kubectl logs pod-name` retrieves the container's stdout/stderr logs, not Kubernetes events; logs show application output, not cluster-level scheduling or lifecycle events. Option B is wrong because `kubectl get pod pod-name` only displays the pod's current status and metadata in a summary table, omitting the detailed event history. Option C is wrong because `kubectl get events` lists all events across the entire namespace or cluster, requiring manual filtering to find those related to a specific pod, which is less efficient and not targeted.

Full explanation →
313
MCQmedium

A Pod has an init container that writes a configuration file, and the main container reads that file. The init container runs successfully, but the main container fails with 'file not found'. What is the most likely cause?

A.The init container wrote the file to a different volume than the one mounted in the main container.
B.The main container restarted and the init container did not rerun.
C.The main container's command is incorrect.
D.The init container did not complete before the main container started.
AnswerA

Kubernetes containers within a pod, including init and main containers, have isolated filesystems by default. For an init container to share data, such as a configuration file, with a main container, they must both mount the same shared volume, like an `emptyDir`. If the init container wrote the file to its own ephemeral filesystem or a volume not also mounted by the main container, the main container would correctly report "file not found" as it cannot access that location.

Why this answer

The most likely cause is that the init container wrote the configuration file to a volume that is not shared with the main container. In Kubernetes, init containers and main containers in the same Pod share the same filesystem only if they mount the same Volume. If the init container writes to a volume that is not mounted in the main container, or writes to a different path within the same volume, the main container will not see the file.

This is a common misconfiguration when using emptyDir or hostPath volumes.

Exam trap

The trap here is that candidates assume init containers and main containers automatically share the same filesystem, but Kubernetes isolates container filesystems by default unless volumes are explicitly shared.

How to eliminate wrong answers

Option B is wrong because if the main container restarts, init containers do not rerun by design — they run to completion before any main container starts, and their output persists in shared volumes, so a restart of the main container would still see the file if it was written to a shared volume. Option C is wrong because an incorrect command in the main container would typically cause a different error (e.g., command not found, exit code 127) or a crash loop, not a 'file not found' error, unless the command explicitly references a missing file. Option D is wrong because Kubernetes guarantees that init containers complete successfully before any main container starts; the Pod's lifecycle ensures the init container's status is 'Completed' before the main container's status moves to 'Running'.

Full explanation →
314
Multi-Selecthard

You have a multi-node Kubernetes cluster. After upgrading the kubelet on a worker node, the node remains in 'NotReady' state. Which TWO actions should you take to troubleshoot? (Choose TWO.)

Select 2 answers
A.Check the node conditions using 'kubectl describe node <node-name>'
B.Check the pod logs on the node
C.Check the kubelet service status on the node using 'systemctl status kubelet'
D.Check the kube-apiserver logs on the control plane
E.Reboot the node
AnswersA, C

Running `kubectl describe node <node-name>` surfaces the node's status object, including the `Conditions` section with entries like `Ready`, `MemoryPressure`, and `PIDPressure`. Each condition carries a `LastHeartbeatTime` and a `Reason`/`Message` that explains why the node might be `NotReady` after an upgrade. This is the fastest control-plane-level check because it reflects the kubelet's last successful status update and any taints, capacity, or allocatable changes that could affect scheduling.

Why this answer

'kubectl describe node <node-name>' shows node conditions, including the 'Ready' status and any underlying issues like 'NetworkUnavailable', 'MemoryPressure', or 'KubeletNotReady'. This command provides a high-level view of why the node is NotReady, such as a kubelet version mismatch or resource exhaustion. It is the standard first step in diagnosing node health.

Exam trap

The trap here is that candidates often jump to checking the kube-apiserver logs (Option D) or rebooting (Option E) instead of focusing on the node's local kubelet service, which is the direct source of the NotReady state.

Full explanation →
315
Multi-Selectmedium

You need to check the status of control plane components. Which TWO commands are appropriate?

Select 2 answers
A.kubectl get pods -n kube-system
B.systemctl status kube-apiserver
C.kubectl get componentstatuses
D.top -u kube
E.systemctl list-units --type=service
AnswersA, C

Control plane components run as static pods in the kube-system namespace, so listing pods there reveals their phase, restart counts and readiness. This works on clusters where the componentstatuses API is deprecated or disabled, making it the reliable fallback for verifying scheduler, controller-manager and etcd health.

Why this answer

To check the status of control plane components in a kubeadm-established cluster, use 'kubectl get pods -n kube-system' to inspect the static pods. 'kubectl get componentstatuses' (deprecated but still a valid status check) reports health of the control plane components. 'systemctl status kube-apiserver' is not appropriate because the API server runs as a static pod, not a systemd service.

Exam trap

The CKA exam environment is built using kubeadm. Do not look for systemd services for the apiserver, controller-manager, or scheduler, as they run as static pods. Only the kubelet and the container runtime (e.g., containerd) run as systemd services on the nodes.

Full explanation →
316
MCQhard

You have a Kubernetes cluster with a single control-plane node and multiple worker nodes. You need to upgrade the cluster from v1.28.0 to v1.29.0. Which sequence of steps is correct?

A.Upgrade all worker nodes first, then upgrade the control plane
B.Drain all nodes simultaneously, upgrade the control plane, then upgrade worker nodes
C.Upgrade the control plane first, then drain each worker node, upgrade the kubelet and kube-proxy, then uncordon
D.Upgrade the control plane and worker nodes at the same time
AnswerC

This sequence is the recommended and correct procedure for a Kubernetes cluster upgrade. Upgrading the control plane first ensures that the central kube-apiserver can support newer worker node components and API versions. Subsequently, draining each worker node individually allows pods to gracefully migrate, minimizing downtime, before upgrading its kubelet and kube-proxy, and finally uncordoning it to rejoin the cluster.

Why this answer

Kubernetes requires the control plane to be upgraded first, as it is the source of truth for the cluster state and API version compatibility. After the control plane is upgraded, each worker node must be drained (to evict pods gracefully), upgraded (kubelet and kube-proxy), and then uncordoned to resume scheduling. This sequential process ensures that the cluster remains functional and that kubelet versions never exceed the kube-apiserver version, which is a strict compatibility requirement.

Exam trap

The trap here is that candidates often think worker nodes can be upgraded first to minimize control-plane downtime, but the CKA exam tests the strict version skew policy that requires the control plane to be upgraded first, and that draining all nodes simultaneously is a common misconception that would cause complete cluster unavailability.

How to eliminate wrong answers

Option A is wrong because upgrading worker nodes before the control plane violates the Kubernetes version skew policy, which requires the kube-apiserver to be at the highest version; if worker nodes are upgraded first, their kubelet may attempt to use API features not yet available on the older control plane, causing failures. Option B is wrong because draining all nodes simultaneously would make the cluster completely unavailable, and upgrading the control plane after draining all nodes is not the correct order; the control plane must be upgraded first while worker nodes are still running to maintain cluster operations. Option D is wrong because upgrading control plane and worker nodes at the same time is not supported; the control plane must be upgraded first to ensure API compatibility, and simultaneous upgrades can lead to version mismatches and cluster instability.

Full explanation →
317
MCQmedium

A node shows status NotReady. You SSH into the node and run 'systemctl status kubelet' which shows the kubelet is active (running). What is the next most likely step to diagnose the issue?

A.Restart the kubelet with systemctl restart kubelet
B.Check the container runtime status
C.Check kubelet logs with journalctl -u kubelet
D.Reboot the node
AnswerC

Checking kubelet logs with `journalctl -u kubelet` is the correct first diagnostic step because it provides the authoritative record of why the kubelet is reporting NotReady. The logs will show concrete errors such as failed CNI plugin execution, repeated API server connection timeouts, disk or memory pressure conditions (`eviction signals`), or Webhook errors, all of which directly explain the node's status. This is the most efficient way to pinpoint the failure rather than guessing, and it also gives you the timestamps to correlate with events from the control plane. Only after analyzing these logs should you decide whether a restart or other intervention is necessary.

Why this answer

Even if the kubelet is running, it may be unhealthy. Checking the kubelet logs with 'journalctl -u kubelet' can reveal errors such as network plugin failures or node pressure.

Full explanation →
318
MCQmedium

You run 'kubectl get pods' and see a pod with status 'CrashLoopBackOff'. You check the logs with 'kubectl logs <pod> --previous' and see: 'Error: unable to connect to database at db-svc:5432 (connection refused)'. What is the most likely cause?

A.The pod's liveness probe is misconfigured
B.The pod's container image is missing
C.The database service is not running or is unreachable
D.The pod has a memory limit that is too low
AnswerC

A connection refused error—specifically ECONNREFUSED—indicates that the application's TCP handshake reached the target host but nothing was listening on that port, or the service endpoints are empty because the backing database pods are not ready. This commonly occurs when the database Deployment has zero ready replicas, the Service selector does not match any pods, or the pod is using an incorrect service name or port. The container's main process exits after failing to initialize its database connection, and the kubelet restarts it, cycling into CrashLoopBackOff.

Why this answer

The error message 'connection refused' indicates that the pod is attempting to connect to the database at 'db-svc:5432' but the target service is not accepting TCP connections on port 5432. This typically means the database pod or service is not running, or a network policy is blocking the connection. The 'CrashLoopBackOff' status confirms the application container repeatedly fails due to this startup dependency.

Exam trap

The CKA exam often tests the distinction between application-level errors (like 'connection refused') and infrastructure-level errors (like OOM or image pull failures), so candidates must read the exact error message in the logs rather than assuming a generic pod failure cause.

How to eliminate wrong answers

Option A is wrong because a misconfigured liveness probe would cause the pod to be restarted after it had started, not produce a 'connection refused' error in the application logs; liveness probes check container health after startup, not database connectivity. Option B is wrong because a missing container image would result in an 'ImagePullBackOff' or 'ErrImagePull' status, not a 'CrashLoopBackOff' with a database connection error in the logs. Option D is wrong because a memory limit that is too low would cause an 'OOMKilled' status or 'OutOfMemory' error in the logs, not a TCP connection refused error.

Full explanation →
319
MCQeasy

What is the purpose of the 'kubeadm reset' command?

A.To restart the kubelet service
B.To undo the effects of kubeadm init or kubeadm join on a node
C.To upgrade the cluster to a newer version
D.To add a new node to the cluster
AnswerB

kubeadm reset is designed to reverse the changes made by kubeadm init or kubeadm join on that specific node. It removes the control-plane components (if present), deletes the local etcd member's data, cleans up /etc/kubernetes, /var/lib/kubelet, and other kubeadm-created directories, and resets network rules so the node returns to its pre-cluster state. This makes the node ready for a fresh kubeadm init or kubeadm join, or to be fully removed from the cluster.

Why this answer

The 'kubeadm reset' command is designed to revert a node back to its pre-'kubeadm init' or pre-'kubeadm join' state. It cleans up all cluster-related configuration, certificates, and etcd data (if running on the control plane), effectively removing the node from the cluster and allowing it to be re-initialized or re-joined cleanly.

Exam trap

The trap here is that candidates confuse 'kubeadm reset' with a simple service restart or a node addition command, but it is specifically a destructive cleanup that undoes the entire initialization or join process, not a maintenance or upgrade tool.

How to eliminate wrong answers

Option A is wrong because 'kubeadm reset' does not restart the kubelet service; restarting the kubelet is done via 'systemctl restart kubelet' and is unrelated to resetting cluster state. Option C is wrong because upgrading a cluster is performed using 'kubeadm upgrade plan' and 'kubeadm upgrade apply', not 'kubeadm reset', which is destructive and removes cluster data. Option D is wrong because adding a new node is done with 'kubeadm join', while 'kubeadm reset' is used to remove a node from the cluster, not add one.

Full explanation →
320
MCQhard

You have a NetworkPolicy that selects pods with label 'app: db'. The policy has an ingress rule allowing traffic from pods with label 'app: frontend'. A pod with label 'app: frontend' is in a different namespace. No namespaceSelector is specified in the ingress rule. Will traffic from that pod be allowed?

A.Yes, because podSelector selects pods across all namespaces
B.No, because NetworkPolicy only works within the same namespace
C.Yes, because all ingress traffic is allowed by default
D.No, because the frontend pod is in a different namespace and no namespaceSelector is specified
AnswerD

Since the frontend pod resides in a different namespace, a simple podSelector rule inside the NetworkPolicy will not match it. To permit cross-namespace traffic, the policy must explicitly define a namespaceSelector to target the external namespace.

Why this answer

A NetworkPolicy's ingress rule without a namespaceSelector only applies to pods within the same namespace as the policy. Since the frontend pod is in a different namespace and no namespaceSelector is specified, the rule does not match it, and traffic is denied by default (as NetworkPolicy enforces default-deny for selected pods).

Exam trap

The trap here is that candidates assume a podSelector alone can match pods across namespaces, confusing it with the behavior of a namespaceSelector, or they forget that NetworkPolicy defaults to deny-all ingress for selected pods.

How to eliminate wrong answers

Option A is wrong because a podSelector in a NetworkPolicy only selects pods within the policy's namespace, not across all namespaces, unless combined with a namespaceSelector. Option B is wrong because NetworkPolicy can work across namespaces when a namespaceSelector is used in the ingress rule, but the question states no namespaceSelector is specified. Option C is wrong because when a NetworkPolicy selects a pod, all ingress traffic is denied by default unless explicitly allowed by a matching rule; there is no default allow for ingress.

Full explanation →
321
MCQhard

A StatefulSet named 'db' manages 3 pods. The pods are named db-0, db-1, db-2. What is the expected behavior when the StatefulSet's pod management policy is set to OrderedReady and you scale down from 3 to 1 replica?

A.All pods are deleted simultaneously.
B.Pod db-2 is deleted, then db-1, and db-0 remains.
C.Only pod db-2 is deleted; db-1 and db-0 remain.
D.Pod db-0 is deleted first, then db-1, and db-2 remains.
AnswerB

When you scale a StatefulSet from 3 replicas to 1 with the default OrderedReady policy, the controller deletes pods in reverse ordinal order: db-2 is terminated first, then db-1, and the process stops once only the pod with ordinal 0 remains. This maintains the StatefulSet identity and ordering guarantees, ensuring db-0 is the final surviving member. Each deletion is completed before the next pod is terminated, so db-0 is never at risk of being deleted.

Why this answer

With the OrderedReady pod management policy, scaling down a StatefulSet deletes pods in reverse ordinal order, starting from the highest index. When scaling from 3 to 1 replica, pods db-2 (index 2) is deleted first, then db-1 (index 1), leaving db-0 (index 0) running. This ensures that each pod is fully terminated before the next one is deleted, maintaining the ordered startup and shutdown guarantees.

Exam trap

Kubernetes often tests the misconception that scaling down deletes pods in ascending order (starting from db-0) or that all pods are deleted at once, but the correct behavior for OrderedReady is reverse ordinal deletion.

How to eliminate wrong answers

Option A is wrong because OrderedReady policy does not delete all pods simultaneously; it deletes them one at a time in reverse order. Option C is wrong because scaling down to 1 replica requires deleting both db-2 and db-1, not just db-2. Option D is wrong because it describes deletion in ascending ordinal order (db-0 first), which is the opposite of the correct reverse-order behavior for scaling down.

Full explanation →
322
MCQhard

You create a PriorityClass named 'high-priority' with value 1000000 (one million). A pod uses this PriorityClass. The cluster has limited resources. What scheduling behavior is most likely?

A.The pod will never be preempted by other pods
B.The pod will be scheduled only after all lower-priority pods have been scheduled
C.The pod may preempt lower-priority pods to be scheduled
D.The pod will be assigned a higher CPU priority in the kernel
AnswerC

Correct. When a pod carries a high-priority PriorityClass, the scheduler treats it as eligible for preemption: if the pod cannot be placed on any node because of insufficient resources, the scheduler identifies nodes running pods with lower priorities and evicts those lower-priority pods to free capacity for the pending high-priority pod. This is governed by the preemptionPolicy field in the PriorityClass, which defaults to PreemptLowerPriority, and the actual eviction is performed through the PodDisruptionBudget-aware API, though critical pods may be protected if they have higher priority or are in terminating state.

Why this answer

PriorityClass with value 1000000 is extremely high (the default max is 1 billion). When a pod with this PriorityClass is submitted and the cluster has limited resources, the Kubernetes scheduler may preempt (evict) lower-priority pods to free resources and schedule this high-priority pod. This is the core behavior of PriorityClass and preemption in Kubernetes.

Exam trap

CNCF often tests the misconception that PriorityClass affects kernel-level CPU priority or that a high-priority pod is scheduled before all lower-priority pods, when in reality it only enables preemption and does not guarantee scheduling order.

How to eliminate wrong answers

Option A is wrong because even a pod with a very high priority can be preempted by a pod with an even higher priority (up to 1 billion), so it is not immune to preemption. Option B is wrong because scheduling order is not strictly based on priority; lower-priority pods can be scheduled first if resources are available, and high-priority pods may preempt them later. Option D is wrong because Kubernetes PriorityClass does not affect the kernel's CPU priority (nice value); it only controls scheduling and preemption within the Kubernetes scheduler.

Full explanation →
323
MCQmedium

A Pod is in CrashLoopBackOff. You run 'kubectl describe pod' and see that the container fails with 'Error: container command not found'. What is the most likely cause?

A.The container is running out of memory
B.The image pull is failing
C.The container image does not contain the specified command
D.The container command is not in the PATH
AnswerC

If the `command` or `args` defined in the Pod specification, or the `ENTRYPOINT` instruction within the container image's Dockerfile, refers to an executable that simply does not exist within the image's filesystem, the container runtime cannot execute it. This fundamental failure causes the container to exit immediately with a non-zero status. Kubernetes then detects this repeated failure and places the pod into a `CrashLoopBackOff` state, with `kubectl describe pod` typically showing an error like "executable file not found" or "no such file or directory" in the container's last termination message.

Why this answer

The error indicating a command is not found (typically presented as 'executable file not found in $PATH' in the container runtime events) most commonly occurs because the specified command or binary does not exist inside the container image at all (for example, trying to run 'bash' or 'curl' in a minimal distroless or scratch-based image, or due to a typo in the command name).

Exam trap

Do not confuse this with a system-level PATH misconfiguration on the Kubernetes host. The PATH being referred to is internal to the container image itself. If a command is not absolute (e.g., 'my-script' instead of '/usr/local/bin/my-script'), the container runtime will search the directories listed in the container's internal PATH variable.

If the binary is missing from the image entirely, it will fail with this error.

How to eliminate wrong answers

Option A is wrong because running out of memory typically causes an OOMKill, which appears as 'Exit Code 137' or 'Error: OOMKilled' in `kubectl describe pod`, not 'container command not found'. Option B is wrong because image pull failures result in events like 'ErrImagePull' or 'ImagePullBackOff', not a container exit error; the container never starts in that case. Option D is wrong because the 'command not found' error occurs when the command itself is missing from the image, not when it's simply not in the PATH; the container runtime (e.g., containerd) uses an absolute path or searches the image's default PATH, but if the binary is absent entirely, it fails regardless of PATH settings.

Full explanation →
324
MCQeasy

Which command shows events sorted by timestamp for troubleshooting recent issues?

A.kubectl logs --events
B.kubectl get events --sort-by=.lastTimestamp
C.kubectl describe events
D.kubectl get events
AnswerB

kubectl get events --sort-by=.lastTimestamp is correct because it lists cluster Event resources and applies a JSONPath sort on the lastTimestamp field, which records the most recent time the event was observed. This produces a clean chronological ordering of events—oldest to newest—making it easier to correlate system activity and identify the root cause sequence during troubleshooting.

Why this answer

The correct option is B, `kubectl get events --sort-by=.lastTimestamp`, because `kubectl get events` lists cluster events and the `--sort-by=.lastTimestamp` flag sorts them by the time each event last occurred, making it easy to spot the most recent events for troubleshooting. The `.lastTimestamp` field is the exact sortable field on Event objects that reflects when the event was last observed. Option A is invalid because `kubectl logs` retrieves container logs and has no `--events` flag.

Option C is invalid because `kubectl describe` operates on a specific resource and does not accept `events` as a resource type in that form. Option D is incomplete: `kubectl get events` lists events but does not sort them by timestamp, so recent issues may not appear first.

Full explanation →
325
MCQmedium

After deploying a new Deployment, you notice that the pods are stuck in ImagePullBackOff. What is the most common cause?

A.The liveness probe is misconfigured
B.The node has insufficient resources
C.The container image name or tag is incorrect
D.The container command fails on startup
AnswerC

Providing an invalid image name or an unavailable tag causes the container registry to return a 404 error to the kubelet. Consequently, the pod transitions into `ErrImagePull` and then `ImagePullBackOff` because the container runtime cannot locate or download the specified image layers.

Why this answer

The ImagePullBackOff status indicates that the kubelet 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 an exponential backoff retry loop, leading to the ImagePullBackOff state.

Exam trap

The trap here is that candidates confuse ImagePullBackOff with CrashLoopBackOff, but ImagePullBackOff specifically relates to image retrieval failures, not container runtime errors.

How to eliminate wrong answers

Option A is wrong because a misconfigured liveness probe causes the container to be restarted or killed (CrashLoopBackOff), not an image pull failure. Option B is wrong because insufficient node resources result in a PodPending state with events like 'FailedScheduling' or 'OutOfMemory', not ImagePullBackOff. Option D is wrong because a container command that fails on startup leads to a CrashLoopBackOff state, as the container exits immediately after starting, not an image pull issue.

Full explanation →
326
MCQmedium

You have a Deployment with 3 replicas. You run 'kubectl rollout history deployment web-app' and see revision 2 is current. You want to roll back to revision 1. Which command should you use?

A.kubectl set image deployment/web-app web-app=image:v1
B.kubectl rollout history deployment/web-app --revision=1
C.kubectl rollout undo deployment/web-app --to-revision=1
D.kubectl rollout undo deployment/web-app
AnswerC

This command explicitly instructs the deployment controller to revert the deployment's state to the exact configuration defined in revision 1. It achieves this by scaling up the ReplicaSet associated with revision 1 while scaling down the current active ReplicaSet.

Why this answer

`kubectl rollout undo deployment/web-app --to-revision=1` explicitly rolls back the Deployment to revision 1, which is the desired state. The `--to-revision` flag targets a specific revision from the rollout history, ensuring the Deployment's Pod template is reverted to the exact configuration of revision 1.

Exam trap

The trap here is that candidates often confuse `kubectl rollout undo` (which defaults to the previous revision) with the need to specify `--to-revision` to target an arbitrary revision, or they mistakenly use `kubectl set image` to 'revert' the image, which instead creates a new revision rather than rolling back.

How to eliminate wrong answers

Option A is wrong because `kubectl set image deployment/web-app web-app=image:v1` changes the container image to `image:v1` but does not perform a rollback; it creates a new revision (revision 3) rather than reverting to revision 1. Option B is wrong because `kubectl rollout history deployment/web-app --revision=1` only displays the details of revision 1 (e.g., annotations, template) without actually rolling back the Deployment. Option D is wrong because `kubectl rollout undo deployment/web-app` rolls back to the previous revision (revision 1 only if revision 2 is current and revision 1 is the immediate predecessor), but it does not guarantee targeting revision 1 if there are multiple revisions; the `--to-revision` flag is required to specify revision 1 explicitly.

Full explanation →
327
MCQmedium

You run 'kubectl get svc my-service -o yaml' and see 'type: ClusterIP'. The service has no endpoints. What is the most likely cause?

A.The service type is ClusterIP, which does not support endpoints.
B.The service's port does not match the container port.
C.The service is misconfigured and needs to be deleted and recreated.
D.No pods with labels matching the service selector are running and ready.
AnswerD

The endpoint controller only publishes Backends for pods that match the Service's selector and have their Ready condition set to True. If no pod carries the label/value pair defined in the selector, or if all matching pods are still Pending/Running with failing readiness probes, the Endpoints object stays empty. This is the canonical root cause of a Service with type ClusterIP but no endpoints.

Why this answer

A Kubernetes Service of type ClusterIP relies on a label selector to identify target Pods. If no Pods match the selector and are in the Ready state, the Service will have no endpoints, causing traffic to be dropped. The absence of endpoints directly indicates a mismatch or absence of matching, ready Pods.

Exam trap

The trap here is that candidates assume a missing endpoint is due to a port mismatch or Service type limitation, rather than recognizing that endpoints are solely driven by the label selector and Pod readiness.

How to eliminate wrong answers

Option A is wrong because ClusterIP is the default Service type and fully supports endpoints; endpoints are created when Pods matching the selector are ready. Option B is wrong because a port mismatch between the Service and container port would cause connection failures, not a lack of endpoints; endpoints are generated based on the selector, not port matching. Option C is wrong because misconfiguration (e.g., incorrect selector) can be fixed by editing the Service's selector field, not by deleting and recreating it; deletion is unnecessary unless the Service is fundamentally broken.

Full explanation →
328
MCQmedium

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

A.api.default.svc.cluster.local
B.default.api.svc.cluster.local
C.api.svc.default.cluster.local
D.api.default.cluster.local
AnswerA

The Kubernetes DNS schema for a Service is <service-name>.<namespace>.svc.cluster.local. Since the Service is named 'api' and created in the default namespace, the fully qualified domain name becomes api.default.svc.cluster.local. This FQDN resolves to the Service's ClusterIP and enables reliable cluster-wide service discovery.

Why this answer

The correct DNS name for a Service in Kubernetes follows the pattern `<service-name>.<namespace>.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.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or reverse the service/namespace order, because they may confuse the DNS format with other Kubernetes naming conventions (e.g., pod DNS or headless service records) or assume the namespace comes first.

How to eliminate wrong answers

Option B is wrong because it reverses the order of service name and namespace, which would be `default.api.svc.cluster.local` — this is not a valid Kubernetes DNS format. Option C is wrong because it places `svc` after the namespace, resulting in `api.svc.default.cluster.local` — the `svc` component must come after the namespace, not before it. Option D is wrong because it omits the `svc` subdomain entirely, giving `api.default.cluster.local` — this would not be resolved by CoreDNS for a Service, as the `svc` label is required in the DNS search path.

Full explanation →
329
MCQeasy

You have a pod that is in 'Pending' state because it requires a PersistentVolumeClaim that is not bound. Which event would you see in 'kubectl describe pod'?

A.0/1 nodes are available: 1 node(s) didn't match node selector
B.Failed to pull image "myimage:latest"
C.0/1 nodes are available: 1 Insufficient memory
D.0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims
AnswerD

This is the exact event message emitted by the kube-scheduler when a Pod references a PersistentVolumeClaim that uses the Immediate volume binding mode but has not yet been bound to a PersistentVolume. The scheduler cannot place the Pod on a node until the underlying storage is successfully provisioned and bound to satisfy the Pod's volume requirements.

Why this answer

When a pod is in 'Pending' state due to an unbound PersistentVolumeClaim (PVC), the scheduler cannot place the pod until the PVC is bound to a PersistentVolume (PV). The event message '0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims' is generated by the Kubernetes scheduler when it evaluates the pod's PVC requirement and finds no matching PV that satisfies the claim's storage class, access modes, and size, causing the pod to remain unscheduled.

Exam trap

The trap here is that candidates confuse 'Pending' state causes—such as resource shortages or node selector mismatches—with the specific PVC binding failure, which produces a unique scheduler event message that is explicitly listed in 'kubectl describe pod' output.

How to eliminate wrong answers

Option A is wrong because '0/1 nodes are available: 1 node(s) didn't match node selector' indicates a node selector mismatch (e.g., nodeSelector or nodeAffinity), not a PVC binding issue. Option B is wrong because 'Failed to pull image' is an image pull error that occurs after scheduling, typically resulting in a 'ImagePullBackOff' or 'ErrImagePull' status, not a 'Pending' state caused by an unbound PVC. Option C is wrong because '0/1 nodes are available: 1 Insufficient memory' is a resource shortage error (memory pressure) that prevents scheduling, but it does not relate to PVC binding; the scheduler would report a different message for unbound claims.

Full explanation →
330
MCQmedium

A pod is in Pending state. You see the event: '0/2 nodes are available: 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate'. What should you do to schedule the pod on one of the control-plane nodes?

A.Increase the pod's resource requests
B.Remove the taint from the control-plane node
C.Use a different namespace
D.Add a toleration to the pod spec matching the taint
AnswerD

Adding a toleration to the pod spec that matches the node's taint is the correct solution because tolerations explicitly opt a pod into scheduling on tainted nodes. The taint on the node uses key, value, and effect (e.g., node-role.kubernetes.io/control-plane:NoSchedule), and the toleration must mirror that key, value, and effect before the scheduler will place the pod there. This is the standard, least-privilege way to run a specific workload on a dedicated or control-plane node without weakening cluster-wide policies.

Why this answer

The pod is in Pending state because the control-plane nodes have a taint (node-role.kubernetes.io/control-plane) that the pod does not tolerate. By default, pods are not scheduled on control-plane nodes unless they explicitly tolerate that taint. Adding a toleration to the pod spec that matches the taint's key, effect, and optionally value allows the scheduler to place the pod on a control-plane node.

Exam trap

The trap here is that candidates may think removing the taint (Option B) is the correct fix, but the CKA exam expects you to use tolerations to selectively schedule pods on tainted nodes without altering node configuration.

How to eliminate wrong answers

Option A is wrong because increasing resource requests does not address taints or tolerations; it may even make scheduling harder by requiring more resources. Option B is wrong because removing the taint from the control-plane node would allow all pods to schedule there, which is not the intended solution for a specific pod and could compromise node isolation. Option C is wrong because namespaces are a logical isolation boundary and have no effect on taint/toleration mechanics or scheduling decisions.

Full explanation →
331
MCQmedium

You create a Service of type LoadBalancer in a Kubernetes cluster that does not have an external load balancer provider (e.g., bare-metal). What will be the state of the EXTERNAL-IP field when you run 'kubectl get svc'?

A.The ClusterIP
B.The node's IP address
C.<pending>
D.<none>
AnswerC

Immediately after a LoadBalancer service is created, its external IP status is set to <pending>. This status persists until the cloud-controller-manager successfully communicates with the underlying cloud provider's API to provision the physical or virtual load balancer and assign it a public IP address.

Why this answer

When a Service of type LoadBalancer is created in a Kubernetes cluster without an external load balancer provider (e.g., bare-metal or on-premises), the cloud-controller-manager component responsible for provisioning the external load balancer is absent or non-functional. As a result, the external IP address remains unassigned, and `kubectl get svc` displays `<pending>` for the EXTERNAL-IP field until a controller sets it. This state persists indefinitely unless an external tool like MetalLB is deployed to fulfill the LoadBalancer request.

Exam trap

The trap here is that candidates confuse `<pending>` with `<none>`, assuming that without a cloud provider the field will simply be empty, but Kubernetes explicitly marks the LoadBalancer Service as pending to indicate it is waiting for an external IP assignment.

How to eliminate wrong answers

Option A is wrong because the ClusterIP is the internal IP assigned to the Service for cluster-internal traffic, not the external IP; the EXTERNAL-IP field is separate and shows the load balancer's address. Option B is wrong because the node's IP address is not automatically assigned to a LoadBalancer Service; a cloud provider or external controller must program the load balancer to route traffic to nodes, and without one, no IP is populated. Option D is wrong because `<none>` indicates the field is intentionally empty (e.g., for ClusterIP or NodePort Services), but for a LoadBalancer Service, the field is expected to be assigned and shows `<pending>` to reflect the waiting state.

Full explanation →
332
MCQeasy

Which kubectl command is used to drain a node before performing maintenance?

A.kubectl cordon node01
B.kubectl drain node01
C.kubectl taint node node01 key=value:NoExecute
D.kubectl delete node node01
AnswerB

The `kubectl drain node01` command is the proper way to prepare a node for maintenance. It cordons the node to make it unschedulable and then evicts all pods on the node (except DaemonSet-managed pods and mirror pods by default) gracefully, respecting PodDisruptionBudgets and terminating containers with proper pre-stop hooks. After the drain completes, the node is both unschedulable and free of workloads, allowing safe maintenance or shutdown. Use flags like --ignore-daemonsets or --delete-emptydir-data when needed, but the base command is the correct starting point.

Why this answer

The `kubectl drain` command is the correct tool for safely evicting all pods from a node before maintenance. It marks the node as unschedulable (similar to `cordon`) and then gracefully terminates pods, respecting PodDisruptionBudgets, ensuring workloads are rescheduled to other nodes without disruption.

Exam trap

CNCF often tests the distinction between `cordon` (only prevents new pods) and `drain` (evicts existing pods), leading candidates to mistakenly choose `cordon` when the question explicitly requires draining for maintenance.

How to eliminate wrong answers

Option A is wrong because `kubectl cordon` only marks the node as unschedulable (SchedulingDisabled) but does not evict existing pods, so maintenance would still leave running workloads on the node. Option C is wrong because `kubectl taint` with `NoExecute` evicts pods that do not tolerate the taint, but it does not gracefully drain all pods or respect PodDisruptionBudgets, and it is not the standard command for node maintenance preparation. Option D is wrong because `kubectl delete node` removes the node object from the cluster entirely, which is destructive and not intended for maintenance; it does not evict pods or cordon the node first, potentially causing workload disruption.

Full explanation →
333
MCQeasy

What is the purpose of a PriorityClass in Kubernetes?

A.To define which nodes a pod can be scheduled on based on priority
B.To set the order in which pods are started
C.To ensure that high-priority pods can preempt lower-priority pods
D.To give a pod a higher share of CPU cycles
AnswerC

The primary function of a PriorityClass is to assign a priority value to a pod, enabling the Kubernetes scheduler to make preemption decisions. When a higher-priority pod is pending due to insufficient resources on any node, the scheduler can evict one or more lower-priority pods from a suitable node to free up the necessary capacity. This mechanism ensures that critical workloads can always find space to run, even in a resource-constrained environment.

Why this answer

PriorityClass in Kubernetes is used to assign a priority value to pods, which the scheduler uses to determine scheduling order and, critically, to enable preemption. When the cluster is under resource pressure, the scheduler can preempt (evict) lower-priority pods to make room for higher-priority pods that cannot be scheduled. This ensures that critical workloads can run even when resources are scarce, which is the core purpose of PriorityClass.

Exam trap

CNCF often tests the misconception that PriorityClass controls CPU or memory resource allocation (like QoS classes), whereas it strictly controls scheduling priority and preemption behavior, not runtime resource guarantees.

How to eliminate wrong answers

Option A is wrong because node selection based on priority is handled by node affinity, node selectors, or taints/tolerations, not by PriorityClass. Option B is wrong because the order in which pods are started is influenced by PriorityClass only in the context of scheduling and preemption, but there is no guaranteed startup order; Kubernetes does not provide a sequential startup mechanism. Option D is wrong because CPU cycles are allocated based on resource requests and limits, not priority; priority does not affect CPU shares or scheduling fairness within the node's cgroups.

Full explanation →
334
MCQeasy

An administrator is preparing a bare-metal node to join an existing kubeadm cluster. The node has containerd installed and running, swap disabled, and the required kernel modules loaded. Before running kubeadm join, which command should the administrator run to ensure the kubelet registers with the API server using the correct node name?

A.kubeadm config images pull
B.kubeadm join --discovery-token ... --discovery-token-ca-cert-hash ...
C.hostnamectl set-hostname <name> (or verify /etc/hostname) and confirm the kubelet --hostname-override setting matches.
D.kubeadm init --config kubeadm-config.yaml
AnswerC

The kubelet derives its node name from the system hostname unless --hostname-override is set. Ensuring the hostname is the intended unique name, or that the override in /var/lib/kubelet/kubeadm-flags.env matches, guarantees the node registers correctly and avoids duplicate or misleading node entries in the cluster.

Why this answer

The kubelet's node name comes from the system hostname or an explicit --hostname-override, so the administrator must confirm or set the hostname before joining. Pulling images, running init, or invoking join without checking the name risks registering the node under an unintended identity that later requires a reset.

Exam trap

The trap here is believing kubeadm join accepts a --node-name flag to rename the node, when the name is actually determined by the hostname or a kubelet override configured before the join.

Full explanation →
335
MCQmedium

A user tries to create a pod with the YAML file that requests 2 CPUs as a limit. The cluster has a ResourceQuota named 'compute-quota' with limits.cpu: 2. The user sees the above error. What is the likely issue?

A.The pod is requesting 2 CPUs as a request, but the quota limits requests.
B.The pod is being created in the wrong namespace.
C.The pod is trying to use more CPU than the node capacity.
D.The current total CPU limit usage in the namespace is 1, and adding a pod with limit 2 would exceed the quota of 2.
AnswerD

This is correct because the namespace has a hard ResourceQuota limit of 2 CPUs (limits.cpu: 2) and currently has 1 CPU already allocated to existing pods. Attempting to create a new pod requesting a limit of 2 CPUs would bring the total requested limit to 3. This exceeds the hard quota of 2, causing the ResourceQuota admission controller to reject the pod creation request.

Why this answer

The ResourceQuota 'compute-quota' sets a hard limit of 2 CPUs for all pods in the namespace. If the current total CPU limit usage is already 1, adding a new pod with a limit of 2 would bring the total to 3, exceeding the quota. Kubernetes enforces ResourceQuota at admission time, rejecting the pod creation to prevent the namespace from exceeding its configured limits.

Exam trap

The trap here is that candidates confuse ResourceQuota enforcement with node capacity or scheduling constraints, but the error is specifically an admission-level quota violation, not a resource shortage on any node.

How to eliminate wrong answers

Option A is wrong because the error is about CPU limits, not requests; the quota specifically restricts limits.cpu, and the pod is requesting a limit of 2 CPUs, not a request. Option B is wrong because the error message does not indicate a namespace mismatch; ResourceQuota is namespace-scoped, but the pod is likely being created in the same namespace as the quota, and the error is about exceeding the quota, not a wrong namespace. Option C is wrong because the error is not about node capacity; node capacity is a scheduling concern handled by the kube-scheduler, while ResourceQuota is an admission control mechanism that rejects the pod before scheduling even considers node resources.

Full explanation →
336
MCQmedium

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?

A.The container's entrypoint command failed
B.The container's readiness probe failed
C.The container image was not found
D.The container was killed because it exceeded its memory limit
AnswerD

Exit code 137 is calculated as 128 plus the signal number 9 (SIGKILL), which indicates that the operating system or container runtime forcefully terminated the process. In Kubernetes, this most commonly occurs when a container exceeds its configured memory limit, triggering the Linux Out-Of-Memory (OOM) killer to terminate the process to safeguard node stability.

Why this answer

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.

Exam trap

The trap here is that candidates confuse exit code 137 with a generic application crash (exit code 1) or a probe failure, but 137 specifically indicates an OOM kill due to memory limit violation.

How to eliminate wrong answers

Option A is wrong because an entrypoint command failure would produce a non-zero exit code like 1 or 127, not 137, which is specifically tied to signal termination. Option B is wrong because a readiness probe failure does not cause the container to exit; it only removes the pod from service endpoints while the container continues running. Option C is wrong because an image-not-found error results in `ErrImagePull` or `ImagePullBackOff` status, not a container exit code.

Full explanation →
337
MCQhard

You are tasked with troubleshooting a web application that is deployed in a Kubernetes cluster. The application consists of a Deployment named 'web-app' with 3 replicas, each running a container that listens on port 3000. A Service named 'web-service' of type ClusterIP with selector 'app: web' and port 80 targeting port 3000 has been created. Additionally, an Ingress resource named 'web-ingress' is configured with a host rule for 'example.com' and backend service 'web-service' on port 80. Users report that accessing http://example.com results in a 503 Service Unavailable error. You verify that all pods are running, but kubectl get pods shows the READY column as 0/1 for each pod. The Ingress controller logs show 'upstream connect error or disconnect/reset before headers'. You check the endpoints: 'kubectl get endpoints web-service' shows no endpoints. The pods have the label 'app: web'. What should you do to resolve the issue?

A.Change the Service type to NodePort to bypass the Ingress.
B.Update the Ingress to use a different backend service.
C.Check the container port and readiness probe configuration; the pods may not be listening on the expected port or the readiness probe is failing.
D.Modify the Service selector to match the pod labels exactly.
AnswerC

Empty endpoints indicate no ready pods matching the selector; despite 'Ready' status, the readiness probe might be failing if not configured, or the container might not be listening on 3000.

Why this answer

Although the Service's selector 'app: web' matches the pod labels, the absence of endpoints indicates that the pods are not being considered ready by the Service. Since `kubectl get pods` shows the READY column as '0/1', the readiness probes are failing or the container is not successfully listening on the expected port. This prevents the endpoints controller from adding the pod IPs to the Service's Endpoints list.

Checking the container port and readiness probe configuration is the correct troubleshooting step.

Exam trap

The trap here is assuming that missing endpoints always mean a mismatched Service selector. If the pods are running but their READY status is 0/1, the endpoints will be empty because the readiness probe is failing, not because of a selector mismatch.

How to eliminate wrong answers

Option A is wrong because changing the Service type to NodePort does not fix the underlying issue of missing endpoints; it only exposes the Service on a node port, but the Ingress still relies on the Service's endpoints to route traffic. Option B is wrong because updating the Ingress to use a different backend service does not address the root cause—the current Service has no endpoints, and any backend service would face the same problem if its selector doesn't match pods. Option D is wrong because the Service selector 'app: web' already matches the pod labels 'app: web', so modifying the selector is unnecessary and would not resolve the missing endpoints if the pods are not listening on port 3000 or readiness probes are failing.

Full explanation →
338
MCQeasy

Which of the following is a valid way to mount a Secret as a volume in a Pod?

A.volumes: - name: secret-volume secret: secretName: my-secret
B.volumes: - name: secret-volume secretName: my-secret
C.volumes: - name: secret-volume configMap: name: my-secret
D.volumes: - name: secret-volume hostPath: path: /etc/secret
AnswerA

This is the correct syntax for mounting a Kubernetes Secret as a volume. The 'secret' volume source must be declared directly under the volume's name, and the 'secretName' field nested within it specifies the exact Secret resource to retrieve from the namespace.

Why this answer

It uses the `secret` volume type with the `secretName` field to reference a Kubernetes Secret object. This is the standard syntax for mounting a Secret as a volume in a Pod, allowing the Secret's data to be exposed as files in the container's filesystem.

Exam trap

The trap here is that candidates confuse the syntax for mounting a Secret with that of a ConfigMap, or incorrectly assume that `secretName` can be used as a top-level field without the `secret` key, leading them to pick option B.

How to eliminate wrong answers

Option B is wrong because it omits the `secret` key under the volume source; the `secretName` field must be nested under a `secret` key, not placed directly under the volume name. Option C is wrong because it uses the `configMap` volume type with a `name` field, which is for ConfigMaps, not Secrets; Secrets require the `secret` volume type. Option D is wrong because it uses `hostPath` to mount a directory from the node's filesystem, which does not mount a Kubernetes Secret object and bypasses Secret management and encryption.

Full explanation →
339
MCQmedium

A company deploys a web application with multiple replicas in a Kubernetes cluster. Users report intermittent connectivity issues. The application pods are exposed via a ClusterIP Service. To ensure stable connectivity, which action should be taken?

A.Change the Service type to NodePort
B.Set service.spec.sessionAffinity to ClientIP
C.Remove the ClusterIP Service and use headless service
D.Add a readiness probe to the pods
AnswerB

Configuring service.spec.sessionAffinity to ClientIP instructs kube-proxy to direct all subsequent requests from a specific client IP to the same backend pod for a designated timeout period. This maintains session state on the target pod, preventing the intermittent failures that occur when stateless load balancing distributes a single user's session across multiple replicas.

Why this answer

Intermittent connectivity issues with multiple replicas often stem from requests being distributed across different pods, which can break session state if the application is not stateless. Setting `service.spec.sessionAffinity` to `ClientIP` ensures that all requests from a given client IP are routed to the same pod, providing stable connectivity for stateful sessions without changing the service type or removing the ClusterIP.

Exam trap

The trap here is that candidates often confuse readiness probes (which ensure pods are healthy) with session affinity (which ensures client requests stick to the same pod), leading them to select the readiness probe option despite it not solving the session persistence problem.

How to eliminate wrong answers

Option A is wrong because changing the Service type to NodePort exposes the service on a static port on each node's IP, which does not address session persistence and may introduce additional network complexity without solving the intermittent connectivity issue. Option C is wrong because removing the ClusterIP Service and using a headless service disables load balancing and DNS-based round-robin, which would break the stable connectivity goal by requiring clients to manage pod IPs directly. Option D is wrong because adding a readiness probe only controls whether a pod receives traffic based on its health, but does not ensure that requests from the same client are consistently routed to the same pod, which is the root cause of intermittent connectivity for stateful applications.

Full explanation →
340
MCQmedium

A pod is in ImagePullBackOff state. Which command can you run to get more details about the underlying error?

A.kubectl logs pod
B.kubectl get events --field-selector involvedObject.name=pod
C.kubectl describe pod
D.kubectl top pod
AnswerC

The kubectl describe pod command retrieves the pod's events and status conditions, which include the specific image pull failure reason and message. This satisfies the stem's need for underlying error detail that kubectl get pod alone does not expose.

Why this answer

The `kubectl describe pod` command provides detailed information about the pod, including its status, conditions, events, and container states. For an `ImagePullBackOff` error, the output will include the exact error message from the container runtime (e.g., 'Failed to pull image', 'manifest not found', or 'unauthorized'), which is essential for diagnosing the root cause.

Exam trap

The trap here is that candidates often confuse `kubectl logs` (which shows application output) with `kubectl describe` (which shows pod lifecycle events and container runtime errors), leading them to choose A when the container never started to produce logs.

How to eliminate wrong answers

Option A is wrong because `kubectl logs pod` retrieves container logs, which are generated by the application inside the container; if the container never started due to ImagePullBackOff, there are no logs to fetch. Option B is wrong because `kubectl get events` with a field selector filters events by the pod's name, but the output may not include the detailed pull error from the kubelet or container runtime; `kubectl describe pod` consolidates those events alongside other critical status fields. Option D is wrong because `kubectl top pod` shows resource usage (CPU/memory) of running pods, which is irrelevant when the pod is in a non-running state like ImagePullBackOff.

Full explanation →
341
Multi-Selectmedium

A pod is in 'Pending' state. Which TWO of the following are possible causes? (Select 2)

Select 2 answers
A.Node has insufficient CPU or memory resources
B.Container exited with non-zero exit code
C.PersistentVolumeClaim is not bound
D.Container was killed due to OOM
E.Image name is misspelled
AnswersA, C

A Pod can only stay Pending when the scheduler is unable to place it on a node. If every node lacks sufficient allocatable CPU and/or memory to satisfy the Pod's `resources.requests`, kube-scheduler marks the Pod unschedulable and leaves it in Pending while continuously retrying scheduling. This is purely a pre-scheduling condition, so it remains until a node is scaled up or the requests are reduced.

Why this answer

Option A is correct because when a node lacks sufficient allocatable CPU or memory, the kube-scheduler cannot find a feasible node and leaves the pod in Pending with a FailedScheduling event. Option C is correct because a pod that references a PersistentVolumeClaim that is not yet Bound (for example, waiting on a dynamic provisioner or a matching PersistentVolume) will remain Pending until the PVC binds. Option B is incorrect because a non-zero container exit code indicates a runtime failure after the container started, producing CrashLoopBackOff or Error, not Pending.

Option D is incorrect because OOMKilled occurs when a running container exceeds its memory limit, resulting in a terminated container rather than a Pending pod. Option E is incorrect because a misspelled image name causes an ImagePullBackOff/ErrImagePull status once the kubelet attempts to pull the image, not a Pending phase.

Exam trap

CKA often tests the distinction between Pending (scheduling phase) and other failure states like CrashLoopBackOff or ImagePullBackOff, causing candidates to select runtime errors as causes of Pending.

Full explanation →
342
MCQeasy

Which command initializes a new Kubernetes cluster using kubeadm?

A.kubeadm create cluster
B.kubeadm setup
C.kubeadm init
D.kubeadm start
AnswerC

kubeadm init is the correct command to bootstrap a new Kubernetes control plane. It runs preflight checks, generates cluster certificates, creates the kubeconfig files, starts the static control-plane pods (kube-apiserver, kube-controller-manager, kube-scheduler), and installs a pod network add-on afterward. This is the standard, documented first step for creating a cluster with kubeadm.

Why this answer

`kubeadm init` is the official Kubernetes command to bootstrap a control-plane node and initialize a new cluster. It performs preflight checks, generates certificates, creates the static Pod manifests for core components (etcd, API server, controller manager, scheduler), and configures the admin kubeconfig file.

Exam trap

The trap here is that candidates confuse `kubeadm init` with generic system commands like `create` or `start`, or assume a `setup` subcommand exists, when in fact `kubeadm init` is the only correct command for initializing a cluster.

How to eliminate wrong answers

Option A is wrong because `kubeadm create cluster` is not a valid kubeadm subcommand; kubeadm uses `init` for control-plane initialization and `join` for worker nodes. Option B is wrong because `kubeadm setup` does not exist in the kubeadm CLI; the correct command for initializing a cluster is `kubeadm init`. Option D is wrong because `kubeadm start` is not a valid kubeadm subcommand; kubeadm does not manage the lifecycle of running processes—it only bootstraps the cluster, after which kubelet and container runtime handle the Pods.

Full explanation →
343
MCQeasy

Which command retrieves the rollout history of a Deployment named 'web'?

A.kubectl describe deployment web
B.kubectl get events --field-selector involvedObject.name=web
C.kubectl rollout history deployment web
D.kubectl rollout status deployment web
AnswerC

`kubectl rollout history deployment web` is the dedicated subcommand that lists all historical rollouts for Deployment `web`, displaying a table of revisions with their change causes (e.g., `REVISION CHANGE-CAUSE`). Internally it reads the Deployment's managed ReplicaSets and their `deployment.kubernetes.io/revision` annotations; with `--revision=N` it can also show the complete pod template for a specific revision, making it the correct command to view rollout history.

Why this answer

The `kubectl rollout history deployment web` command retrieves the revision history of the specified Deployment, showing each revision number and, with the `--revision` flag, the details of a specific revision. This is the standard Kubernetes command for viewing rollout history, as defined in the kubectl reference.

Exam trap

The CKA exam often tests the distinction between commands that show current state (`describe`, `status`) versus those that show historical data (`rollout history`), leading candidates to confuse `rollout status` with `rollout history`.

How to eliminate wrong answers

Option A is wrong because `kubectl describe deployment web` shows the current state and configuration of the Deployment, including its rollout strategy, but does not display the historical revisions or changes. Option B is wrong because `kubectl get events --field-selector involvedObject.name=web` retrieves events related to the Deployment, which may include rollout-related events but does not provide a structured history of revisions. Option D is wrong because `kubectl rollout status deployment web` shows the current status of an ongoing rollout (e.g., waiting for pods to become ready), not the historical record of past rollouts.

Full explanation →
344
MCQmedium

You apply the following NetworkPolicy: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress What effect does this policy have?

A.Ingress traffic from pods with label 'app: allowed' is allowed.
B.All ingress and egress traffic to/from pods in the namespace is denied.
C.The policy has no effect because no rules are specified.
D.All ingress traffic to any pod in the namespace is denied.
AnswerD

An empty podSelector selects every pod in the namespace, and the sole policyType is Ingress, so all inbound connections to those pods are blocked while egress stays unaffected. It satisfies the scenario's requirement to deny all incoming traffic namespace-wide.

Why this answer

This NetworkPolicy uses a `podSelector: {}` which selects all pods in the namespace, and specifies `policyTypes: [Ingress]` with no ingress rules. According to Kubernetes NetworkPolicy semantics, when no ingress rules are defined, all ingress traffic is denied. This effectively creates a default-deny ingress policy for all pods in the namespace, making option D correct.

Exam trap

The trap here is that candidates often think a NetworkPolicy with no rules is ineffective or that `podSelector: {}` alone does nothing, but in Kubernetes, specifying `policyTypes` without corresponding rules triggers a default-deny for that traffic direction.

How to eliminate wrong answers

Option A is wrong because the policy has no ingress rules, so no ingress traffic is allowed based on labels; the `podSelector: {}` selects all pods, but without an `ingress` field, no traffic is permitted. Option B is wrong because the policy only specifies `Ingress` in `policyTypes`, not `Egress`, so egress traffic is not affected; a separate `Egress` policy would be needed to deny egress. Option C is wrong because the policy does have an effect: by specifying `policyTypes: [Ingress]` with no ingress rules, it defaults to denying all ingress traffic; this is a valid and intentional configuration.

Full explanation →
345
MCQmedium

A pod has been in Pending state for a long time. 'kubectl describe pod' shows the event: '0/3 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate, 2 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate.' What is the most likely cause?

A.The pod's image is incorrect
B.The kubelet on each node is not running
C.The pod has resource requests that exceed node capacity
D.The nodes are all cordoned
AnswerB

When kubelet is not running on a node, the node's heartbeat to the control plane is absent; after the node-monitor-grace-period, the Node controller marks the node NotReady and applies the node.kubernetes.io/not-ready:NoSchedule taint. Since no nodes are schedulable, the kube-scheduler cannot find a match for the pod, leaving it in Pending indefinitely. This is often the systemic cause when all nodes are unreachable or their kubelets have crashed.

Why this answer

The taints `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable` are automatically added by the node controller when a node's kubelet stops reporting its status (the `node-monitor-grace-period`, default 40s, is exceeded). Since all three nodes exhibit these taints, the kubelet is not running on any of them, preventing the node from being marked `Ready` and causing the scheduler to find no suitable node for the pod.

Exam trap

A common trap is confusing taints added automatically by the node controller (like `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable`) with taints added manually by an administrator (like `node.kubernetes.io/unschedulable` from `kubectl cordon`). In this scenario, the presence of these automatic taints on all nodes indicates that the kubelet is not running, not that nodes are cordoned.

How to eliminate wrong answers

Option A is wrong because an incorrect image would cause a `ErrImagePull` or `ImagePullBackOff` event, not a `Pending` state with taint-based scheduling failures. Option C is wrong because resource requests exceeding node capacity would produce events like `Insufficient cpu` or `Insufficient memory`, not taints related to node readiness or reachability. Option D is wrong because cordoned nodes have the `node.kubernetes.io/unschedulable:NoSchedule` taint (added by `kubectl cordon`), not the `not-ready` or `unreachable` taints; additionally, cordoning does not affect all nodes simultaneously unless explicitly done.

Full explanation →
346
MCQeasy

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

A.etcd
B.kube-controller-manager
C.kube-apiserver
D.kube-scheduler
AnswerA

etcd is a distributed, consistent, and highly available key-value store that serves as Kubernetes' backing store for all cluster data. It persistently stores the entire cluster state, including configuration data, metadata for all Kubernetes objects like Pods, Deployments, and Services, and the desired state of the system. Its robust consistency model is critical for ensuring that all control plane components operate on a single, unified source of truth.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse the kube-apiserver as the storage component because it is the primary interface for all cluster operations, but it is actually a stateless API gateway that relies entirely on etcd for persistence.

How to eliminate wrong answers

Option B (kube-controller-manager) is wrong because it runs controller loops that reconcile the current state with the desired state stored in etcd, but it does not store any data itself. Option C (kube-apiserver) is wrong because it is the front-end API gateway that validates and processes requests, but it delegates all persistent storage to etcd and does not maintain its own database. Option D (kube-scheduler) is wrong because it only assigns pods to nodes based on resource availability and policies, and it reads cluster state from the API server without storing any state or configuration.

Full explanation →
347
MCQhard

You apply a LimitRange that sets default CPU request to 0.5 and default CPU limit to 1. You create a pod without specifying any CPU resources. What are the effective CPU request and limit for the pod?

A.request: 0.5, limit: 1
B.request: 0.5, limit: 0 (no limit)
C.request: 0, limit: 0 (no defaults applied)
D.request: 1, limit: 0.5
AnswerA

The LimitRange's admission controller applies its declared default request and default limit to any Pod that omits resource requirements. Because default.cpu is 0.5 and default.limit is 1, the effective container specification becomes request: 0.5, limit: 1. This happens automatically at Pod creation, before the object is persisted, so you do not need to manually add the values to the manifest.

Why this answer

When a LimitRange is applied to a namespace, it automatically injects default resource requests and limits into pods that do not specify them. In this case, the LimitRange sets default CPU request to 0.5 and default CPU limit to 1, so the pod inherits these values. This ensures the pod is subject to resource constraints even without explicit specification.

Exam trap

The trap here is that candidates may think a pod without resource specifications will have no limits or requests, but the LimitRange admission controller automatically applies defaults, overriding the absence of explicit values.

How to eliminate wrong answers

Option B is wrong because a LimitRange default limit is applied, so the pod gets a limit of 1, not 0 (no limit). Option C is wrong because the LimitRange is active and applies defaults to pods without resource specifications, so the pod does not have zero values. Option D is wrong because it reverses the request and limit values, which does not match the LimitRange configuration.

Full explanation →
348
MCQhard

You have an Ingress resource with the following spec: spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 A client sends a request to http://example.com/api/v1/users. Which path is matched?

A./api/v1/users
B.ImplementationSpecific: depends on the Ingress controller
C./api
D.No match, returns 404
AnswerC

With pathType Prefix, the path /api matches any request URL whose path starts with /api, and matching is performed on a segment boundary; /api/v1/users begins with /api followed by the / segment, so it satisfies the rule. Prefix is the default and most common pathType for REST APIs because it allows a single rule to govern all nested resource endpoints. Thus /api is the correct path that the Ingress rule defines.

Why this answer

The Ingress rule uses `pathType: Prefix` with a path of `/api`. According to the Kubernetes Ingress specification, a Prefix pathType matches any URL path that has the specified path as its prefix. The request `/api/v1/users` starts with `/api`, so it matches the rule, and the traffic is forwarded to the `api-service` on port 80.

Exam trap

The trap here is that candidates often confuse `Prefix` with `Exact` and think the entire request path must match the specified path, leading them to incorrectly select Option A or D, or they assume `ImplementationSpecific` is the default behavior when `pathType` is explicitly set.

How to eliminate wrong answers

Option A is wrong because the path `/api/v1/users` is not the path defined in the Ingress rule; the rule matches based on the prefix `/api`, not the full request path. Option B is wrong because `ImplementationSpecific` is not the pathType used here; the spec explicitly sets `pathType: Prefix`, so the behavior is defined by the Kubernetes specification, not left to the controller. Option D is wrong because the request does match the prefix rule, so a 404 is not returned; the Ingress controller routes the request to the backend service.

Full explanation →
349
MCQhard

A cluster has multiple namespaces: 'frontend', 'backend', and 'monitoring'. A pod in the 'frontend' namespace needs to reach a Service named 'db-service' in the 'backend' namespace. The 'db-service' Service is of type ClusterIP. Which DNS name should the pod use?

A.db-service.svc.cluster.local
B.db-service
C.db-service.backend.cluster.local
D.db-service.backend.svc.cluster.local
AnswerD

db-service.backend.svc.cluster.local is the fully qualified domain name Kubernetes automatically creates for the Service named db-service in the backend namespace. Any Pod in any namespace, including frontend, can use this FQDN because it contains every component needed by CoreDNS to locate the ClusterIP. It is the canonical cross-namespace address and avoids relying on search domains or local-only short names.

Why this answer

Kubernetes DNS resolves services using the format `<service>.<namespace>.svc.cluster.local`. Since the pod is in the 'frontend' namespace and needs to reach 'db-service' in the 'backend' namespace, the fully qualified domain name (FQDN) must include the namespace and the 'svc' subdomain to be resolved by the cluster DNS (CoreDNS).

Exam trap

The trap here is that candidates often forget the 'svc' subdomain or assume that omitting the namespace works across namespaces, leading them to pick Option A or C, while the correct FQDN must include both namespace and 'svc' for reliable resolution.

How to eliminate wrong answers

Option A is wrong because it omits the namespace, so it would only resolve if the pod and service were in the same namespace; cross-namespace access requires the namespace. Option B is wrong because a bare service name without a domain suffix is only valid within the same namespace and relies on search domains, which are not guaranteed to resolve across namespaces. Option C is wrong because it uses 'backend.cluster.local' instead of 'backend.svc.cluster.local', missing the mandatory 'svc' subdomain that Kubernetes DNS expects for service records.

Full explanation →
350
Multi-Selectmedium

Which TWO of the following commands are useful for debugging network connectivity between pods?

Select 2 answers
A.kubectl top pod <pod-name>
B.kubectl run test-pod --image=busybox --rm -it -- wget -O- http://service:port
C.kubectl edit deployment <deployment-name>
D.kubectl logs <pod-name>
E.kubectl exec <pod-name> -- ping <target-ip>
AnswersB, E

kubectl run test-pod --image=busybox --rm -it -- wget -O- http://service:port launches a temporary, interactive busybox Pod that performs an HTTP request against the target Service from within the cluster network. The --rm flag ensures the Pod is deleted after the command finishes, and -it lets you see the output immediately. This is a classic debugging pattern for validating DNS resolution, Service routing, and application response without altering any existing workloads.

Why this answer

Option B is correct because running an ephemeral busybox pod with `kubectl run test-pod --image=busybox --rm -it -- wget -O- http://service:port` lets you test DNS resolution and HTTP connectivity from a separate pod to a target service, which is a standard way to isolate whether a connectivity problem is pod-specific or service-wide. Option E is correct because `kubectl exec <pod-name> -- ping <target-ip>` executes a network utility inside an existing pod, directly verifying ICMP reachability and basic IP-level connectivity between that pod and the target. Option A is not useful here because `kubectl top pod` only reports CPU and memory usage metrics, not network reachability.

Option C is not useful because `kubectl edit deployment` modifies the deployment manifest and does not test connectivity. Option D is not useful because `kubectl logs` only retrieves container stdout/stderr output and does not actively probe network paths.

Exam trap

The trap here is that candidates confuse resource monitoring (`kubectl top`) or log inspection (`kubectl logs`) with active network probing, and may overlook that `ping` uses ICMP which is often filtered, while `wget` uses TCP which is more reliable for connectivity tests.

Full explanation →
351
MCQmedium

To back up etcd, which command should be used with etcdctl?

A.etcdctl export
B.etcdctl backup
C.etcdctl dump
D.etcdctl snapshot save
AnswerD

etcdctl snapshot save is the correct and standard command for backing up an etcd cluster's data. It contacts the etcd endpoint, takes a consistent snapshot of the entire key-value store (including all keys, versions, and metadata), and writes it to a file on disk. This snapshot can then be used with etcdctl snapshot restore to recover a cluster, making it the essential backup tool for etcd-backed Kubernetes control planes.

Why this answer

The correct command to back up etcd is `etcdctl snapshot save`, which creates a point-in-time snapshot of the etcd key-value store. This is the officially recommended method for backing up etcd data in Kubernetes clusters, as it captures the entire database state consistently.

Exam trap

The trap here is that candidates may confuse `etcdctl` subcommands with similar-sounding Linux backup commands (like `dump` or `export`) or assume a generic `backup` subcommand exists, when the CKA exam specifically tests knowledge of the exact `snapshot save` syntax.

How to eliminate wrong answers

Option A is wrong because `etcdctl export` is not a valid command; the correct command for exporting data is `etcdctl snapshot save`. Option B is wrong because `etcdctl backup` is not a valid subcommand; etcdctl uses `snapshot save` for backups. Option C is wrong because `etcdctl dump` is not a valid command; the closest valid command is `etcdctl snapshot save` for backups or `etcdctl get` for retrieving specific keys.

Full explanation →
352
MCQmedium

You suspect a DNS issue inside a pod. Which command can you run to test DNS resolution from within a pod?

A.kubectl logs coredns -n kube-system
B.kubectl describe svc kubernetes
C.kubectl run test --image=busybox -- nslookup kubernetes.default
D.kubectl exec <pod-name> -- nslookup kubernetes.default
AnswerD

`kubectl exec <pod-name> -- nslookup kubernetes.default` runs the `nslookup` binary directly inside the target pod's network namespace. This uses the pod's own `/etc/resolv.conf`, including its `nameserver` (typically the kube-dns ClusterIP) and search domains (such as `default.svc.cluster.local`), to perform a real DNS query. It is the most direct way to verify that the pod can resolve a service name, because it replicates exactly what an application in that pod would experience.

Why this answer

The correct command is `kubectl exec <pod-name> -- nslookup kubernetes.default`, which runs the DNS lookup from inside the existing pod's network namespace, using the pod's own /etc/resolv.conf and DNS policy. This directly tests whether the pod can resolve cluster DNS names through kube-dns/CoreDNS, which is exactly what a DNS issue inside a pod requires. Running nslookup from within the affected pod isolates the problem to that pod's DNS configuration rather than the cluster DNS service as a whole.

Exam trap

CKA often tests whether candidates confuse observing DNS components (logs, Service descriptions) with actually exercising name resolution from the affected pod's network namespace.

How to eliminate wrong answers

Option A is wrong because `kubectl logs coredns -n kube-system` only shows CoreDNS server logs; it does not test resolution from the pod's perspective and may show no errors even when the pod's resolv.conf is misconfigured. Option B is wrong because `kubectl describe svc kubernetes` only displays the Service object's endpoints and metadata; it does not perform any DNS query or validate name resolution. Option C is wrong because `kubectl run test --image=busybox -- nslookup kubernetes.default` creates a brand-new pod with its own default DNS configuration, so it tests cluster DNS generally but not the suspect pod's DNS behavior.

Full explanation →
353
MCQhard

A pod is running but cannot be accessed via its ClusterIP service from another pod in the same namespace. The service endpoints list shows the pod's IP. What is the most likely cause?

A.The kube-proxy is not running on the node
B.A NetworkPolicy is blocking the traffic
C.The service's targetPort is incorrect
D.The pod is running on a different node without proper routing
AnswerB

NetworkPolicy is a namespace-scoped firewall that can restrict egress traffic from a specific pod (via podSelector) to a destination service's backing pod IP or CIDR. Even if the Service object and endpoints are intact, a NetworkPolicy denying egress from the source pod to the backend pod's IP or port will silently drop the packets, making the Service unreachable only for the affected pod(s).

Why this answer

A NetworkPolicy can explicitly deny ingress traffic to a pod even when the service endpoints are correctly populated. Since the endpoints list shows the pod's IP, the service and pod are communicating at the network layer, but a NetworkPolicy with an ingress rule that does not allow traffic from the source pod's labels or CIDR will cause the packet to be dropped by the node's iptables or eBPF rules, resulting in a connection timeout or reset from the client pod.

Exam trap

The trap here is that candidates assume a populated endpoints list guarantees connectivity, but they overlook that NetworkPolicies operate at a lower layer (L3/L4) and can block traffic even when the service and pod are correctly configured.

Why the other options are wrong

A

kube-proxy issues would affect all services cluster-wide, not just one service with correct endpoints.

C

If targetPort were wrong, endpoints might still show but traffic would not reach the container; but endpoints are based on the container port, so if endpoints exist, targetPort matches.

D

ClusterIP services work across nodes; no extra routing needed.

Full explanation →
354
MCQeasy

You have a Deployment named 'web-app' in the 'default' namespace. You run the following command: kubectl rollout history deployment web-app. The output shows: revision 1, revision 2, revision 3. You want to roll back to revision 1. Which command achieves this?

A.kubectl rollout undo deployment web-app --revision=1
B.kubectl rollout undo deployment web-app --to-revision=1
C.kubectl rollback deployment web-app --to-revision=1
D.kubectl rollout undo deployment web-app
AnswerB

This is the correct command to revert the `web-app` Deployment to exactly revision 1. The `--to-revision=1` flag explicitly selects the first recorded revision from the rollout history, forcing Kubernetes to restore that revision's pod template spec. All later changes—such as image updates, environment variable modifications, or container command changes—are discarded, and the Deployment will scale down the current ReplicaSet and scale up the ReplicaSet corresponding to revision 1.

Why this answer

`kubectl rollout undo` with the `--to-revision` flag is the proper syntax to roll back a Deployment to a specific revision. The command `kubectl rollout undo deployment web-app --to-revision=1` reverts the Deployment to revision 1, as shown in the rollout history output.

Exam trap

The trap here is that candidates confuse the `--revision` flag (used with `kubectl rollout history`) with the `--to-revision` flag required for `kubectl rollout undo`, or they mistakenly think `kubectl rollback` is a valid command.

How to eliminate wrong answers

Option A is wrong because `kubectl rollout undo` does not accept a `--revision` flag; the correct flag is `--to-revision`. Option C is wrong because `kubectl rollback` is not a valid kubectl command; the correct command is `kubectl rollout undo`. Option D is wrong because it rolls back to the previous revision (revision 2), not to revision 1, as it omits the `--to-revision` flag.

Full explanation →
355
MCQhard

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?

A.The nodes have insufficient resources
B.The pod has a requiredDuringSchedulingIgnoredDuringExecution anti-affinity rule that is too restrictive
C.The pod has a taint tolerance issue
D.The nodes are all cordoned
AnswerB

A requiredDuringSchedulingIgnoredDuringExecution anti-affinity rule is a hard constraint: the scheduler will only place the pod on a node that satisfies every term of the rule. If the rule's label selector and topologyKey match labels on pods running on every available node, no node passes the check. The resulting event is '0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules,' and the pod stays Pending until a node no longer runs a conflicting pod or the rule is updated. This is the only option where the pod's own scheduling constraints, not cluster conditions, make all nodes ineligible.

Why this answer

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.

Exam trap

CNCF often tests the distinction between hard and soft scheduling constraints; the trap here is that candidates may confuse anti-affinity errors with resource insufficiency or taint issues, but the specific event message directly points to anti-affinity rules.

How to eliminate wrong answers

Option A is wrong because insufficient resources would produce events like 'Insufficient cpu' or 'Insufficient memory', not a message about anti-affinity rules. Option C is wrong because taint/toleration issues generate events such as 'node(s) had taints that the pod didn't tolerate', not anti-affinity mismatches. Option D is wrong because cordoned nodes produce events like 'node(s) were cordoned' or 'node(s) were unschedulable', not a message about pod anti-affinity rules.

Full explanation →
356
MCQmedium

A pod is stuck in 'Pending' state. Which command would you run FIRST to diagnose the issue?

A.kubectl logs <pod-name>
B.kubectl describe pod <pod-name>
C.kubectl top pod <pod-name>
D.kubectl exec -it <pod-name> -- sh
AnswerB

kubectl describe pod <pod-name> is the correct diagnostic command because it aggregates the pod's object metadata, current status, conditions, and most importantly, recent Events from the API server, scheduler, and kubelet. For a Pending pod, the Events section reveals whether the scheduler failed due to insufficient resources, taints/tolerations, node selector mismatches, or whether a PersistentVolume claim is awaiting binding — the precise reason for the stuck state.

Why this answer

A pod stuck in 'Pending' state means it has not been scheduled to a node yet. The `kubectl describe pod` command provides detailed event logs, scheduler decisions, and resource constraints (e.g., insufficient CPU/memory, persistent volume claims not bound, node selector mismatches) that reveal why scheduling failed. This is the first diagnostic step because it surfaces the root cause without requiring the pod to be running.

Exam trap

The trap here is that candidates often jump to `kubectl logs` or `kubectl exec` out of habit, forgetting that these commands only work for running pods, while 'Pending' indicates a pre-scheduling failure that requires inspecting events and conditions via `kubectl describe`.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` retrieves container logs, but a pod in 'Pending' has no running containers yet, so there are no logs to fetch. Option C is wrong because `kubectl top pod` shows real-time resource usage metrics, which require the pod to be running on a node; a pending pod has no metrics. Option D is wrong because `kubectl exec` requires a running container to execute commands, which is impossible when the pod is still pending.

Full explanation →
357
MCQmedium

A node has been cordoned. Which statement about the node is true?

A.All pods on the node are immediately terminated
B.The kubelet on the node is stopped
C.The node is removed from the cluster
D.The node is marked as unschedulable, but existing pods continue to run
AnswerD

The correct effect of cordoning is to mark the node as unschedulable by setting `spec.unschedulable: true`, which tells the scheduler to avoid placing any new pods on it. However, the pods that are already scheduled and running are unaffected and continue their lifecycle normally until they finish, are evicted, or are explicitly deleted. This is why cordon is the preferred first step before a node drain: it prevents new workloads while letting existing ones remain available during maintenance preparation.

Why this answer

When a node is cordoned using `kubectl cordon <node>`, it is marked as unschedulable by setting the `spec.unschedulable` field to `true`. This prevents new pods from being scheduled onto the node, but existing pods continue to run normally. The kubelet remains active, and the node stays in the cluster.

Exam trap

The trap here is confusing `cordon` with `drain` — candidates often think cordoning also evicts pods, but it only prevents new scheduling, leaving existing pods untouched.

How to eliminate wrong answers

Option A is wrong because cordoning does not terminate pods; only `kubectl drain` evicts or deletes pods. Option B is wrong because the kubelet continues to run and manage existing pods; cordoning only affects the scheduler. Option C is wrong because the node remains a member of the cluster and is still visible via `kubectl get nodes`; it is not removed.

Full explanation →
358
Multi-Selecthard

Which three components are part of the Gateway API? (Choose three.)

Select 3 answers
A.Ingress
B.GatewayClass
C.Gateway
D.HTTPRoute
E.Service
AnswersB, C, D

GatewayClass is one of the three core Gateway API resources and serves as a cluster-scoped template that defines a named class of gateways. It references a controller that manages gateways of that class and can include parameters for customization, similar to StorageClass in the storage API. By grouping gateways into classes, it enables different implementations (e.g., different load balancers) to be used transparently within the same cluster. Thus, GatewayClass is correct because it is a fundamental building block for defining gateway behavior.

Why this answer

The Gateway API defines three core resource types: GatewayClass, Gateway, and HTTPRoute (along with other route types like TCPRoute and TLSRoute). Option B, GatewayClass, is correct because it is a cluster-scoped resource that identifies the controller implementing the Gateway API and defines the class of gateways available. Option C, Gateway, is correct because it represents an instance of a gateway that provisions the underlying load balancer or proxy and defines listeners for traffic.

Option D, HTTPRoute, is correct because it is a route resource that attaches to a Gateway and specifies how HTTP traffic is matched and forwarded to backend Services. Option A, Ingress, is not part of the Gateway API; it is a separate, older Kubernetes API for HTTP routing. Option E, Service, is a core Kubernetes resource used as a backend target, not a component of the Gateway API itself.

Exam trap

The CKA exam often tests the distinction between the older Ingress API and the newer Gateway API, where candidates mistakenly think Ingress is a component of the Gateway API, but Ingress is a separate, standalone resource.

Full explanation →
359
MCQmedium

A container requests 256Mi memory and has a limit of 512Mi. The container tries to allocate 600Mi. What happens?

A.The container is allowed to use up to 600Mi if the node has free memory
B.The kernel throttles the container's memory usage
C.The container is killed with OOMKilled and restarted
D.The container is evicted from the node
AnswerC

When a container exceeds its 512Mi memory limit, the kernel's OOM killer terminates the process, resulting in an OOMKilled status. Because the default restartPolicy for Pods is Always, the kubelet will automatically restart the container in an attempt to restore the application's availability.

Why this answer

The container's memory limit is 512Mi, and it attempts to allocate 600Mi, which exceeds the limit. Kubernetes enforces memory limits via cgroups; when a container exceeds its memory limit, the kernel's OOM killer terminates the process, resulting in an OOMKilled status. The container will then be restarted according to its restart policy (e.g., Always).

Exam trap

The trap here is confusing memory limits with node-level memory pressure or CPU throttling, leading candidates to think the container can burst beyond its limit if node memory is available, or that memory usage is throttled like CPU.

How to eliminate wrong answers

Option A is wrong because the container is not allowed to exceed its memory limit (512Mi) even if the node has free memory; Kubernetes enforces the limit via cgroups, not node availability. Option B is wrong because memory throttling (e.g., via CPU cfs quota) applies to CPU, not memory; exceeding the memory limit triggers an OOM kill, not throttling. Option D is wrong because eviction occurs when the node is under memory pressure and the pod exceeds its request, not when a single container exceeds its limit; the container is killed and restarted in place, not evicted from the node.

Full explanation →
360
Multi-Selecteasy

Which TWO of the following are valid reasons to use a Headless Service?

Select 2 answers
A.To provide a single stable IP address for the service.
B.To expose a service externally via a cloud load balancer.
C.To enable a client to discover all pod IPs for a StatefulSet.
D.To enable DNS to return individual pod IPs for stateful applications.
E.To provide load-balanced access to a set of pods.
AnswersC, D

When a StatefulSet creates pods, a headless service provides a stable DNS name for each pod (e.g., podname.servicename.namespace.svc.cluster.local) and also allows the service's own DNS name to return a list of A records for all matching pod IPs. Clients can then obtain the entire set of pod addresses directly, which is exactly what stateful peers need to discover one another and join the cluster without a proxy.

Why this answer

A Headless Service (with `clusterIP: None`) does not provide a single stable IP or load balancing. Instead, it returns DNS A/AAAA records for all pod IPs that match the service's selector. This is essential for StatefulSets, where each pod has a unique identity and clients need to discover and connect to specific pods directly, such as in a database cluster.

Exam trap

The trap here is that candidates confuse a Headless Service's DNS-based pod discovery with load balancing or external exposure, when in fact it is designed to give clients direct access to individual pod IPs for stateful workloads.

Full explanation →
361
MCQmedium

What is the purpose of 'kubeadm reset'?

A.To restart the Kubernetes services on a node.
B.To reinitialize the cluster with new configuration.
C.To remove the node from the cluster and clean up.
D.To rollback the last upgrade.
AnswerC

This command is designed to revert the changes made to a host by kubeadm init or kubeadm join. It stops the kubelet, removes local static pod manifests, deletes the /etc/kubernetes configuration directory, and cleans up local state. This prepares the machine to either be safely decommissioned or rejoined to a cluster.

Why this answer

`kubeadm reset` is designed to revert any changes made by `kubeadm init` or `kubeadm join` on a node, effectively cleaning up the node's local state (e.g., removing CNI configurations, etcd member data, and kubelet certificates) so it can be safely removed from the cluster or reinitialized. Option C correctly identifies this as removing the node from the cluster and cleaning up, which is the primary purpose of the command.

Exam trap

CNCF often tests the misconception that `kubeadm reset` is a general-purpose reset or rollback tool, when in fact it is a destructive cleanup command that only prepares a node for re-joining or re-initialization, not for reverting cluster-wide changes or upgrades.

How to eliminate wrong answers

Option A is wrong because `kubeadm reset` does not restart Kubernetes services; it tears down and cleans up the node, whereas `systemctl restart kubelet` or `kubeadm upgrade` commands handle service restarts. Option B is wrong because `kubeadm reset` does not reinitialize the cluster with new configuration; it only cleans up the current state, and reinitialization would require running `kubeadm init` again with a new config. Option D is wrong because `kubeadm reset` is not a rollback mechanism for upgrades; `kubeadm upgrade` has its own rollback procedures (e.g., `kubeadm upgrade apply --etcd-upgrade=false` or manual etcd snapshot restore), and `reset` simply destroys the node's Kubernetes artifacts without preserving upgrade history.

Full explanation →
362
Multi-Selectmedium

Which TWO commands can be used to view the configuration of a kubeconfig file?

Select 2 answers
A.kubectl describe configmap kubeconfig
B.kubectl config set-context
C.kubectl config current-context
D.kubectl config get-contexts
E.kubectl config view
AnswersD, E

kubectl config get-contexts returns a table of all contexts defined in the kubeconfig, listing each context's name, cluster, authinfo, and namespace (along with a marker for the current context). This is a read-only command that directly satisfies the requirement to view context configuration, making it a correct choice.

Why this answer

Option E, `kubectl config view`, is correct because it prints the merged kubeconfig settings (clusters, contexts, users, and current-context) from the kubeconfig file, optionally with `--minify` or `--raw`. Option D, `kubectl config get-contexts`, is correct because it lists the contexts defined in the kubeconfig, showing NAME, CLUSTER, AUTHINFO, and NAMESPACE, which is a way to view part of the configuration. Option A is wrong because a kubeconfig is a client-side file, not a ConfigMap object, so `kubectl describe configmap kubeconfig` would only work if such a ConfigMap existed in the cluster.

Option B is wrong because `kubectl config set-context` modifies a context rather than displaying configuration. Option C is wrong because `kubectl config current-context` only displays the name of the active context, not the configuration itself.

Exam trap

The trap here is that candidates may confuse commands that modify the kubeconfig (like `set-context`) with commands that display it, or mistakenly think `current-context` shows the full configuration when it only shows the active context name.

Full explanation →
363
MCQmedium

An Ingress resource is created with the following spec: spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 The backend service 'api-service' is in the same namespace as the Ingress. What must be true for the Ingress to route traffic to the service?

A.The Ingress controller must be configured to use the NodePort of the service.
B.The service 'api-service' must be of type NodePort.
C.The service 'api-service' must have a valid ClusterIP and at least one endpoint.
D.The Ingress must have an IngressClass annotation.
AnswerC

Ingress routing resolves the backend through the Service, so the Service needs a valid ClusterIP and at least one ready endpoint. Without endpoints, kube-proxy has no pod to forward to and requests fail, regardless of correct Ingress path and host configuration.

Why this answer

For an Ingress to route traffic to a backend service, the service must have a valid ClusterIP (so the Ingress controller can reach it via the cluster network) and at least one healthy endpoint (i.e., pods matching the service’s selector must be running and ready). The Ingress controller forwards traffic to the service’s ClusterIP on the specified port, not directly to pods, so a ClusterIP and endpoints are essential.

Exam trap

The trap here is that candidates often assume Ingress requires a NodePort or LoadBalancer service type, but in reality, Ingress works with any service type that has a ClusterIP (including ClusterIP, NodePort, and LoadBalancer), and the critical requirement is that the service has a reachable ClusterIP and at least one ready endpoint.

How to eliminate wrong answers

Option A is wrong because the Ingress controller does not require NodePort of the service; it uses the service’s ClusterIP and port, not the node port. Option B is wrong because the service does not need to be of type NodePort; Ingress works with ClusterIP services (the default type) as long as the service has a ClusterIP and endpoints. Option D is wrong because while an IngressClass annotation may be needed in some setups (e.g., multiple controllers), it is not universally required; the question does not specify a multi-controller environment, and the Ingress can work without it if a default IngressClass is defined or the controller is configured to watch all Ingresses.

Full explanation →
364
MCQmedium

You deploy a pod with image 'nginx:1.21'. It stays in ImagePullBackOff. You run 'kubectl describe pod nginx-pod' and see the event: 'Failed to pull image "nginx:1.21": rpc error: code = Unknown desc = Error response from daemon: manifest for nginx:1.21 not found'. What is the most likely fix?

A.Use a different container runtime
B.Add imagePullSecrets to the pod
C.Restart the kubelet on the node
D.Change the image tag to a valid one, e.g., nginx:1.21.6
AnswerD

The tag `nginx:1.21` does not exist in the Docker Hub repository; valid tags for the 1.21 series include specific patch versions like `1.21.6`. Changing the image reference to a known valid tag allows the runtime to pull the correct manifest and start the container, resolving the ImagePullBackOff. Always verify available tags in the registry when encountering pull errors.

Why this answer

The tag '1.21' does not exist in the registry. Use a valid tag like '1.21.6' or 'latest'.

Full explanation →
365
MCQmedium

Refer to the exhibit. An administrator creates a token with TTL 0. What is the effect on the token?

A.The token will never expire.
B.The token will expire after the default TTL.
C.The token expires immediately.
D.The token is invalid and cannot be used.
AnswerA

When a token is created with a TTL (time-to-live) value of 0, Kubernetes treats that as an explicit request to disable expiration. The resulting token contains no `exp` claim or has an `exp` value far in the future, so the API server will not reject it based on time. It remains valid indefinitely until manually revoked, for example by deleting the Secret or Service Account.

Why this answer

Setting TTL to 0 means the token never expires (unless manually deleted). It will persist indefinitely.

Full explanation →
366
MCQmedium

You want to forward local port 8080 to port 80 of a pod named 'nginx-pod'. Which command should you use?

A.kubectl proxy pod/nginx-pod 8080:80
B.kubectl port-forward pod/nginx-pod 8080:80
C.kubectl forward pod/nginx-pod 8080 80
D.kubectl port-forward service/nginx-pod 8080:80
AnswerB

This is the correct command and syntax for forwarding traffic from a local port to a pod. The `kubectl port-forward` subcommand targets the `pod/nginx-pod` resource and maps local port 8080 to the container's port 80, establishing a secure tunnel via the API server.

Why this answer

`kubectl port-forward` is the Kubernetes command used to forward a local port to a port on a specific pod. The syntax `kubectl port-forward pod/nginx-pod 8080:80` correctly specifies the pod resource, the local port (8080), and the target pod port (80), enabling access to the pod's port 80 from the local machine.

Exam trap

The trap here is that candidates often confuse `kubectl port-forward` with `kubectl proxy` or misremember the syntax, leading them to choose a non-existent command like `kubectl forward` or incorrectly assume that a service must always be used for port forwarding.

How to eliminate wrong answers

Option A is wrong because `kubectl proxy` is used to create a proxy server to the Kubernetes API server, not to forward ports to a specific pod; it does not accept a pod resource type or port mapping syntax. Option C is wrong because `kubectl forward` is not a valid kubectl command; the correct command is `kubectl port-forward`. Option D is wrong because it forwards to a service (`service/nginx-pod`) rather than a pod; while `kubectl port-forward` can target services, the question explicitly asks for forwarding to a pod named 'nginx-pod', and the service name may not match the pod name, making this option incorrect for the given scenario.

Full explanation →
367
Multi-Selectmedium

Which TWO statements about Headless services are correct? (Select TWO)

Select 2 answers
A.A headless service assigns a ClusterIP to the service
B.Headless services provide round-robin load balancing across pods
C.Headless services require a selector that matches at least one pod
D.DNS queries for a headless service return the IP addresses of the backing pods
E.A headless service is created by setting clusterIP to None
AnswersD, E

For a headless service with a selector, Kubernetes still creates an Endpoints object listing the IPs of all pods that match the selector, but it does not expose those IPs behind a ClusterIP. Instead, DNS A/AAAA records for the service name resolve directly to those individual pod IPs, so a query returns one or more pod addresses depending on how many endpoints exist. This is the core mechanism that enables stateful applications, such as databases, to discover and connect to specific pod instances rather than a load-balanced virtual IP.

Why this answer

Option E is correct because a headless service is defined by explicitly setting the spec.clusterIP field to "None" in the Service manifest, which tells Kubernetes not to allocate a virtual IP. Option D is correct because, with no ClusterIP, kube-dns/CoreDNS resolves the service name directly to the individual pod IPs (A/AAAA records) of the endpoints rather than to a single service VIP. Options A and B are wrong because a headless service has no ClusterIP and therefore no kube-proxy VIP-based round-robin load balancing; clients connect directly to pod IPs.

Option C is wrong because a headless service does not strictly require a selector — a selectorless headless service is valid and is commonly used with manually managed Endpoints or EndpointSlices.

Exam trap

The trap here is that candidates often confuse headless services with regular ClusterIP services, assuming they still get a ClusterIP or that they provide built-in load balancing, when in fact headless services are designed for direct pod addressing without proxying.

Full explanation →
368
MCQmedium

A pod uses a PVC with access mode RWO. The pod is scheduled on node A. You want to schedule another pod on node B that uses the same PVC. What will happen?

A.The second pod will be stuck in ContainerCreating state until the first pod releases the volume
B.Both pods will mount the volume and share it without issues
C.The second pod will successfully mount the volume as read-only
D.The first pod will be evicted to allow the second pod to use the volume
AnswerA

When a PersistentVolume is bound using ReadWriteOnce (RWO), it can only be mounted by a single node at any given time. If a second pod is scheduled to a different node and attempts to use the same PVC, the volume attachment controller will block the attachment to prevent data corruption. Consequently, the second pod remains stuck in the ContainerCreating state, generating Multi-Attach error events until the first pod is deleted and the volume is fully detached from its node.

Why this answer

A PVC with access mode RWO (ReadWriteOnce) can only be mounted as a block device or filesystem by a single node at a time. When the first pod on node A has the volume attached, the second pod on node B cannot attach the same volume because the underlying storage (e.g., an AWS EBS volume or GCE Persistent Disk) does not support multi-node attachment. The second pod will remain in ContainerCreating state with a 'Multi-Attach error' until the first pod releases the volume (e.g., by being deleted or rescheduled).

Exam trap

The trap here is that candidates confuse access modes with pod-level permissions, assuming 'ReadWriteOnce' means the volume can be mounted by multiple pods as long as they are on the same node, or that the second pod will mount as read-only, when in fact the restriction is node-based and enforced at the storage layer.

How to eliminate wrong answers

Option B is wrong because RWO explicitly restricts the volume to a single node; both pods cannot mount and share the volume simultaneously. Option C is wrong because RWO does not imply read-only access; the second pod would still fail to attach the volume at all, regardless of the mount mode. Option D is wrong because Kubernetes does not evict the first pod to free the volume for the second pod; the scheduler will simply not schedule the second pod on a different node if the volume is already attached, or the pod will hang in ContainerCreating.

Full explanation →
369
MCQeasy

Which component is responsible for managing the network rules and forwarding on each node?

A.container runtime
B.kubelet
C.kube-proxy
D.kube-scheduler
AnswerC

kube-proxy runs as a DaemonSet on every node and watches the Kubernetes API server for updates to Service and EndpointSlice objects. It is the component that manages network rules for Services by writing entries into iptables or IPVS, which then perform DNAT, load balancing, and connection forwarding to backend Pods. Without kube-proxy, or an equivalent replacement, ClusterIP and NodePort Services would not have the kernel rules necessary to route Service traffic.

Why this answer

kube-proxy is the component responsible for managing network rules and forwarding traffic on each node. It implements the Kubernetes Service concept by maintaining iptables or IPVS rules that route packets to the correct backend pods, handling load balancing and service discovery at the network layer.

Exam trap

CNCF often tests the misconception that kubelet handles networking, but kubelet only manages pod lifecycle and container runtime interactions, not network rule management.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is only responsible for pulling images and running containers, not for managing network rules or packet forwarding. Option B is wrong because the kubelet is the primary node agent that registers the node with the API server and manages pod lifecycle, but it does not handle network rule management or forwarding. Option D is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints, and it has no role in network traffic forwarding.

Full explanation →
370
MCQeasy

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

A.etcdctl endpoint status
B.etcdctl snapshot restore /backup/snapshot.db
C.etcdctl snapshot save /backup/snapshot.db
D.etcdctl member list
AnswerC

This is the correct command to capture a point-in-time backup of the active etcd keyspace and write it to a specified file path. When executed with the appropriate TLS certificates and endpoints, it securely streams the database state into a single compressed snapshot file suitable for disaster recovery.

Why this answer

`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.

Exam trap

The trap here is that candidates confuse the `save` and `restore` subcommands, often selecting `snapshot restore` (Option B) because they think 'backup' implies 'restore', but `save` is the correct verb for creating a backup.

How to eliminate wrong answers

Option A is wrong because `etcdctl endpoint status` only returns health and version information about the etcd endpoints, not a backup of the data. Option B is wrong because `etcdctl snapshot restore` is used to restore a previously saved snapshot, not to create a new backup. Option D is wrong because `etcdctl member list` lists the members of the etcd cluster and their status, which is unrelated to creating a data backup.

Full explanation →
371
MCQmedium

A Node is in NotReady state. Which action should be taken first to diagnose the issue?

A.kubectl describe node <node>
B.Check kubelet logs on the node
C.Restart kubelet
D.Check API server logs
AnswerA

kubectl describe node <node> is the correct first diagnostic because it displays the Node object's Status.Conditions (Ready, MemoryPressure, DiskPressure, PIDPressure, NetworkUnavailable) and a rolling list of recent Events that record taints, kubelet restarts, and CNI failures. This single command aggregates the node's current condition, capacity, allocatable resources, and the kubelet's reported heartbeats from the control plane, letting you immediately see which signal flipped the node to NotReady without requiring SSH access to the node.

Why this answer

When a node is in NotReady state, the first diagnostic step is to gather information about the node's current status, conditions, and recent events using `kubectl describe node <node>`. This command reveals the node's conditions (e.g., Ready, DiskPressure, MemoryPressure), the last heartbeat timestamp, and any relevant events that may indicate the root cause, such as network issues or kubelet failures. It provides a high-level overview without requiring direct node access, making it the most efficient initial action.

Exam trap

The trap here is that candidates often jump to checking kubelet logs or restarting the kubelet, forgetting that `kubectl describe node` provides immediate visibility into node conditions and events from the control plane, which is the standard first step in the Kubernetes troubleshooting workflow.

Why the other options are wrong

B

Useful but not the first step; describe node gives overview.

C

Recovery action, not diagnosis.

D

Unlikely to show node conditions.

Full explanation →
372
MCQmedium

You have a NetworkPolicy that selects pods with label 'role: db' in the 'default' namespace. The policy has no ingress rules defined. What is the effect on traffic to the selected pods?

A.Only traffic from pods with label 'role: frontend' is allowed
B.Both ingress and egress traffic are denied
C.All ingress traffic is denied
D.All ingress traffic is allowed
AnswerC

This is the correct behavior because applying a NetworkPolicy to a pod transitions it into an isolated state for ingress. Since the policy selects the target pods but contains no ingress rules to explicitly permit traffic, Kubernetes defaults to a deny-all stance for all incoming connections.

Why this answer

A NetworkPolicy with no ingress rules defaults to denying all ingress traffic to the selected pods. This is because Kubernetes NetworkPolicies are whitelist-based: if no ingress rules are specified, the policy implicitly denies all incoming traffic, even if other policies allow it. The selected pods with label 'role: db' will therefore receive no ingress traffic.

Exam trap

The trap here is that candidates often assume a NetworkPolicy with no rules allows all traffic, but Kubernetes defaults to deny for ingress when a policy selects the pod, making 'All ingress traffic is allowed' a common mistake.

How to eliminate wrong answers

Option A is wrong because the policy has no ingress rules, so it does not allow traffic from any specific source, including pods with label 'role: frontend'. Option B is wrong because the policy only affects ingress traffic; egress traffic is not denied unless an egress rule is explicitly defined. Option D is wrong because the absence of ingress rules results in all ingress traffic being denied, not allowed.

Full explanation →
373
Multi-Selectmedium

Which THREE of the following are valid steps to troubleshoot DNS issues in a Kubernetes cluster?

Select 3 answers
A.Run 'kubectl exec <pod> -- nslookup kubernetes.default'
B.Check the /etc/resolv.conf on the host
C.Restart all nodes in the cluster
D.Verify the kube-dns Service has endpoints
E.Check the logs of the CoreDNS pods
AnswersA, D, E

Running `kubectl exec <pod> -- nslookup kubernetes.default` is a valid troubleshooting step because it tests DNS resolution from inside the pod's network namespace, exactly where application failures occur. If this command fails, it confirms the issue is with DNS resolution rather than with the application itself. It uses the pod's configured DNS settings (resolv.conf and search domains) to query the cluster's DNS service. Success indicates the cluster DNS is reachable and resolving service names, while failure isolates the problem to DNS configuration or CoreDNS.

Why this answer

To troubleshoot DNS, you can check the DNS pod logs, test resolution from a pod, and verify the DNS service endpoints.

Full explanation →
374
MCQmedium

Which of the following is a correct Ingress resource snippet that routes traffic to service 'web-svc' on port 80 for the host 'example.com'?

A.spec: rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: web-svc port: number: 80
B.spec: rules: - http: paths: - backend: service: name: web-svc port: number: 80
C.spec: rules: - host: example.com http: paths: - backend: serviceName: web-svc servicePort: 80
D.spec: rules: - host: example.com backend: serviceName: web-svc servicePort: 80
AnswerA

This snippet correctly adheres to the networking.k8s.io/v1 Ingress API specification. It properly defines a routing rule under spec.rules with a designated host, an http routing block, and a path list containing the required path, pathType (set to Prefix), and a nested backend.service configuration specifying both name and port.number.

Why this answer

It follows the exact structure required by the Kubernetes Ingress v1 API (networking.k8s.io/v1). It specifies the host `example.com`, defines an HTTP rule with a path of `/` and `pathType: Prefix`, and correctly references the backend service `web-svc` on port 80 using the `service.name` and `port.number` fields. This configuration ensures that traffic for `example.com` is routed to the target service.

Exam trap

The trap here is that candidates often confuse the deprecated `extensions/v1beta1` API syntax (using `serviceName` and `servicePort`) with the current `networking.k8s.io/v1` API syntax (using `service.name` and `port.number`), leading them to select option C.

How to eliminate wrong answers

Option B is wrong because it omits the `host` field, which means the rule would match all hosts, not just `example.com`, and fails to meet the requirement of routing traffic specifically for `example.com`. Option C is wrong because it uses the deprecated `serviceName` and `servicePort` fields from the older `extensions/v1beta1` API; the correct Ingress v1 API requires `service.name` and `port.number`. Option D is wrong because it places the `backend` block directly under the `rules` entry instead of under `http.paths`, which is an invalid structure; the backend must be nested within a path definition.

Full explanation →
375
MCQhard

You have a Service with endpoints for pods in different zones. You want kube-proxy to use a mode that provides better performance for large clusters and supports scheduling algorithms like least-connection. Which mode should you use?

A.userspace mode
B.ipvs mode
C.iptables mode
D.kernelspace mode
AnswerB

IPVS (IP Virtual Server) mode operates in the Linux kernel space and utilizes hash tables, allowing it to scale efficiently to thousands of services. It supports advanced load-balancing algorithms, such as round-robin, least connection, and destination hashing, which are crucial for optimizing traffic distribution across different zones.

Why this answer

IPVS (IP Virtual Server) mode is correct because it uses the LVS (Linux Virtual Server) kernel module to provide a transport-layer load balancer that supports multiple scheduling algorithms, including least-connection (lc), round-robin (rr), and source hashing (sh). Unlike iptables, IPVS uses a hash table as the underlying data structure, which scales linearly with the number of services and endpoints, making it far more performant in large clusters with thousands of services.

Exam trap

The trap here is that candidates often assume iptables mode is the best for performance because it is the default, but they overlook that IPVS is specifically designed for high-performance load balancing with advanced scheduling algorithms, while iptables mode only supports random selection and suffers from linear rule traversal in large clusters.

How to eliminate wrong answers

Option A is wrong because userspace mode runs kube-proxy in user space, proxying traffic through a userspace program, which incurs high overhead due to context switching and copying data between kernel and user space, and does not support advanced scheduling algorithms like least-connection. Option C is wrong because iptables mode uses a chain of iptables rules that are evaluated sequentially for every packet, leading to O(n) lookup time and poor performance in large clusters with many services; it also only supports random selection (via statistic module) and does not natively support least-connection scheduling. Option D is wrong because kernelspace mode is not a valid kube-proxy mode; the three supported modes are userspace, iptables, and IPVS.

Full explanation →
Page 4

Page 5 of 10

Page 6

All pages

12345678910

Practice CKA by domain

Target a specific domain to shore up weak areas.

TroubleshootingCluster Architecture, Installation and ConfigurationServices and NetworkingWorkloads and SchedulingStorageCluster Architecture, Installation & ConfigurationWorkloads & SchedulingServices & Networking
See all domains with question counts →