Certified Kubernetes Administrator CKA CKA Questions 451–525 | Page 7/10

451

MCQmedium

A pod is stuck in 'Pending' state. You run 'kubectl describe pod mypod' and see: '0/4 nodes are available: 4 node(s) didn't match pod anti-affinity constraints'. What does this mean?

A.The pod has a taint that no node tolerates.

B.The pod has a node selector that doesn't match any node.

C.The pod's anti-affinity rule conflicts with all existing pods on every node.

D.The cluster is out of resources.

AnswerC

Pod anti-affinity enforces that a pod cannot share a topology domain with other pods that match a specified label selector. If the pod's `requiredDuringSchedulingIgnoredDuringExecution` anti-affinity rule targets pods that appear on every node within the cluster, then each node is disqualified and the scheduler reports something like `0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules.` This exactly matches the described output, confirming the conflict with existing pods is the cause of the Pending state.

Why this answer

The error message '4 node(s) didn't match pod anti-affinity constraints' directly indicates that the pod's anti-affinity rule (defined in the pod spec under `affinity.podAntiAffinity`) prevents it from being scheduled on any node because the rule conflicts with the labels of existing pods on all nodes. Anti-affinity ensures the pod is not co-located with certain pods, and if every node already hosts a pod matching the anti-affinity selector, no node is eligible. This is distinct from taints, node selectors, or resource shortages.

Exam trap

The CKA exam often tests the distinction between anti-affinity, taints/tolerations, and node selectors; the trap here is that candidates misread 'anti-affinity constraints' as a generic scheduling failure and incorrectly choose resource exhaustion or taints.

How to eliminate wrong answers

Option A is wrong because taints and tolerations produce a message like 'node(s) had taints that the pod didn't tolerate', not an anti-affinity constraint error. Option B is wrong because a node selector mismatch yields 'node(s) didn't match node selector', not anti-affinity. Option D is wrong because resource exhaustion shows messages like 'Insufficient cpu' or 'Insufficient memory', not a constraint-based failure.

Full explanation →

452

MCQmedium

You want to check the logs of a container that previously crashed. Which command should you use?

A.kubectl logs --previous <pod-name>

B.kubectl logs <pod-name>

C.kubectl exec <pod-name> -- cat /var/log/app.log

D.kubectl describe pod <pod-name>

AnswerA

The `--previous` flag instructs kubectl to retrieve the logs of the last terminated container instance within the pod. When a container has crashed and restarted, the current container's logs are empty or show only new output, while the terminated container's logs remain accessible via this flag. This is the correct way to diagnose why the previous container failed, as it directly fetches the stdout/stderr stream from that dead instance.

Why this answer

The `kubectl logs --previous` command retrieves logs from the previous instance of a container in a Pod that has crashed or been restarted. This is essential for debugging transient failures because the current container's logs may not contain the crash information. The `--previous` flag specifically accesses the terminated container's log stream, which is stored by the kubelet until the pod is deleted.

Exam trap

The trap here is that candidates often choose `kubectl logs <pod-name>` (option B) thinking it shows all logs, but they forget that a crashed container's logs are only accessible with the `--previous` flag.

How to eliminate wrong answers

Option B is wrong because `kubectl logs <pod-name>` only shows logs from the currently running container, not from a previously crashed instance. Option C is wrong because `kubectl exec` runs a command in a running container, which is impossible if the container has crashed and is not running. Option D is wrong because `kubectl describe pod` shows pod metadata, events, and status, but does not retrieve container logs, especially not from a previous crash.

Full explanation →

453

MCQmedium

Refer to the exhibit. The master node shows NotReady status. The kubelet is reporting 'container runtime is down'. Which command should be used to investigate and fix this issue?

A.kubectl delete node master && kubeadm reset

B.systemctl status kubelet && systemctl restart kubelet

C.systemctl status containerd && systemctl restart containerd

D.systemctl status docker && systemctl restart docker

AnswerC

In a kubeadm-provisioned cluster, the default and expected container runtime is containerd, with the CRI socket typically located at `/run/containerd/containerd.sock`. If the containerd service has stopped, crashed, or is unresponsive, the kubelet cannot communicate over CRI to create pods or static control-plane pods, causing it to report NotReady. Running `systemctl status containerd` confirms whether the service failed, and `systemctl restart containerd` restores the CRI endpoint so the kubelet can re-establish its connection and recover node status. After restarting, you can validate with `crictl ps` or check that the node becomes Ready within a few minutes.

Why this answer

The kubelet is unable to communicate with the container runtime. Since the master uses containerd (common in kubeadm), checking the containerd service status and restarting it is the first step.

Full explanation →

454

MCQmedium

You need to create a RoleBinding that grants a user access to read Pods in the 'dev' namespace. Which YAML manifest is correct?

A.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: dev ... subjects: - kind: ServiceAccount name: dev-user roleRef: kind: Role name: pod-reader

B.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding ... subjects: - kind: User name: dev-user roleRef: kind: ClusterRole name: pod-reader

C.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding ... subjects: - kind: User name: dev-user roleRef: kind: ClusterRole name: pod-reader

D.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: dev ... subjects: - kind: User name: dev-user roleRef: kind: Role name: pod-reader

AnswerD

This is the correct answer. The RoleBinding is defined with 'namespace: dev', which confines the authorization to the dev namespace. The subject uses 'kind: User' and 'name: dev-user', correctly identifying the human user who needs access. The roleRef points to a Role named 'pod-reader' in the same namespace, which is the appropriate binding structure for granting namespace-scoped permissions to a named user. This combination satisfies the requirement of granting the user access to pod-reader only in the dev namespace.

Why this answer

It defines a RoleBinding in the 'dev' namespace that binds a User named 'dev-user' to a Role named 'pod-reader'. This grants the user read access to Pods within that specific namespace, which is exactly what the question requires. RoleBindings are namespace-scoped and must specify the target namespace in metadata.

Exam trap

CNCF often tests the distinction between RoleBinding and ClusterRoleBinding, and candidates mistakenly choose a ClusterRoleBinding when namespace-scoped access is required, or forget to include the namespace in the RoleBinding metadata.

How to eliminate wrong answers

Option A is wrong because it uses a ServiceAccount as the subject instead of a User, and the question explicitly asks to grant access to a user. Option B is wrong because it omits the namespace in metadata (RoleBindings are namespace-scoped and require a namespace), and it references a ClusterRole instead of a Role, which would work but is not the simplest correct answer; however, the missing namespace makes it invalid. Option C is wrong because it uses a ClusterRoleBinding, which grants cluster-wide access, not namespace-scoped access as required by the question.

Full explanation →

455

MCQeasy

You want to debug a Service that is not reachable. Which kubectl command can you use to forward a local port to a pod in the Service?

A.kubectl expose deployment my-deployment --type=NodePort

B.kubectl port-forward svc/my-service 8080:80

C.kubectl exec -it my-pod -- curl localhost:80

D.kubectl proxy

AnswerB

kubectl port-forward svc/my-service 8080:80 is the correct command because it establishes a secure, temporary tunnel from your local machine's port 8080 to port 80 on a pod backing the specified my-service. This allows you to directly access the service from your local machine, bypassing any external network configurations or ingress controllers. It's an ideal method for debugging an unreachable service by testing its internal functionality and connectivity directly.

Why this answer

`kubectl port-forward svc/my-service 8080:80` creates a local TCP tunnel from port 8080 on your workstation to port 80 on a pod selected by the Service `my-service`. This allows you to reach the Service's backend pod directly without exposing it externally, which is a standard debugging technique for testing connectivity to a Service that appears unreachable.

Exam trap

The trap here is that candidates may confuse `kubectl port-forward` with `kubectl expose` or `kubectl proxy`, thinking any command that 'exposes' or 'proxies' can forward a local port, but only `port-forward` directly creates a local-to-pod tunnel for debugging a specific Service endpoint.

How to eliminate wrong answers

Option A is wrong because `kubectl expose deployment my-deployment --type=NodePort` creates a new Service or modifies an existing one to expose it via a NodePort, but it does not forward a local port to a pod; it changes the Service type to make it externally accessible on a node port, which is not a debugging port-forward command. Option C is wrong because `kubectl exec -it my-pod -- curl localhost:80` runs a command inside a specific pod to test connectivity from within the pod itself, but it does not forward a local port from your workstation to the pod; it tests the pod's internal loopback, not the Service's reachability from outside. Option D is wrong because `kubectl proxy` starts a proxy server that provides access to the Kubernetes API server, not to individual pods or Services; it does not forward a local port to a pod in a Service.

Full explanation →

456

Multi-Selecthard

A node is NotReady. Which THREE conditions could cause this?

Select 3 answers

A.Network plugin (e.g., Calico) is not functioning

B.A pod is in CrashLoopBackOff

C.kubelet service is stopped

D.Disk pressure on the node

E.The API server is overloaded

AnswersA, C, D

The kubelet determines node readiness by reporting conditions such as Ready, and one key condition the kubelet watches is the status of the container network interface (CNI). If the network plugin (e.g., Calico, Flannel, Cilium) fails to install routes, pods, or the CNI binaries, the kubelet cannot set up pod networking, causing the Ready condition to become False. The kubelet may also have its own network readiness checks (like the NodeStatus condition for network) that fail, and the node will stay NotReady until the CNI plugin is restored. This is why a healthy kubelet and Kubernetes control plane can still show a node as NotReady when the overlay network is broken.

Why this answer

Kubelet stopped, network plugin issues, and disk pressure can all cause a node to become NotReady.

Full explanation →

457

MCQmedium

A pod is stuck in Pending state. You run 'kubectl describe pod my-pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {gpu: true} that the pod didn't tolerate, 3 node(s) had resource pressure.'. What is the most likely cause?

A.The pod has a nodeSelector that doesn't match any node.

B.The pod is using a deprecated API version.

C.The pod needs a toleration for the gpu taint, and nodes have resource constraints.

D.The pod's image pull secret is missing.

AnswerC

The scheduler cannot place the pod because the available nodes either carry a gpu taint that the pod does not tolerate, or they lack sufficient CPU/memory capacity to satisfy the pod's resource requests. To resolve this, you must add the appropriate tolerations to the pod specification and ensure the cluster has nodes with adequate allocatable resources.

Why this answer

The event message explicitly states that 1 node has a taint (gpu: true) that the pod does not tolerate, and 3 nodes have resource pressure (e.g., memory, disk, or PID exhaustion). A pod remains in Pending state when no node can satisfy its scheduling requirements; adding a toleration for the gpu taint would allow scheduling on that node, but the resource pressure on the other nodes must also be resolved (e.g., by freeing resources or increasing capacity).

Exam trap

CKA often tests the distinction between taint/toleration issues and other scheduling constraints (like nodeSelector or affinity), and the trap here is that candidates may overlook the resource pressure component and focus only on the taint, or confuse the event message with a nodeSelector mismatch.

How to eliminate wrong answers

Option A is wrong because the event message does not mention any nodeSelector mismatch; it specifically cites taints and resource pressure, not label mismatches. Option B is wrong because deprecated API versions cause warnings or failures during resource creation, not a Pending state with scheduling events about taints and resource pressure. Option D is wrong because a missing image pull secret would cause an ImagePullBackOff or ErrImagePull event, not a Pending state with scheduling-related events about taints and resource pressure.

Full explanation →

458

MCQeasy

Which command can you use to check the expiration date of certificates managed by kubeadm?

A.kubeadm certs check-expiration

B.kubectl get certificates

C.kubeadm certs list

D.kubeadm certs renew --check

AnswerA

The `kubeadm certs check-expiration` command is the official kubeadm subcommand for inspecting the validity of all certificates managed by kubeadm. It reads the certificate files from the default PKI directory (usually /etc/kubernetes/pki) and from the kubeconfig files in /etc/kubernetes, then prints a table showing the remaining validity period for each certificate. This is the canonical way to audit certificate expiration on a cluster bootstrapped with kubeadm, and it also displays the CA certificates separately from the leaf certificates.

Why this answer

The correct command is `kubeadm certs check-expiration`, which is a dedicated kubeadm subcommand that inspects all certificates managed by kubeadm and displays their expiration dates, remaining validity, and renewal status. This command reads the certificate files from `/etc/kubernetes/pki/` and parses their X.509 metadata, providing a concise summary without requiring external tools like OpenSSL.

Exam trap

The trap here is that candidates confuse the `kubeadm certs` subcommands, often misremembering `list` or inventing flags like `--check`, when the actual command uses the precise verb `check-expiration` to separate inspection from renewal.

How to eliminate wrong answers

Option B is wrong because `kubectl get certificates` is not a valid kubectl command; kubectl interacts with Kubernetes API resources, not filesystem certificates, and there is no built-in 'certificates' resource type. Option C is wrong because `kubeadm certs list` does not exist; the correct subcommand for listing certificate details is `check-expiration`, not `list`. Option D is wrong because `kubeadm certs renew --check` is not a valid flag; the `renew` subcommand performs actual renewal, and there is no `--check` flag — the check functionality is separated into the `check-expiration` subcommand.

Full explanation →

459

MCQhard

A Kubernetes cluster uses kube-proxy in IPVS mode. A Service named 'api-svc' of type ClusterIP has three endpoints: 10.244.1.5:8080, 10.244.2.6:8080, and 10.244.3.7:8080. A client pod repeatedly connects to 'api-svc' and observes that all connections are routed to the same endpoint, 10.244.1.5:8080. The client pod and the endpoints are on different nodes. What is the most likely cause?

A.The IPVS scheduler is set to 'rr' (round-robin), but session affinity is enabled on the Service.

B.The IPVS scheduler is set to 'sh' (source hashing), which consistently maps the same client IP to the same endpoint.

C.The Service has 'externalTrafficPolicy: Local' set, causing traffic to be routed only to endpoints on the same node as the client.

D.The client pod is using a persistent HTTP connection, and the Service's load balancing only applies to new TCP connections.

AnswerB

In IPVS mode, the default scheduler is 'rr' (round-robin), but if the scheduler is changed to 'sh' (source hashing), IPVS uses a hash of the source IP to select a real server. This ensures that all connections from the same client IP go to the same endpoint, explaining why the client pod always reaches 10.244.1.5. This is the most likely cause given the consistent routing without session affinity.

Why this answer

In IPVS mode, kube-proxy can use different schedulers. The default is round-robin, but if configured to source hashing ('sh'), IPVS selects the real server based on a hash of the source IP. This causes all connections from the same client IP to consistently go to the same endpoint.

Since the client pod always reaches the same endpoint across multiple connections, the most likely cause is that the IPVS scheduler is set to 'sh'.

Exam trap

The trap here is confusing connection-level load balancing with per-request load balancing; IPVS source hashing can pin a client to one endpoint even without session affinity.

Full explanation →

460

MCQmedium

A HorizontalPodAutoscaler (HPA) is configured for a Deployment with targetCPUUtilizationPercentage: 80. The current CPU utilization is 90%. The deployment has minReplicas: 3 and maxReplicas: 10. What will the HPA do?

A.It does nothing because the utilization is within the acceptable range.

B.It adds a new node to the cluster.

C.It decreases the number of replicas to reduce CPU usage.

D.It increases the number of replicas.

AnswerD

This is the correct behavior because the current average CPU utilization (90%) is higher than the target utilization (80%). The HPA controller uses the formula of desired replicas equals the ceiling of current replicas multiplied by the ratio of current metric value to target metric value. Since this ratio is greater than 1.0, the controller will increase the replica count of the deployment to distribute the load and bring utilization down.

Why this answer

The HPA increases the number of replicas because the current CPU utilization (90%) exceeds the target of 80%. The HPA calculates the desired replica count using the formula: desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)], which yields ceil[3 * (90/80)] = ceil[3.375] = 4 replicas. This scales the deployment up to reduce per-pod CPU load, staying within the configured minReplicas (3) and maxReplicas (10).

Exam trap

The CKA exam often tests the misconception that the HPA can directly manage cluster nodes, but the HPA only adjusts pod replicas; node autoscaling is a separate component.

How to eliminate wrong answers

Option A is wrong because the utilization of 90% is above the target of 80%, so the HPA does not consider it within the acceptable range and must act. Option B is wrong because the HPA only manages replica counts within the cluster; node scaling is handled by the Cluster Autoscaler, not the HPA, and the HPA does not directly add nodes. Option C is wrong because increasing utilization above the target triggers scale-up, not scale-down; decreasing replicas would further increase per-pod CPU load, worsening the situation.

Full explanation →

461

MCQeasy

Which kubectl command is used to view the current context in the kubeconfig file?

A.kubectl config view

B.kubectl config use-context

C.kubectl config current-context

D.kubectl config get-contexts

AnswerC

This command specifically queries the active kubeconfig file and outputs only the name of the currently active context to stdout. It is the most direct and precise way to programmatically or visually verify which cluster, user, and namespace combination your kubectl commands will target by default.

Why this answer

`kubectl config current-context` is the dedicated kubectl command that displays the currently active context from the kubeconfig file. This command directly queries the `current-context` field in the kubeconfig and outputs its value, allowing you to verify which cluster, user, and namespace combination is active without modifying any configuration.

Exam trap

The trap here is that candidates confuse `kubectl config get-contexts` (which lists all contexts and marks the current one) with `kubectl config current-context` (which outputs only the current context name), leading them to pick option D because they see the current context highlighted, but the question specifically asks for the command to 'view the current context' as a direct output.

How to eliminate wrong answers

Option A is wrong because `kubectl config view` displays the entire kubeconfig file contents, including all contexts, clusters, and users, but does not specifically show which context is currently active. Option B is wrong because `kubectl config use-context` is used to switch the active context, not to view it; it modifies the `current-context` field in the kubeconfig. Option D is wrong because `kubectl config get-contexts` lists all available contexts and marks the current one with an asterisk, but it does not directly output just the current context name; it shows the full list, which is not the same as the single command to view the current context.

Full explanation →

462

MCQmedium

You have a DaemonSet that is supposed to run on all nodes, but you notice it is not running on a node with a taint 'dedicated=monitoring:NoSchedule'. What must be added to the DaemonSet's pod template to make it run on that node?

A.Add the annotation 'scheduler.alpha.kubernetes.io/tolerations'

B.A nodeSelector with key 'dedicated' and value 'monitoring'

C.Set the priorityClassName to 'system-node-critical'

D.A toleration with key 'dedicated', value 'monitoring', effect 'NoSchedule'

AnswerD

To allow DaemonSet pods to schedule on nodes carrying the 'dedicated=monitoring:NoSchedule' taint, you must define a matching toleration in the Pod template spec. This toleration explicitly permits the scheduler to place the pods on these tainted nodes, ensuring complete cluster-wide coverage for the DaemonSet.

Why this answer

A DaemonSet's pods must tolerate a node's taints to be scheduled on that node. The taint 'dedicated=monitoring:NoSchedule' means pods without a matching toleration will not be scheduled. Adding a toleration with key 'dedicated', value 'monitoring', and effect 'NoSchedule' explicitly allows the DaemonSet pod to bypass this taint and run on the node.

Exam trap

The trap here is that candidates often confuse nodeSelector (which selects nodes by labels) with tolerations (which handle taints), leading them to pick option B, but nodeSelector does not override taints.

How to eliminate wrong answers

Option A is wrong because 'scheduler.alpha.kubernetes.io/tolerations' is a deprecated annotation from early Kubernetes versions and is not the standard way to add tolerations; the correct method is to use the 'tolerations' field in the pod spec. Option B is wrong because a nodeSelector with key 'dedicated' and value 'monitoring' would only schedule pods on nodes that have that label, but it does not address the taint; the pod would still be blocked by the NoSchedule taint. Option C is wrong because setting priorityClassName to 'system-node-critical' increases the pod's priority but does not bypass taints; tolerations are required to override scheduling restrictions from taints.

Full explanation →

463

MCQmedium

You need to check the expiration date of certificates used by the kube-apiserver. Which command should you use?

A.kubeadm certs renew

B.kubectl get secrets -n kube-system

C.openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout

D.kubeadm certs check-expiration

AnswerD

This is the correct and standard administrative command used to inspect the expiration status of all Kubernetes control plane certificates managed by kubeadm. It scans the /etc/kubernetes/pki directory and the embedded certificates within the kubeconfig files, outputting a clean, tabular summary of the residual lifetime, expiration date, and authority for each certificate.

Why this answer

`kubeadm certs check-expiration` is the dedicated kubeadm command to display the expiration dates of all certificates managed by kubeadm in the cluster, including the kube-apiserver certificate. This command reads the certificate files from `/etc/kubernetes/pki/` and outputs the remaining validity period for each, making it the most direct and accurate method for checking certificate expiration in a kubeadm-deployed cluster.

Exam trap

The trap here is that candidates may confuse `kubeadm certs check-expiration` with `kubeadm certs renew` (option A) or think that `openssl` (option C) is the only way to inspect certificates, but the CKA exam expects you to know the kubeadm-specific command for checking expiration as part of cluster maintenance tasks.

How to eliminate wrong answers

Option A is wrong because `kubeadm certs renew` is used to renew certificates, not to check their expiration dates; it performs the renewal action without providing expiration information. Option B is wrong because `kubectl get secrets -n kube-system` retrieves Kubernetes secrets (which may contain certificate data as opaque or TLS secrets), but it does not decode or display the expiration dates of the certificates; it only shows metadata and base64-encoded values. Option C is wrong because while `openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout` can indeed show the certificate details including expiration, it is a manual, file-level command that requires knowing the exact path and does not leverage kubeadm's cluster-aware certificate management; it is a valid alternative but not the recommended or most efficient command for this specific task in a kubeadm context.

Full explanation →

464

Multi-Selecthard

Which THREE of the following are valid steps to troubleshoot a node that is in 'NotReady' state?

Select 3 answers

A.Check the kubelet status using 'systemctl status kubelet' on the node

B.View kubelet logs using 'journalctl -u kubelet'

C.Check node conditions with 'kubectl describe node <node-name>'

D.Restart the kubelet using 'systemctl restart kubelet'

E.Delete the node object and rejoin it to the cluster

AnswersA, B, C

Checking whether the kubelet is actually running on the node is the first diagnostic action: systemctl status kubelet reports whether the unit is active, the main PID, memory/CPU usage, and a short tail of recent log lines. If the service is inactive or failed, the exit status and timestamp help determine whether the node problem is a service crash, a stopped unit, or a configuration failure. This is a quick, non-destructive check that establishes the starting point before digging into logs.

Why this answer

Options A, B, and C are valid troubleshooting steps to investigate a NotReady node. Option A checks if kubelet is running, Option B examines kubelet logs for errors, and Option C shows node conditions. Option D (restarting kubelet) is a remediation action, not a troubleshooting step.

Option E (deleting and rejoining) is a recovery step.

Full explanation →

465

MCQeasy

Which resource type is used to define a template for dynamically provisioning PersistentVolumes?

A.PersistentVolume

B.VolumeAttachment

C.StorageClass

D.PersistentVolumeClaim

AnswerC

A StorageClass acts as the template and driver definition for dynamic volume provisioning in Kubernetes. It defines which volume plugin (provisioner) to use and passes specific parameters, such as IOPS or replication factors, to the underlying storage provider when a user requests storage via a PersistentVolumeClaim.

Why this answer

StorageClass is the correct resource because it defines a 'class' of storage with a provisioner (e.g., kubernetes.io/aws-ebs) and parameters that Kubernetes uses to dynamically create PersistentVolumes when a PersistentVolumeClaim requests storage. Without a StorageClass, dynamic provisioning cannot occur, as the cluster needs a template to know which storage backend to use and how to configure it.

Exam trap

The trap here is that candidates confuse PersistentVolumeClaim (a request) with the template that defines how to fulfill that request, or think PersistentVolume itself can be used as a template, when in fact it is the result of provisioning, not the definition.

How to eliminate wrong answers

Option A is wrong because a PersistentVolume is a static piece of pre-provisioned storage, not a template for dynamic provisioning; it represents an actual volume that already exists. Option B is wrong because VolumeAttachment is used to attach a volume to a node (via CSI or in-tree drivers) and has no role in defining provisioning templates. Option D is wrong because a PersistentVolumeClaim is a request for storage by a user, not a template for creating volumes; it triggers dynamic provisioning only when a StorageClass is referenced.

Full explanation →

466

Multi-Selecthard

A ClusterIP Service is not reachable from within the cluster. You verify that the Service has endpoints. Which of the following could be the cause? (Select two.)

Select 2 answers

A.kube-proxy is not running on the node.

B.The container is listening on a different port than the Service targetPort.

C.The pod's readiness probe is failing.

D.The Service name is too long.

AnswersA, B

kube-proxy programs the iptables or IPVS rules that implement ClusterIP load balancing on each node. If it is not running, packets to the virtual IP are never translated to a pod endpoint, so the Service fails despite having healthy endpoints.

Why this answer

Option A is correct because kube-proxy is the component that programs the iptables/IPVS rules on each node to implement ClusterIP Service virtual IP load balancing; if kube-proxy is not running on a node, pods on that node cannot reach the Service's ClusterIP even though endpoints exist. Option B is correct because the Service's targetPort must match the port the container actually listens on; if the container listens on a different port, traffic forwarded to the endpoint will be refused or dropped, making the Service unreachable despite having endpoints. Option C is not correct because a failing readiness probe would remove the pod from the Service's endpoints, but the scenario explicitly states that endpoints exist, so this cannot be the cause.

Option D is not correct because Kubernetes Service names are limited to 63 characters by DNS label rules, but an overly long name would be rejected at creation time rather than causing a running Service with endpoints to be unreachable.

Exam trap

Candidates may think a failing readiness probe can cause unreachability even when endpoints exist, but that is not possible because the pod would be removed from endpoints upon probe failure.

Why the other options are wrong

Service name length does not affect connectivity.

Full explanation →

467

MCQeasy

Which command is used to initialize a Kubernetes cluster using kubeadm?

A.kubeadm init

B.kubeadm create cluster

C.kubeadm start

D.kubeadm bootstrap

AnswerA

kubeadm init is the correct command because it initializes a Kubernetes control-plane node, performing preflight checks, generating PKI certificates, kubeconfig files, and etcd cluster configuration. It is the standard bootstrap mechanism for building a new cluster and is the only valid 'initialization' subcommand in kubeadm's CLI.

Why this answer

The correct command to initialize a Kubernetes cluster using kubeadm is `kubeadm init`. This command performs the bootstrap process by setting up the control plane components (e.g., API server, etcd, controller manager, scheduler) on the node, generating certificates, and creating the necessary configuration files in `/etc/kubernetes/`. It is the standard first step after installing kubeadm, kubelet, and a container runtime.

Exam trap

The trap here is that candidates confuse `kubeadm init` with non-existent commands like `kubeadm create cluster` or `kubeadm bootstrap`, assuming a more intuitive or verbose command exists, when in fact kubeadm's subcommands are deliberately minimal and specific.

How to eliminate wrong answers

Option B is wrong because `kubeadm create cluster` is not a valid kubeadm subcommand; kubeadm uses `init` for control plane initialization and `join` for worker nodes, not a generic 'create cluster'. Option C is wrong because `kubeadm start` does not exist; starting the cluster is handled by the kubelet service and systemd, not by kubeadm directly. Option D is wrong because `kubeadm bootstrap` is not a valid command; the bootstrap process is triggered by `kubeadm init` (or `kubeadm join` for nodes), and there is no separate 'bootstrap' subcommand.

Full explanation →

468

MCQmedium

An admin runs 'kubectl get pods' and sees a pod in 'Pending' state for a long time. 'kubectl describe pod' shows '0/1 nodes are available: 1 node has memory pressure'. Which is the most likely cause?

A.The node's disk is full.

B.The pod's image pull secret is missing.

C.The node is under memory pressure and cannot admit the pod.

D.The pod requires more CPU than any node can provide.

AnswerC

The scheduler's filter plugin rejects nodes reporting MemoryPressure, so the pod stays Pending with the '0/1 nodes are available' message. The node cannot admit new pods until memory pressure clears or the pod requests are reduced.

Why this answer

The '0/1 nodes are available: 1 node has memory pressure' message in `kubectl describe pod` indicates that the kubelet on the node has set a memory pressure condition, which triggers eviction thresholds. When a node is under memory pressure, the kubelet refuses to admit new pods (except those with QoS class Guaranteed) to prevent further resource exhaustion, leaving the pod stuck in Pending state. This matches option C exactly.

Exam trap

CNCF often tests the distinction between different node pressure conditions (memory vs. disk vs. PID) and their corresponding error messages, so candidates must recognize that 'memory pressure' is a specific kubelet condition, not a generic resource shortage.

How to eliminate wrong answers

Option A is wrong because a full disk would cause 'disk pressure', not 'memory pressure', and would be reported as '0/1 nodes are available: 1 node has disk pressure'. Option B is wrong because a missing image pull secret would cause an ImagePullBackOff or ErrImagePull error, not a Pending state with node availability issues. Option D is wrong because insufficient CPU would be reported as 'Insufficient cpu' in the node conditions, not 'memory pressure', and the pod would still be schedulable if memory were available.

Full explanation →

469

Multi-Selectmedium

Which TWO of the following are valid strategies for a Deployment's rolling update? (Select TWO.)

Select 2 answers

A.maxUnavailable: 0

B.maxSurge: 1

C.podManagementPolicy: OrderedReady

D.scaleUp: 2

E.type: Recreate

AnswersA, B

Setting maxUnavailable to 0 ensures that no pods are terminated before new ones are ready. This guarantees that 100% of the desired replica count remains available during a rolling update, preventing any capacity drop. It is a valid configuration under the rollingUpdate strategy field of a Deployment.

Why this answer

In a Kubernetes Deployment's rollingUpdate strategy, maxUnavailable: 0 (option A) is valid because it guarantees that the number of available Pods never drops below the desired replica count during an update, forcing new Pods to become Ready before old ones are terminated. maxSurge: 1 (option B) is also valid because it allows the Deployment to temporarily exceed the desired replica count by one Pod, enabling new Pods to be created before old ones are removed. Both fields belong under spec.strategy.rollingUpdate and accept either an integer or a percentage. Option C (podManagementPolicy: OrderedReady) is a StatefulSet field, not a Deployment rolling-update parameter.

Option D (scaleUp: 2) is not a Kubernetes Deployment field at all. Option E (type: Recreate) is a valid Deployment strategy type, but it is not a rolling-update strategy since it terminates all existing Pods before creating new ones.

Exam trap

The trap here is that candidates often confuse `podManagementPolicy` (a StatefulSet-only field) with Deployment update strategies, or incorrectly assume that `scaleUp` is a valid rolling update parameter, when in fact only `maxSurge` and `maxUnavailable` are used.

Full explanation →

470

MCQmedium

You run 'kubectl get events --sort-by=.lastTimestamp' and see the following events for a pod: 'Warning FailedScheduling 0/3 nodes are available: 3 Insufficient cpu'. What is the most likely solution?

A.Reduce the CPU request for the pod or remove other workloads to free CPU

B.Change the scheduler to a different one

C.Increase the CPU limit for the pod

D.Add more nodes to the cluster

AnswerA

The Kubernetes scheduler uses a pod's CPU request to determine node feasibility during the filtering phase. Lowering this request value reduces the resource footprint required for scheduling, allowing the pod to fit onto existing nodes with limited allocatable CPU. Alternatively, evicting or deleting non-essential workloads frees up allocatable capacity on those nodes, resolving the scheduling bottleneck without requiring infrastructure changes.

Why this answer

The event '0/3 nodes are available: 3 Insufficient cpu' indicates that all three nodes in the cluster lack sufficient allocatable CPU to satisfy the pod's CPU request. The most direct solution is to either reduce the pod's CPU request (so it fits on an existing node) or remove other workloads to free up CPU capacity. This aligns with Kubernetes resource scheduling, where the scheduler only considers requests (not limits) when placing pods.

Exam trap

The trap here is that candidates often confuse CPU requests with CPU limits and mistakenly think increasing limits will help the pod get scheduled, but the scheduler only evaluates requests, not limits.

How to eliminate wrong answers

Option B is wrong because changing the scheduler does not address the root cause of insufficient CPU resources; the default scheduler already evaluates node capacity, and a different scheduler would face the same resource shortage. Option C is wrong because increasing the CPU limit does not affect scheduling decisions—limits are for resource enforcement at runtime, not for admission; the scheduler only considers CPU requests. Option D is wrong because adding more nodes is an over-engineered solution; the cluster already has three nodes, and the issue is that they are fully utilized, so reducing demand is more efficient and cost-effective than scaling out.

Full explanation →

471

MCQmedium

Which annotation is commonly used with ExternalDNS to specify the DNS hostname for a Service?

A.service.beta.kubernetes.io/load-balancer-dns

B.external-dns.alpha.kubernetes.io/hostname

C.dns.alpha.kubernetes.io/hostname

D.kubernetes.io/ingress.class

AnswerB

This is the canonical annotation ExternalDNS watches on Services and Ingresses. Its value is a comma-separated list of DNS names that ExternalDNS will provision records for, using the resource's external IP or hostname as the target. The alpha segment of the prefix signals that the annotation's schema may evolve, but this key remains the standard way to explicitly request a DNS record.

Why this answer

`external-dns.alpha.kubernetes.io/hostname` is the annotation used by the ExternalDNS project to specify the desired DNS hostname for a Kubernetes Service or Ingress. ExternalDNS watches resources with this annotation and synchronizes the DNS records (e.g., A or CNAME) with a configured DNS provider like AWS Route53 or Google Cloud DNS.

Exam trap

The trap here is that candidates confuse the `external-dns.alpha.kubernetes.io/hostname` annotation with the similar-sounding but non-existent `dns.alpha.kubernetes.io/hostname`, or they mistakenly associate `service.beta.kubernetes.io/load-balancer-dns` with DNS hostname configuration, when in fact it is not a real annotation in Kubernetes.

How to eliminate wrong answers

Option A is wrong because `service.beta.kubernetes.io/load-balancer-dns` is not a standard annotation; the correct annotation for specifying a custom DNS name on a Service of type LoadBalancer is `external-dns.alpha.kubernetes.io/hostname`. Option C is wrong because `dns.alpha.kubernetes.io/hostname` is not a recognized annotation in Kubernetes or ExternalDNS; the correct prefix is `external-dns.alpha.kubernetes.io`. Option D is wrong because `kubernetes.io/ingress.class` is used to specify the Ingress controller class (e.g., nginx, haproxy) for an Ingress resource, not for DNS hostname configuration with ExternalDNS.

Full explanation →

472

MCQmedium

You create a Deployment with the following YAML: apiVersion: apps/v1 kind: Deployment metadata: name: myapp spec: replicas: 3 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: myapp image: myapp:latest resources: limits: cpu: "500m" memory: "256Mi" requests: cpu: "200m" memory: "128Mi" After applying it, the pods are in 'CrashLoopBackOff'. You check logs and see 'Error: container process exited with error'. What is the MOST likely cause?

A.The application is crashing at startup due to a missing dependency

B.The container is being OOMKilled because memory limit is too low

C.The readiness probe is failing

D.The container has insufficient CPU resources

AnswerA

When an application process exits immediately due to a missing dependency, runtime error, or misconfiguration, the container terminates with a non-zero exit code. Kubernetes detects this termination and automatically restarts the container, eventually entering a CrashLoopBackOff state as it backs off exponentially between restart attempts. This is the classic signature of an application-level startup failure.

Why this answer

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

Exam trap

The CKA exam often tests the distinction between container startup failures (application errors) and runtime resource issues (OOMKill, CPU throttling). Candidates may mistakenly attribute a generic exit error to resource limits or probes.

How to eliminate wrong answers

Option B is wrong because OOMKilled would show a specific 'OOMKilled' reason in `kubectl describe pod`, not a generic 'exited with error' message, and the memory limit of 256Mi is reasonable for many applications. Option C is wrong because readiness probes only affect traffic routing after the container is running; a failing readiness probe does not cause the container to exit with an error. Option D is wrong because insufficient CPU resources would cause the container to be throttled or pending, not to crash with an exit error; CPU limits are soft and do not kill containers.

Full explanation →

473

MCQhard

A CSI driver is installed in the cluster, but a PersistentVolumeClaim using a StorageClass that references this driver remains Pending. The administrator checks the logs of the CSI controller pod and sees no errors. What is a possible cause?

A.The CSI driver is not registered correctly.

B.The StorageClass volumeBindingMode is set to WaitForFirstConsumer.

C.The StorageClass volumeBindingMode is set to Immediate.

D.The PVC requests a size that is not available.

AnswerB

With volumeBindingMode: WaitForFirstConsumer, the PersistentVolumeClaim is intentionally left in the Pending state until a pod that references it is created and scheduled to a node. The external provisioner is not invoked at PVC creation time; instead, the scheduler waits for a pod to consume the volume, then binds and provisions it in the node's zone/topology. Therefore, if no pod has been created, the PVC remaining Pending with no errors is exactly the expected behavior.

Why this answer

If the volumeBindingMode is set to WaitForFirstConsumer, the PV will not be provisioned until a pod using the PVC is scheduled. This is a common pitfall. The CSI driver may be working fine, but the binding mode delays provisioning.

Full explanation →

474

MCQeasy

Which Kubernetes Service type exposes the Service on a static port on each Node's IP address, allowing external access without a LoadBalancer?

A.LoadBalancer

B.ClusterIP

C.ExternalName

D.NodePort

AnswerD

NodePort exposes the service externally by reserving a static port (typically in the 30000-32767 range) on every cluster node's IP address. Any traffic sent to this designated port on any node is automatically routed to the underlying pods via kube-proxy, providing a direct mechanism for external access.

Why this answer

A NodePort Service exposes the Service on a static port (in the range 30000-32767) on every Node's IP address. This allows external traffic to reach the Service by targeting any cluster node's IP and the assigned NodePort, without requiring a cloud LoadBalancer. The kube-proxy component on each node creates iptables or IPVS rules to forward traffic from that port to the corresponding ClusterIP Service and then to the selected Pods.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking a LoadBalancer is required for external access, but NodePort directly provides external access on each node's IP without any cloud provider dependency.

How to eliminate wrong answers

Option A is wrong because a LoadBalancer Service provisions an external load balancer (typically in a cloud environment) and does not expose a static port on each Node's IP; it relies on an external LB to distribute traffic. Option B is wrong because ClusterIP exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like an ingress or proxy. Option C is wrong because ExternalName maps a Service to a DNS name (via CNAME records) and does not expose any port or IP; it is used for internal DNS aliasing, not external access.

Full explanation →

475

MCQmedium

Which kube-proxy mode uses iptables rules to handle service traffic and is the default in many distributions?

A.userspace

B.ipvs

C.iptables

D.nftables

AnswerC

iptables mode is the default kube-proxy mode and uses a carefully constructed set of iptables rules (typically DNAT and REDIRECT) to handle Service traffic. For each Service and its endpoints, kube-proxy creates separate rules that are evaluated in a linear chain; the kernel rewrites the destination IP of a packet to one of the selected backend pod IPs. This mode operates entirely in kernel space, avoiding user-space copying while providing reliable and predictable behavior, although the linear rule traversal can introduce latency with thousands of Services.

Why this answer

The iptables mode is the default kube-proxy mode in many Kubernetes distributions, including kubeadm-based clusters. In this mode, kube-proxy watches the Kubernetes API server for Service and Endpoint changes and programs iptables rules in the kernel's netfilter framework to direct traffic to the appropriate backend Pods, providing efficient NAT-based load balancing without requiring a userspace proxy.

Exam trap

The trap here is that candidates often confuse the default kube-proxy mode with the ipvs mode, which is more performant but requires explicit configuration, or mistakenly think nftables is a supported mode in current Kubernetes releases.

How to eliminate wrong answers

Option A is wrong because the userspace mode is an older, deprecated kube-proxy mode that runs a userspace proxy process to handle service traffic, which introduces higher latency and is not the default in modern distributions. Option B is wrong because the ipvs mode uses the IPVS kernel module for load balancing and is not the default in most distributions; it must be explicitly enabled via the `--proxy-mode=ipvs` flag. Option D is wrong because nftables is a modern replacement for iptables in Linux, but kube-proxy does not support an nftables mode as of Kubernetes 1.28; it remains an experimental or future feature.

Full explanation →

476

MCQhard

A pod has status 'Init:Error'. What does this indicate?

A.The main container has crashed

B.An init container failed

C.The pod is being initialized

D.There is a network error during initialization

AnswerB

When an init container exits with a non-zero exit code, the pod status transitions to Init:Error (or Init:CrashLoopBackOff if it keeps failing). Kubernetes treats init containers as mandatory prerequisites: they run sequentially to completion before any regular containers start. The failing init container can be identified with kubectl describe pod, which shows the last exit code and reason, and its logs are available via kubectl logs <pod> -c <init-container-name>. This directly matches the init error status shown in the question stem.

Why this answer

The 'Init:Error' status indicates that a pod's init container has failed to complete successfully. Init containers run sequentially before any main containers start, and if one exits with a non-zero exit code, the pod enters this error state. This is distinct from a main container crash, which would show as 'CrashLoopBackOff' or 'Error' after the pod has started.

Exam trap

The trap here is that candidates confuse 'Init:Error' with a pod initialization phase or a main container error, when in fact it specifically indicates a failed init container that prevents the pod from reaching the running state.

Why the other options are wrong

Main container status would be CrashLoopBackOff or Error.

That would be Init:0/1 etc.

Network error would show as Init:NetworkNotReady or similar.

Full explanation →

477

MCQmedium

A company runs a batch job that processes a queue. The job should run to completion exactly once. Which resource should be used?

A.Job

B.DaemonSet

C.CronJob

D.Deployment

AnswerA

A Kubernetes Job is specifically designed to run a finite batch workload to completion. It creates one or more Pods and ensures that a specified number of them successfully terminate, making it the ideal resource for processing a finite work queue. Once the tasks are complete, the Job stops creating Pods, conserving cluster resources.

Why this answer

A Kubernetes Job is designed to run a specified number of pods to successful completion. When the pod exits with a zero exit code, the Job is marked as complete and will not be restarted, making it the correct choice for a batch job that must run exactly once.

Exam trap

The trap here is that candidates often confuse a CronJob with a Job, thinking that a CronJob can also run a one-time task, but CronJob is specifically for scheduled, recurring execution, not a single run-to-completion workload.

How to eliminate wrong answers

Option B (DaemonSet) is wrong because it ensures that a copy of a pod runs on every node (or a subset of nodes) in the cluster, continuously, not for a one-time batch job. Option C (CronJob) is wrong because it creates Jobs on a recurring schedule; while it could run a batch job, it is intended for periodic execution, not a single run-to-completion task. Option D (Deployment) is wrong because it manages a set of identical pods with a desired replica count, ensuring they are always running and self-healing, which is the opposite of a run-to-completion workload.

Full explanation →

478

MCQmedium

Which kubectl command is used to mark a node as unschedulable for new pods without affecting existing running pods?

A.kubectl cordon <node-name>

B.kubectl uncordon <node-name>

C.kubectl drain <node-name>

D.kubectl taint nodes <node-name> key=value:NoSchedule

AnswerA

This command directly sets the .spec.unschedulable field of the specified Node object to true. This prevents the Kubernetes scheduler from assigning any new pods to the node, while leaving existing running pods completely unaffected. It is the most direct and lightweight way to temporarily halt scheduling on a specific node.

Why this answer

The `kubectl cordon` command marks a node as unschedulable by setting the `node.Spec.Unschedulable` field to `true`. This prevents the Kubernetes scheduler from placing new pods onto the node, while existing pods continue to run unaffected. It is the correct tool for this specific maintenance task.

Exam trap

The trap here is that candidates confuse `kubectl drain` (which evicts pods and then cordons) with `kubectl cordon` (which only prevents new scheduling), leading them to select drain when the question explicitly states 'without affecting existing running pods'.

How to eliminate wrong answers

Option B is wrong because `kubectl uncordon` reverses the effect of cordon, making a previously unschedulable node schedulable again, not marking it unschedulable. Option C is wrong because `kubectl drain` evicts all pods from a node (respecting PodDisruptionBudgets) and then cordons it, which affects existing running pods, not just preventing new ones. Option D is wrong because `kubectl taint nodes ...:NoSchedule` adds a taint that prevents pods without a matching toleration from being scheduled, but it does not mark the node as unschedulable globally; pods with the correct toleration can still be scheduled, and it does not set the `Unschedulable` field.

Full explanation →

479

MCQmedium

You create a Service with clusterIP: None. What is this called and what is its purpose?

A.NodePort Service; it exposes on node ports.

B.ExternalName Service; it maps to an external DNS name.

C.ClusterIP Service; it provides a stable IP.

D.Headless Service; it allows direct pod-to-pod DNS resolution.

AnswerD

A Service with `clusterIP: None` is a headless Service: the DNS lookup returns multiple A records, one for each ready endpoint, instead of a single virtual IP. This allows clients to discover and connect directly to individual pods, enabling pod-to-pod DNS resolution and client-side load balancing without kube-proxy.

Why this answer

A Service with `clusterIP: None` is called a Headless Service. Its purpose is to allow direct pod-to-pod DNS resolution by returning the IP addresses of the backing pods (via DNS A/AAAA records) rather than a single virtual ClusterIP, enabling stateful applications like databases to discover individual pod endpoints.

Exam trap

The trap here is that candidates confuse the absence of a ClusterIP with a different Service type (like NodePort or ExternalName), not realizing that `clusterIP: None` specifically creates a Headless Service for direct pod DNS resolution.

How to eliminate wrong answers

Option A is wrong because a NodePort Service exposes a Service on a static port on each node's IP, not by setting `clusterIP: None`. Option B is wrong because an ExternalName Service maps to an external DNS name via a CNAME record, not by omitting the ClusterIP. Option C is wrong because a ClusterIP Service provides a stable virtual IP for load balancing, which is explicitly disabled when `clusterIP: None` is set.

Full explanation →

480

MCQhard

A StatefulSet named 'web' has 3 replicas. You need to update the container image from 'nginx:1.19' to 'nginx:1.20' using a rolling update with ordered pod management. What must you ensure in the StatefulSet spec?

A.Set spec.updateStrategy.rollingUpdate.maxSurge to 1

B.Set spec.updateStrategy.rollingUpdate.partition to 0

C.Set spec.podManagementPolicy to Parallel

D.Set spec.podManagementPolicy to OrderedReady (default)

AnswerD

Setting `spec.podManagementPolicy` to `OrderedReady` is the correct choice, as it is the default and ensures ordered, one-at-a-time updates. This policy dictates that the StatefulSet controller will create, update, or delete pods strictly in ascending ordinal order (for creation/update) or descending ordinal order (for deletion), waiting for each pod to be fully ready or terminated before proceeding to the next. This sequential processing is crucial for maintaining the stable identity and data consistency of stateful applications during lifecycle events.

Why this answer

For a StatefulSet to perform a rolling update with ordered pod management (pods updated one at a time in reverse ordinal order), the podManagementPolicy must be set to OrderedReady. This is the default policy and ensures that pods are created, deleted, and updated in a strict sequential order, maintaining the stable identity and startup ordering required by stateful applications.

Exam trap

The trap here is that candidates often confuse Deployment rolling update parameters (like maxSurge or maxUnavailable) with StatefulSet update strategies, or mistakenly think that setting a partition value is required for a full rolling update, when in fact the key requirement is the podManagementPolicy being OrderedReady.

How to eliminate wrong answers

Option A is wrong because maxSurge is not a valid field in the StatefulSet update strategy; it is used in Deployments to control how many extra pods can be created during a rolling update, but StatefulSets do not support maxSurge. Option B is wrong because setting spec.updateStrategy.rollingUpdate.partition to 0 is the default and does not affect the ordered rolling update behavior; partition is used for canary or phased rollouts, not for enabling ordered updates. Option C is wrong because setting spec.podManagementPolicy to Parallel would cause all pods to be created or deleted concurrently, which defeats the ordered pod management required for a rolling update that updates pods one at a time in reverse order.

Full explanation →

481

MCQeasy

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

A.kubectl logs <pod-name>

B.kubectl top pod <pod-name>

C.kubectl describe pod <pod-name>

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

AnswerC

This command retrieves detailed configuration and lifecycle status of the pod, including its recent event log. The 'Events' section at the bottom of the output will explicitly detail the failure reason, such as a 'Failed to pull image' error due to an incorrect tag, network issue, or missing registry credentials.

Why this answer

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

Exam trap

CNCF CKA often tests the misconception that 'kubectl logs' can diagnose pre-start failures, but logs only capture output from a running container, not from the image pull phase.

How to eliminate wrong answers

Option A is wrong because 'kubectl logs' retrieves container stdout/stderr, which is only available if the container has started; in ImagePullBackOff, the container never runs, so logs are empty. Option B is wrong because 'kubectl top pod' shows resource usage (CPU/memory) of running pods, which is irrelevant to image pull failures. Option D is wrong because 'kubectl exec' requires a running container to execute commands; in ImagePullBackOff, the container is not running, so exec fails.

Full explanation →

482

MCQmedium

A developer asks you to create a Service that resolves to an external database at 'db.example.com'. Which Service type should you use?

A.ExternalName

B.LoadBalancer

C.NodePort

D.ClusterIP

AnswerA

ExternalName services map a Kubernetes service directly to an external DNS name by returning a CNAME record from the cluster's internal DNS provider (like CoreDNS). This allows pods to reference external resources, such as a managed database, using a consistent internal service name without proxying any traffic through the cluster.

Why this answer

An ExternalName Service type maps a Service to a DNS name (e.g., 'db.example.com') by returning a CNAME record, allowing pods to resolve the Service name to an external endpoint without a proxy or selector. This is the only Service type that directly resolves to an external DNS name without requiring endpoints or a backend selector.

Exam trap

The trap here is that candidates often confuse ExternalName with a regular ClusterIP Service that has an external endpoint, but ExternalName is the only type that purely provides DNS-based resolution without any proxy or selector.

How to eliminate wrong answers

Option B (LoadBalancer) is wrong because it exposes the Service externally via a cloud load balancer, but it still requires a selector and endpoints to route traffic, not a DNS name. Option C (NodePort) is wrong because it exposes the Service on a static port on each node's IP, but it also requires a selector and internal endpoints, not an external DNS resolution. Option D (ClusterIP) is wrong because it provides a virtual IP within the cluster for internal traffic only, and it requires a selector to route to pods, not an external DNS name.

Full explanation →

483

Multi-Selecthard

Which THREE of the following are valid steps to troubleshoot a DNS issue within a Kubernetes cluster?

Select 3 answers

A.Verify that the kube-dns service has endpoints using 'kubectl get endpoints -n kube-system kube-dns'

B.Check the logs of the CoreDNS pods using 'kubectl logs -n kube-system -l k8s-app=kube-dns'

C.Check the /etc/resolv.conf on the node

D.Restart all nodes to reset DNS settings

E.Run 'kubectl exec -it busybox -- nslookup kubernetes.default'

AnswersA, B, E

This command is a first-line check to confirm the Service named kube-dns actually has backend Pods behind it. In Kubernetes, a Service is only able to route traffic to Pods that match its selector; if the endpoints list is empty, no Pod is available to receive DNS queries, meaning the Service is not routing to any CoreDNS Pod. You would then inspect the CoreDNS Deployment or DaemonSet to determine whether the Pods are unscheduled, crashing, or carry the wrong labels.

Why this answer

Option A is correct because verifying that the kube-dns service has endpoints with 'kubectl get endpoints -n kube-system kube-dns' confirms that the DNS service is properly backed by CoreDNS pods; if the endpoint list is empty, DNS resolution will fail cluster-wide. Option B is correct because inspecting CoreDNS pod logs via 'kubectl logs -n kube-system -l k8s-app=kube-dns' reveals errors such as plugin failures, upstream timeouts, or configuration problems that directly explain DNS resolution issues. Option E is correct because running 'kubectl exec -it busybox -- nslookup kubernetes.default' from inside a pod tests actual in-cluster DNS resolution against the kubernetes.default service, isolating whether the problem is DNS-specific or broader networking.

Option C is not a valid cluster DNS troubleshooting step because /etc/resolv.conf on the node governs the node's own resolver, not the DNS configuration injected into pods (which comes from the pod's dnsPolicy and kubelet settings). Option D is not valid because restarting all nodes is a disruptive, non-targeted action that does not address DNS misconfiguration and is not an accepted troubleshooting procedure.

Exam trap

CNCF often tests the misconception that node-level configuration files like `/etc/resolv.conf` are relevant for cluster-internal DNS troubleshooting, when in fact the issue is almost always within the CoreDNS pods or service endpoints.

Full explanation →

484

MCQeasy

You have a pod that is in 'Pending' state. Which command would you run to get more information about why the pod cannot be scheduled?

A.kubectl logs <pod-name>

B.kubectl get events

C.kubectl get pod <pod-name> -o wide

D.kubectl describe pod <pod-name>

AnswerD

This command queries the Kubernetes API server for the complete state of the pod and appends a dedicated Events section at the bottom. This section explicitly details scheduler decisions, such as insufficient CPU/memory, taints and tolerations mismatches, or node selector conflicts that are keeping the pod in a pending state.

Why this answer

`kubectl describe pod <pod-name>` provides detailed information about the pod, including events, conditions, and scheduler-related messages. For a pod stuck in 'Pending', the 'Conditions' and 'Events' sections will reveal scheduling failures such as insufficient resources, node selector mismatches, or taint toleration issues, which are not visible in logs or basic status output.

Exam trap

The trap here is that candidates often confuse `kubectl logs` (which only works for running containers) with troubleshooting a pending pod, or they assume `kubectl get events` is the best tool, but the most targeted and efficient command for a single pod's scheduling issue is `kubectl describe pod`.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` retrieves container logs from a running pod, but a pod in 'Pending' state has not started any containers, so there are no logs to fetch. Option B is wrong because `kubectl get events` shows cluster-wide events, which may include scheduling failures, but it does not filter specifically for the pod in question and can be noisy; it is less direct than describing the pod. Option C is wrong because `kubectl get pod <pod-name> -o wide` only adds node IP and host information, but does not expose the detailed scheduling conditions or error messages needed to diagnose why the pod is pending.

Full explanation →

485

MCQmedium

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

A.prometheus.io/scrape

B.external-dns.alpha.kubernetes.io/hostname

C.kubernetes.io/ingress.class

D.cert-manager.io/cluster-issuer

AnswerB

This is the standard annotation used by the ExternalDNS controller to dynamically provision DNS records in external providers like AWS Route53 or Cloudflare. When applied to a Service or Ingress resource, ExternalDNS reads this value to map the resource's public IP or hostname to the specified custom domain name.

Why this answer

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

Exam trap

The trap here is that candidates confuse annotations used by different ecosystem projects (Prometheus, cert-manager, Ingress controllers) with those specific to ExternalDNS, leading them to pick a familiar but incorrect annotation.

How to eliminate wrong answers

Option A is wrong because `prometheus.io/scrape` is an annotation used by the Prometheus operator to indicate that a target should be scraped for metrics, not for DNS record management. Option C is wrong because `kubernetes.io/ingress.class` is an annotation used on Ingress resources to select the Ingress controller (e.g., nginx, haproxy), not for ExternalDNS. Option D is wrong because `cert-manager.io/cluster-issuer` is an annotation used by cert-manager to specify the ClusterIssuer for TLS certificate issuance, not for DNS record management.

Full explanation →

486

MCQmedium

Which kube-proxy mode uses IP Virtual Server (IPVS) for load balancing and supports more algorithms than the default mode?

A.ipvs

B.userspace

C.iptables

D.kube-proxy

AnswerA

IPVS (IP Virtual Server) is a Linux kernel module that provides high-performance L4 load balancing with dedicated scheduling algorithms. In kube-proxy's ipvs mode, the kernel creates IPVS virtual servers for each Service, supporting algorithms like round-robin, least-connection, and weighted scheduling directly in kernel space. This is the mode that specifically leverages IPVS for load balancing, avoiding the linear rule traversal and limited scheduling of iptables.

Why this answer

The IP Virtual Server (IPVS) mode in kube-proxy leverages the Linux kernel's IPVS module, which is built on the Netfilter framework and operates in the kernel space. Unlike the default iptables mode, IPVS supports a variety of load-balancing algorithms (e.g., round-robin, least-connection, source-hashing) and provides better scalability and performance for large clusters by using a hash table for service-to-endpoint mapping.

Exam trap

The trap here is that candidates often confuse the default mode (iptables) with the IPVS mode, or mistakenly think that kube-proxy itself is a mode, when in fact IPVS is a distinct mode that must be explicitly enabled via the `--proxy-mode=ipvs` flag.

How to eliminate wrong answers

Option B (userspace) is wrong because it is the legacy mode that proxies traffic in user space, leading to high latency and poor performance; it does not use IPVS. Option C (iptables) is wrong because it is the default mode that uses iptables rules for load balancing, which supports only random or round-robin selection via statistic modules and lacks the advanced scheduling algorithms of IPVS. Option D (kube-proxy) is wrong because it is the component itself, not a mode; the question asks for the mode that uses IPVS.

Full explanation →

487

Multi-Selectmedium

You run 'kubectl cordon node1'. Which TWO statements describe the effect of this command? (Choose TWO.)

Select 2 answers

A.The node is removed from the cluster

B.All pods on node1 are deleted

C.Existing pods on node1 are immediately evicted

D.New pods will not be scheduled onto node1

E.The node is marked as unschedulable

AnswersD, E

Setting `spec.unschedulable` to true on node1 makes the scheduler skip the node during the scheduling cycle, so no new pods are placed there. This is the intended functional outcome of cordoning: to preserve the current pod set while blocking future placements. The scheduler re-evaluates this field on every scheduling decision.

Why this answer

Option D is correct because 'kubectl cordon node1' sets the node's spec.unschedulable field to true, which causes the Kubernetes scheduler to skip node1 when placing new pods, so no new pods will be scheduled onto it. Option E is correct because cordoning is precisely the operation that marks a node as unschedulable, which is reflected in the node's status and taints the scheduler's view of that node. The unmarked options do not belong: option A is wrong because cordoning does not remove the node from the cluster (that would require 'kubectl delete node'), option B is wrong because cordoning does not delete any pods, and option C is wrong because existing pods are not evicted by cordon—eviction requires 'kubectl drain' (with appropriate flags such as --ignore-daemonsets and --delete-emptydir-data).

Exam trap

The trap here is that candidates often confuse `cordon` with `drain`, mistakenly thinking that cordon evicts or deletes existing pods, when in fact it only prevents new scheduling.

Full explanation →

488

MCQmedium

A pod is unable to resolve DNS names of services in other namespaces. Which DNS configuration is most likely missing?

A.CoreDNS is not deployed in the cluster.

B.The pod's dnsPolicy is set to 'Default'.

C.The pod is in a different namespace than the service.

D.The service does not have a ClusterIP assigned.

AnswerB

When a pod's dnsPolicy is configured as 'Default', it inherits the name resolution configuration of the hosting node rather than using the cluster's DNS service (CoreDNS). Consequently, the pod can resolve external internet domains but lacks the search paths and nameservers required to resolve internal Kubernetes service FQDNs across namespaces.

Why this answer

When a pod's `dnsPolicy` is set to `Default`, the pod inherits the node's DNS resolution configuration, which typically points to the host's `/etc/resolv.conf` and does not include the cluster's DNS service (CoreDNS). This prevents the pod from resolving service DNS names like `<service>.<namespace>.svc.cluster.local`, which are only resolvable via the cluster's DNS. Setting `dnsPolicy` to `ClusterFirst` (the default if not specified) ensures the pod uses CoreDNS for DNS queries, enabling cross-namespace service discovery.

Exam trap

The trap here is that candidates often assume DNS issues are always due to CoreDNS not running or a service misconfiguration, but the CKA exam tests the subtle behavior of `dnsPolicy` and how `Default` inherits the node's DNS, breaking cluster service resolution.

How to eliminate wrong answers

Option A is wrong because if CoreDNS were not deployed, no pod in the cluster would resolve service DNS names, but the question implies only this specific pod has the issue, so CoreDNS is likely present. Option C is wrong because being in a different namespace does not prevent DNS resolution; Kubernetes DNS uses the format `<service>.<namespace>.svc.cluster.local` to resolve services across namespaces. Option D is wrong because a service without a ClusterIP would not be reachable via DNS at all, but the question states the pod cannot resolve DNS names, implying the service exists and has a ClusterIP; the issue is with the pod's DNS configuration, not the service's IP assignment.

Full explanation →

489

Multi-Selectmedium

Which THREE of the following are components of the Kubernetes control plane? (Choose THREE.)

Select 3 answers

A.kube-apiserver

B.kube-scheduler

C.etcd

D.kubelet

E.kube-proxy

AnswersA, B, C

The kube-apiserver is the front-end of the Kubernetes control plane: it exposes the Kubernetes REST API and handles all read/write operations to the cluster's desired state. Every request—whether from kubectl, pods, or other components—passes through it for authentication, authorization, admission control, and validation before it is persisted. It is the only component that communicates directly with etcd, making it the central gateway for all cluster interactions.

Why this answer

The Kubernetes control plane consists of the components that make global cluster decisions and store cluster state. kube-apiserver (A) is correct because it exposes the Kubernetes API and serves as the front end of the control plane, handling all REST requests and validating/updating objects in etcd. kube-scheduler (B) is correct because it watches for newly created Pods with no assigned node and selects a suitable node for them to run on. etcd (C) is correct because it is the consistent, highly-available key-value store that persists all cluster data and is the backing store for the API server. kubelet (D) is not a control plane component; it is a node agent that runs on each worker node and manages Pods and containers on that node. kube-proxy (E) is also not a control plane component; it is a node-level network proxy that implements Service networking rules on each node.

Exam trap

CNCF often tests the distinction between control plane components and node-level agents, so candidates mistakenly select kubelet or kube-proxy because they are essential to cluster operation, but they are not part of the control plane itself.

Full explanation →

490

MCQhard

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

A.Cordon the master node to remove it from scheduling

B.Remove or modify the pod anti-affinity rules

C.Add a toleration for the master taint to the pod spec

D.Delete and recreate the pod

AnswerB

Pod anti-affinity rules prevent the scheduler from placing a pod on a node that already hosts a matching pod. By removing or relaxing these rules, such as changing a hard requiredDuringSchedulingIgnoredDuringExecution constraint to a soft preferredDuringSchedulingIgnoredDuringExecution rule, the scheduler can utilize the available worker nodes even if they already run similar pods.

Why this answer

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

Exam trap

The trap here is that candidates focus on the taint error (because it's a common CKA topic) and overlook the anti-affinity error, which is the actual majority blocker; the CKA exam often tests your ability to prioritize multiple scheduling failures.

How to eliminate wrong answers

Option A is wrong because cordoning the master node would remove it from scheduling entirely, making the situation worse (only 2 nodes would remain, still blocked by anti-affinity). Option C is wrong because the pod already has a toleration for the master taint? No—the event shows the pod did NOT tolerate the master taint, but that only affects one node; the primary blocker is the anti-affinity rules on two nodes. Option D is wrong because deleting and recreating the pod without changing the anti-affinity rules would result in the same 'Pending' state.

Full explanation →

491

MCQmedium

You run 'kubectl logs my-pod -c my-container' and get no output, but you know the container produces logs. What should you do next to see previous container logs?

A.kubectl logs my-pod -c my-container -f

B.kubectl logs my-pod -c my-container --previous

C.kubectl logs my-pod -c my-container --tail=50

D.kubectl logs my-pod -c my-container --all-containers

AnswerB

`--previous` (or `-p`) is the correct flag because it instructs kubectl to retrieve the log file of the last terminated container instance for the named container in the same pod. When a container crashes and restarts, the kubelet retains the previous container's log file alongside the current one. By combining `-c my-container` with `--previous`, you specifically target the earlier incarnation that produced output, bypassing the currently empty log stream.

Why this answer

The --previous flag retrieves logs from the previous instance of a crashed container.

Full explanation →

492

MCQeasy

You have a Pod that is stuck in Pending state. Which command should you use to get detailed information about why the Pod is not running?

A.kubectl logs <pod-name>

B.kubectl describe pod <pod-name>

C.kubectl exec <pod-name> -- /bin/sh

D.kubectl get pod <pod-name>

AnswerB

This command queries the Kubernetes API server for the complete state of the Pod resource, rendering its configuration, current conditions, and controller events. The "Events" section at the bottom of the output is critical for troubleshooting Pending Pods, as it reveals scheduler decisions, such as insufficient CPU/memory, node taints, or missing PersistentVolumeClaims. This makes it the primary tool for diagnosing scheduling failures.

Why this answer

`kubectl describe pod <pod-name>` provides detailed event logs, status conditions, and resource constraints (e.g., insufficient CPU/memory, persistent volume claims pending, node selector mismatches) that explain why the Pod is stuck in Pending state. The Pending state indicates the Pod has been accepted by the API server but not yet scheduled or started, and `describe` surfaces the exact scheduler or admission controller failures.

Exam trap

Candidates often mistakenly think that `kubectl logs` can diagnose startup failures, but logs only exist for running containers, whereas `kubectl describe` reveals pre-scheduling and admission issues that cause the Pending state.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` retrieves container stdout/stderr, which is only available after the Pod has started running; a Pending Pod has no running containers to produce logs. Option C is wrong because `kubectl exec` requires a running container to execute commands, which does not exist in a Pending Pod. Option D is wrong because `kubectl get pod` only shows the current status (e.g., Pending) without the underlying reasons, such as failed volume mounts or taint toleration issues.

Full explanation →

493

MCQhard

A Service of type LoadBalancer is created but the EXTERNAL-IP remains <pending>. The cluster is running on-premises without a cloud load balancer integration. Which of the following is the most likely reason?

A.The cluster has no default storage class.

B.The nodes are not reachable from the internet.

C.No load balancer controller (e.g., MetalLB) is installed.

D.The Service selector does not match any pods.

AnswerC

In on-premises clusters without a cloud provider integration, the Service controller has no built-in mechanism to allocate an external IP. A load balancer controller such as MetalLB is required to watch for Services of type LoadBalancer and update their status with an IP from its address pool. Until that controller runs, the external IP is stuck in <pending>, which is exactly the symptom shown.

Why this answer

A Service of type LoadBalancer in Kubernetes requires an external load balancer controller to provision an external IP address. In on-premises clusters without cloud integration, no such controller exists by default, so the EXTERNAL-IP remains <pending> until a bare-metal load balancer like MetalLB is installed and configured. Option C is correct because without a load balancer controller, Kubernetes cannot assign an external IP.

Exam trap

The trap here is that candidates may confuse the EXTERNAL-IP <pending> state with networking issues (Option B) or pod connectivity (Option D), when the root cause is the absence of a load balancer controller, a concept specific to on-premises Kubernetes deployments.

Why the other options are wrong

Storage class is unrelated to LoadBalancer IP assignment.

Even if nodes are unreachable, a cloud LB would still assign an IP; on-premises, the LB controller would assign an IP from a pool.

A mismatched selector would result in no endpoints, but the external IP could still be assigned (pending also occurs if there's no controller).

Full explanation →

494

MCQmedium

You attempt to schedule a pod but it remains 'Pending'. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) didn't match node selector.' What is the MOST likely cause?

A.A PersistentVolumeClaim is not bound

B.All nodes have insufficient memory or CPU

C.The nodes have taints that the pod does not tolerate

D.The pod's nodeSelector does not match any node labels

AnswerD

A nodeSelector in the pod spec requires the selected node to have all the specified label key-value pairs. If no node in the cluster carries those labels, the scheduler marks those nodes as failing the `node selector` predicate and the pod remains Pending with an event like `0/N nodes are available: N node(s) didn't match node selector`. This is the canonical cause of a pending pod when there are no volume, resource, or taint issues, and it is confirmed by checking node labels with `kubectl get nodes --show-labels`.

Why this answer

The event '0/3 nodes are available: 3 node(s) didn't match node selector' explicitly indicates that the pod's nodeSelector field specifies labels that no node in the cluster possesses. The scheduler filters nodes based on the nodeSelector, and since none match, the pod remains Pending. The fix is to either label a node to match the selector or correct the pod's nodeSelector.

Exam trap

The trap is confusing node selector mismatches with taint/toleration or resource issues; candidates must read the exact scheduler event, because each failure mode produces a distinct message.

How to eliminate wrong answers

Option A is wrong because an unbound PersistentVolumeClaim would produce a different event such as 'pod has unbound immediate PersistentVolumeClaims' or 'waiting for first consumer to be created', not a node selector mismatch. Option B is wrong because insufficient memory or CPU would generate events like 'Insufficient cpu' or 'Insufficient memory' in the scheduler's failure message, not 'didn't match node selector'. Option C is wrong because taint/toleration issues produce events like 'node(s) had taint {key: value}, that the pod didn't tolerate', which is distinct from a node selector mismatch.

Full explanation →

495

MCQmedium

After creating a NetworkPolicy that selects pods with label 'role: db' and allows ingress on TCP port 3306 from pods with label 'role: api', you notice that pods with label 'role: db' are still reachable on port 3306 from pods without 'role: api' label. What is the most likely cause?

A.The NetworkPolicy is not in the same namespace as the pods.

B.The NetworkPolicy uses the wrong protocol.

C.The NetworkPolicy has an egress rule that overrides ingress.

D.The NetworkPolicy requires an explicit 'deny all' rule.

AnswerA

Kubernetes NetworkPolicy resources are strictly namespace-scoped. The podSelector defined within a policy only matches pods residing in the exact same namespace as the policy itself. If the policy is deployed in a different namespace than the target pods, it will fail to select them and have no effect on their traffic.

Why this answer

NetworkPolicies are namespaced resources. If the NetworkPolicy is created in a different namespace than the pods with label 'role: db', it will not apply to those pods. The policy must reside in the same namespace as the pods it targets; otherwise, the default behavior (allow all ingress) remains in effect for those pods.

Exam trap

The trap here is that candidates assume NetworkPolicies are cluster-scoped or automatically apply across namespaces, but they are namespaced resources and only affect pods in the same namespace unless explicitly using namespaceSelectors.

How to eliminate wrong answers

Option B is wrong because the question states the policy allows TCP port 3306, and the pods are reachable on that port; if the protocol were wrong (e.g., UDP), traffic would not match the rule, but the issue is that all traffic is allowed, not that a specific rule fails. Option C is wrong because egress rules do not override ingress rules; they are independent, and the absence of an egress rule does not affect ingress behavior. Option D is wrong because NetworkPolicies do not require an explicit 'deny all' rule; they are additive—if no policy selects a pod, all traffic is allowed, but if a policy selects the pod, only explicitly allowed traffic is permitted (implicit deny).

The problem here is that the policy is not being applied at all.

Full explanation →

496

Multi-Selectmedium

Which THREE components are part of the Gateway API?

Select 3 answers

A.Gateway

B.Service

C.Ingress

D.HTTPRoute

E.GatewayClass

AnswersA, D, E

Gateway is a core resource in the Gateway API that represents the point where external traffic enters the cluster. It defines one or more listeners specifying protocol, port, and hostname, and is bound to a GatewayClass that provides the underlying controller implementation. Gateways are typically managed by cluster operators, not application developers, and serve as the entrypoint for routing traffic to services via attached routes.

Why this answer

The Gateway API is a Kubernetes SIG-Network set of role-oriented, portable, and expressive routing resources, and its core object model consists of GatewayClass, Gateway, and route resources such as HTTPRoute. Option A, Gateway, is correct because it represents a deployed instance of a gateway (a data-plane load balancer/proxy) that listeners and routes attach to. Option D, HTTPRoute, is correct because it is one of the standard route types that defines HTTP/HTTPS routing rules and binds to a Gateway listener.

Option E, GatewayClass, is correct because it is the cluster-scoped template that defines the controller implementation and configuration for Gateways, analogous to IngressClass. Option B, Service, is not part of the Gateway API itself; it is a core Kubernetes resource used for exposing pods and may be referenced as a backend, but it is not a Gateway API component. Option C, Ingress, is not part of the Gateway API; it is the older, separate Kubernetes Ingress resource that the Gateway API is intended to supersede.

Exam trap

In the CKA exam, candidates may confuse the older Ingress API with the newer Gateway API, mistakenly thinking Ingress is part of Gateway API or that Service is a routing resource within Gateway API.

Full explanation →

497

MCQeasy

Which access mode allows a PersistentVolume to be mounted as read-write by multiple pods across different nodes?

A.ReadWriteMany (RWX)

B.ReadWriteOnce (RWO)

C.ReadWriteOncePod (RWOP)

D.ReadOnlyMany (ROX)

AnswerA

ReadWriteMany permits a PersistentVolume to be mounted read-write simultaneously by many pods, including pods scheduled across different nodes. ReadWriteOnce restricts access to a single node, and ReadOnlyMany allows only read access, so RWX satisfies the multi-node write requirement.

Why this answer

ReadWriteMany (RWX) is the correct access mode because it allows a PersistentVolume to be mounted as read-write by multiple pods simultaneously, even when those pods are scheduled on different nodes. This is the only access mode that supports concurrent read-write access across nodes, which is essential for shared storage solutions like NFS, GlusterFS, or CephFS.

Exam trap

The trap here is that candidates often confuse ReadWriteOnce (RWO) with the ability to mount across nodes, not realizing RWO is per-node, not per-pod, and that ReadWriteMany (RWX) is the only mode that explicitly allows multi-node read-write access.

How to eliminate wrong answers

Option B (ReadWriteOnce, RWO) is wrong because it restricts the volume to be mounted as read-write by only a single pod on a single node; any additional pods attempting to mount the same volume will fail. Option C (ReadWriteOncePod, RWOP) is wrong because it further restricts the volume to be mounted by only one pod cluster-wide, regardless of node, and is a Kubernetes 1.22+ feature for preventing concurrent access entirely. Option D (ReadOnlyMany, ROX) is wrong because it allows multiple pods to mount the volume, but only in read-only mode, not read-write.

Full explanation →

498

MCQhard

You have a Service 'my-svc' with ClusterIP None (headless). You create a StatefulSet with 3 replicas and a headless Service. How do you reach individual pods?

A.Use the pod DNS name: <pod-name>.my-svc.<namespace>.svc.cluster.local

B.Use the Service name 'my-svc' which will round-robin between pods

C.Use the Service's ClusterIP (None) to reach all pods

D.You cannot reach individual pods directly; you must use the Service name

AnswerA

When a Service is configured as headless by setting clusterIP to None, CoreDNS automatically creates individual A or AAAA records for each backing Pod that matches the selector. These records are formatted as <pod-name>.<service-name>.<namespace>.svc.cluster.local, allowing clients to bypass the service proxy and resolve the direct IP address of a specific Pod. This mechanism is essential for stateful applications that require direct, addressable communication with individual cluster members.

Why this answer

In a headless Service (ClusterIP: None), Kubernetes creates DNS A/AAAA records for each pod in a StatefulSet using the pattern <pod-name>.<service-name>.<namespace>.svc.cluster.local. This allows direct, stable network identity for each pod, which is essential for stateful applications like databases that require consistent hostnames.

Exam trap

The trap here is that candidates often assume a Service always provides a virtual IP for load balancing, but a headless Service deliberately removes that abstraction to expose individual pod identities directly via DNS.

How to eliminate wrong answers

Option B is wrong because a headless Service (ClusterIP: None) does not perform load balancing or round-robin; it only provides DNS-based pod discovery without a virtual IP. Option C is wrong because the ClusterIP is explicitly set to 'None', meaning there is no ClusterIP to use for reaching pods; attempting to use it would fail. Option D is wrong because you can reach individual pods directly via their pod DNS names, which is the primary purpose of combining a headless Service with a StatefulSet.

Full explanation →

499

MCQhard

You are troubleshooting a connectivity issue between two pods in the same cluster. Pod A cannot reach Pod B's IP. Which command would you run from Pod A to test connectivity?

A.kubectl exec pod-a -- curl <pod-b-ip>

B.kubectl top pod pod-b

C.kubectl logs pod-b

D.kubectl describe pod-b

AnswerA

This command initiates an interactive execution context within the container of pod-a, allowing you to run curl directly from its network namespace. By targeting the IP address of pod-b, you can verify if the Kubernetes network plugin (CNI) is correctly routing traffic between these specific endpoints. It is the most direct way to validate data-plane connectivity from the source pod's perspective.

Why this answer

`kubectl exec pod-a -- curl <pod-b-ip>` runs the `curl` command inside Pod A, directly testing Layer 3 connectivity to Pod B's IP address. This bypasses any service or DNS abstraction and verifies whether the pod network (e.g., CNI plugin like Calico or Flannel) is functioning correctly between the two pods.

Exam trap

The trap here is that candidates may choose `kubectl describe pod-b` (option D) thinking it shows connectivity status, but it only displays static pod metadata and does not perform any active network test.

How to eliminate wrong answers

Option B is wrong because `kubectl top pod pod-b` shows resource usage (CPU/memory) of Pod B, not network connectivity. Option C is wrong because `kubectl logs pod-b` displays Pod B's container logs, which may show application errors but cannot test reachability from Pod A. Option D is wrong because `kubectl describe pod-b` provides metadata and status of Pod B, such as IP and labels, but does not execute any network probe to verify connectivity.

Full explanation →

500

MCQhard

You are troubleshooting a DNS issue. From within a pod, you run 'nslookup kubernetes.default.svc.cluster.local' and get 'connection timed out; no servers could be reached'. What is the most likely cause?

A.The pod's /etc/resolv.conf has incorrect nameservers

B.The node's network plugin is misconfigured

C.The pod's DNS policy is set to 'None'

D.The kube-dns service is not running or is misconfigured

AnswerD

The `kube-dns` (or `CoreDNS`) service is the designated DNS resolver for pods within a Kubernetes cluster, with pods' `/etc/resolv.conf` typically pointing to its ClusterIP. If the underlying `kube-dns` or `CoreDNS` pods are not running, are crashing, or are misconfigured (e.g., resource starvation, incorrect upstream servers), the DNS service IP will be unresponsive to queries. This directly causes DNS resolution attempts from client pods to time out, as queries are sent to the correct IP but receive no response from the non-functional or overloaded DNS server.

Why this answer

The error 'connection timed out; no servers could be reached' from nslookup indicates that the DNS resolver (typically the kube-dns or CoreDNS service) is unreachable. Since the query targets the standard Kubernetes service name 'kubernetes.default.svc.cluster.local', the most likely cause is that the kube-dns service (or its backend pods) is not running or is misconfigured, preventing the pod from resolving cluster-internal DNS names.

Exam trap

The trap here is that candidates confuse DNS resolution failures with network plugin issues, but the specific 'connection timed out' error points to the DNS service itself being unreachable, not to a general network misconfiguration.

How to eliminate wrong answers

Option A is wrong because if the pod's /etc/resolv.conf had incorrect nameservers, the error would typically be 'server can't find ...' or 'no answer', not a connection timeout; a timeout suggests the DNS server IP is unreachable, not that it's misconfigured. Option B is wrong because a misconfigured node network plugin would cause broader connectivity issues (e.g., pod-to-pod or pod-to-service failures) rather than a DNS-specific timeout; DNS relies on the network plugin only for basic IP reachability, not for DNS resolution logic. Option C is wrong because setting the pod's DNS policy to 'None' would result in an empty /etc/resolv.conf, leading to an immediate 'no servers could be reached' or 'failure: no nameservers' error, not a timeout after attempting to reach servers.

Full explanation →

501

MCQeasy

Which NetworkPolicy rule will allow ingress traffic from pods with label 'role: frontend' in the same namespace?

A.ingress: - from: - podSelector: matchLabels: role: frontend

B.ingress: - from: - ipBlock: cidr: 0.0.0.0/0

C.egress: - to: - podSelector: matchLabels: role: frontend

D.ingress: - from: - namespaceSelector: matchLabels: role: frontend

AnswerA

The `from` section with a `podSelector` selects source pods by their labels, and because the selector is placed directly under `ingress`, it governs inbound traffic. This rule allows traffic only from pods in the same namespace that carry the label `role: frontend`, which is exactly the intended behavior. It correctly targets pod identity rather than IP ranges or namespace identity, making it the right choice.

Why this answer

A NetworkPolicy ingress rule with a `podSelector` matches pods in the same namespace as the policy. By specifying `matchLabels: role: frontend`, it allows inbound traffic from any pod in the same namespace that has that label, which is exactly what the question requires.

Exam trap

The trap here is that candidates often confuse `podSelector` (which selects pods in the same namespace) with `namespaceSelector` (which selects namespaces), or they mistakenly choose an egress rule when the question explicitly asks for ingress traffic.

How to eliminate wrong answers

Option B is wrong because `ipBlock: 0.0.0.0/0` allows ingress traffic from any IP address, not just from pods with the label `role: frontend`. Option C is wrong because it defines an `egress` rule (outbound traffic), not an ingress rule, and the question specifically asks for ingress traffic. Option D is wrong because `namespaceSelector` matches entire namespaces based on their labels, not pods within the same namespace; it would allow traffic from pods in any namespace that has the label `role: frontend`, which is broader and not restricted to the same namespace.

Full explanation →

502

MCQmedium

A pod is in the 'Pending' state for a long time. You run 'kubectl describe pod pending-pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, 3 node(s) had taint {node-role.kubernetes.io/control-plane: } that the pod didn't tolerate.' What is the MOST likely solution?

A.Remove the taint from the control-plane nodes

B.Delete the pod and recreate it

C.Increase the pod's resource requests

D.Add tolerations to the pod for the control-plane taint

AnswerD

Adding tolerations to the pod's manifest is the correct solution because taints repel pods unless those pods have a matching toleration. Control-plane nodes are typically tainted to prevent general workloads from running on them. By adding a toleration that matches the control-plane node's taint (e.g., `key: node-role.kubernetes.io/control-plane`, `operator: Exists`, `effect: NoSchedule`), the pod explicitly signals to the scheduler that it is permitted to be scheduled on such nodes, resolving the `Pending` state.

Why this answer

The pod is stuck in 'Pending' because it cannot be scheduled. The event shows that 3 control-plane nodes have the 'node-role.kubernetes.io/control-plane' taint, which by default prevents non-tolerant pods from scheduling on them. Adding the corresponding toleration to the pod's spec allows it to be scheduled on those nodes, resolving the pending state.

Exam trap

The trap here is that candidates often confuse taints/tolerations with node affinity or resource constraints, leading them to choose resource-related fixes or node modifications instead of adding the correct toleration to the pod spec.

How to eliminate wrong answers

Option A is wrong because removing the taint from control-plane nodes would allow all pods to schedule on them, which is not the intended solution for a specific pod and could compromise cluster security or workload isolation. Option B is wrong because deleting and recreating the pod without changing its configuration will result in the same scheduling failure, as the taint and lack of toleration remain unchanged. Option C is wrong because increasing resource requests does not address the taint-based scheduling restriction; resource constraints would produce a different event message (e.g., 'Insufficient cpu/memory').

Full explanation →

503

MCQmedium

You need to drain a node 'node1' and ensure that pods are evicted gracefully. Which command should you use?

A.kubectl delete node node1

B.kubectl cordon node1

C.kubectl taint node node1 key=value:NoSchedule

D.kubectl drain node1

AnswerD

`kubectl drain node1` first marks the node unschedulable (cordon) and then evicts all non-daemonset, non-mirror Pods via the Eviction API, gracefully terminating them while respecting PodDisruptionBudgets. It is the correct way to prepare a node for maintenance because it actually removes the Pods and reschedules them on other available nodes.

Why this answer

`kubectl drain node1` safely evicts all pods from the node while respecting PodDisruptionBudgets (PDBs) and graceful termination periods. It cordons the node first (marking it unschedulable) and then evicts pods, ensuring that workloads are rescheduled on other nodes without disruption.

Exam trap

The trap here is that candidates often confuse `cordon` (which only prevents new pods) with `drain` (which evicts existing pods), leading them to select option B as a quick fix without understanding that existing workloads remain running.

How to eliminate wrong answers

Option A is wrong because `kubectl delete node node1` removes the node object from the cluster but does not evict pods gracefully; pods may be left orphaned or abruptly terminated. Option B is wrong because `kubectl cordon node1` only marks the node as unschedulable, preventing new pods from being scheduled, but does not evict existing pods. Option C is wrong because `kubectl taint node node1 key=value:NoSchedule` adds a taint that prevents future pod scheduling but does not evict currently running pods.

Full explanation →

504

MCQhard

You are performing a backup of etcd using the command: 'ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db'. You get an error: 'Error: context deadline exceeded'. What is the most likely cause?

A.The endpoint flag is missing or incorrect, causing the client to timeout trying to connect

B.The etcdctl version is incompatible with etcd

C.The etcd cluster is not running

D.The snapshot file already exists and is locked

AnswerA

When etcdctl attempts to connect to the etcd cluster without a specified --endpoints flag, it defaults to localhost:2379. In many Kubernetes environments, etcd runs on a dedicated control plane node, often with a different IP address, or behind a firewall, or even on a non-standard port. If the client cannot establish a connection to the default or specified endpoint within the configured timeframe, the operation will result in a "context deadline exceeded" or similar timeout error, indicating that the server did not respond to the connection attempt. This is distinct from an active refusal.

Why this answer

The error 'context deadline exceeded' indicates that the etcdctl client attempted to connect to the etcd endpoint but the request timed out before a connection could be established. This is most commonly caused by the --endpoints flag being omitted or pointing to an incorrect address (e.g., localhost:2379 instead of the actual etcd listener), so the client cannot reach the etcd server within the default timeout period.

Exam trap

The trap here is that candidates may assume the error is due to the cluster being down or a file lock, but the 'deadline exceeded' message specifically points to a network connectivity or endpoint misconfiguration issue, not a server-side unavailability or filesystem problem.

How to eliminate wrong answers

Option B is wrong because an incompatible etcdctl version typically produces a different error, such as 'etcdserver: api version mismatch' or 'rpc error: code = Unimplemented', not a context deadline exceeded. Option C is wrong because if the etcd cluster is not running, the client would receive a 'connection refused' error immediately, not a timeout after a deadline. Option D is wrong because a locked or existing snapshot file would cause a file write error (e.g., 'file exists' or 'permission denied'), not a network-level timeout error.

Full explanation →

505

MCQeasy

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

A.A records for each pod IP backing the Service

B.No DNS record

C.A CNAME record pointing to an external DNS

D.An A record for the Service IP (ClusterIP)

AnswerA

When a Service is configured as headless by setting spec.clusterIP to None, CoreDNS bypasses the creation of a single virtual IP record. Instead, it directly generates individual A or AAAA records mapping the Service's fully qualified domain name to the IP addresses of all ready backend pods selected by the Service. This allows clients to perform direct peer-to-peer communication or implement custom client-side load balancing.

Why this answer

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

Exam trap

The trap here is that candidates often assume headless Services create no DNS records or that they use a ClusterIP-based A record, but CoreDNS actually creates A records for each pod IP, not for a virtual Service IP, which is a key distinction for stateful applications.

How to eliminate wrong answers

Option B is wrong because CoreDNS does create DNS records for headless Services — specifically A records for each pod IP, not no records at all. Option C is wrong because headless Services do not use CNAME records to point to external DNS; CNAME records are used for external name resolution or Service aliases, not for headless Services. Option D is wrong because headless Services have no ClusterIP (set to None), so there is no A record for a Service IP; instead, A records are created for the individual pod IPs.

Full explanation →

506

MCQeasy

Which of the following is the default DNS name for a Service named 'api' in namespace 'production'?

A.api.production.cluster.local

B.api.production.svc.cluster.local

C.production.api.svc.cluster.local

D.api.svc.production.cluster.local

AnswerB

This is the canonical fully qualified Domain Name (FQDN) for a Service. For a Service named `api` in Namespace `production`, CoreDNS registers an A record at `api.production.svc.cluster.local` using the standard schema `<service-name>.<namespace>.svc.<cluster-domain>`. Pods inside the cluster can resolve this name to the Service's ClusterIP, making it the default and correct Service DNS name.

Why this answer

In Kubernetes, the default DNS name for a Service follows the pattern `<service>.<namespace>.svc.cluster.local`. For a Service named 'api' in namespace 'production', this resolves to `api.production.svc.cluster.local`. The `svc` subdomain is a fixed component that distinguishes Service DNS records from Pod DNS records, and `cluster.local` is the default cluster domain.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or confuse the order of namespace and service name, leading them to choose options like A or C, which omit or misplace the `svc` component.

How to eliminate wrong answers

Option A is wrong because it omits the required `svc` subdomain, which is part of the standard DNS schema for Services. Option C is wrong because it reverses the order of the Service name and namespace, placing the namespace before the Service name, which does not match the Kubernetes DNS specification. Option D is wrong because it places `svc` after the namespace and before the cluster domain, whereas the correct order is `<service>.<namespace>.svc.cluster.local`.

Full explanation →

507

MCQhard

A pod is in Pending state. You run 'kubectl describe pod pending-pod' and see an event: '0/3 nodes are available: 3 Insufficient memory'. However, you believe there is enough memory across the cluster. What could be the issue?

A.The pod's memory request is higher than any node's allocatable memory

B.The cluster is using a resource quota that is exhausted

C.The pod's memory limit is set too low

D.The nodes have taints that the pod does not tolerate

AnswerA

The pod's memory request is higher than any node's allocatable memory. The Kubernetes scheduler performs a feasibility check for each node, comparing the pod's sum of memory requests against the node's allocatable memory (which excludes reserved system resources). If no node can satisfy this request, the scheduler cannot bind the pod, leaving it in Pending state. The `kubectl describe` output would include events such as "0/3 nodes are available: insufficient memory" or "Fit failed" for all nodes, directly indicating that the request exceeds every node's capacity.

Why this answer

The '0/3 nodes are available: 3 Insufficient memory' event indicates that the scheduler could not place the pod because each node lacks enough allocatable memory to satisfy the pod's memory request. Even if the cluster has plenty of total memory, the scheduler evaluates each node individually against the pod's resource requests, not the cluster-wide sum. Therefore, if the pod's memory request exceeds the allocatable memory on every node, the pod will remain Pending.

Exam trap

The trap here is that candidates confuse cluster-wide total memory with per-node allocatable memory, assuming that if the sum of free memory across all nodes is sufficient, the pod should schedule — but the scheduler only considers individual node capacity, not aggregated cluster memory.

How to eliminate wrong answers

Option B is wrong because a resource quota limits total resource consumption within a namespace, but the scheduler error specifically says 'Insufficient memory' on nodes, not a quota violation (which would show a different event like 'exceeded quota'). Option C is wrong because a memory limit that is set too low does not prevent scheduling; limits are enforced at runtime by the kubelet, not by the scheduler, and a low limit would cause OOM kills, not a Pending state. Option D is wrong because taints and tolerations produce a different scheduler event: '0/3 nodes are available: 3 node(s) had taint {key: value} that the pod didn't tolerate', not an 'Insufficient memory' message.

Full explanation →

508

MCQmedium

An administrator runs 'kubectl cordon node1' and then 'kubectl drain node1 --ignore-daemonsets'. What is the effect on node1?

A.Node1 is marked as unschedulable and all pods except DaemonSets are evicted

B.Node1 is marked as unschedulable but no pods are evicted

C.New pods are scheduled onto node1 and existing pods are evicted

D.Node1 is marked as schedulable and all pods are evicted

AnswerA

The `kubectl cordon node1` command initially marks `node1` as unschedulable, preventing the Kubernetes scheduler from placing any new pods on it. Subsequently, `kubectl drain node1` proceeds to gracefully evict all existing pods from the node. By default, or with the `--ignore-daemonsets` flag, pods managed by DaemonSets are typically not evicted during a drain operation, as they are designed to run one instance per node. This combined action prepares the node for maintenance without disrupting critical system services.

Why this answer

The `kubectl cordon node1` command marks node1 as unschedulable, preventing new pods from being scheduled onto it. The subsequent `kubectl drain node1 --ignore-daemonsets` command evicts all pods from node1 except DaemonSets (which are ignored because they are managed by the DaemonSet controller and typically need to run on every node). This combination makes node1 unschedulable and removes all non-DaemonSet pods, preparing the node for maintenance.

Exam trap

The trap here is that candidates often confuse `cordon` (which only marks the node unschedulable) with `drain` (which evicts pods), or mistakenly think `--ignore-daemonsets` means no pods are evicted at all, when in fact it only excludes DaemonSet pods from eviction.

How to eliminate wrong answers

Option B is wrong because the drain command with `--ignore-daemonsets` does evict pods (except DaemonSets), not just mark the node unschedulable. Option C is wrong because the cordon command marks the node as unschedulable, so new pods are not scheduled onto node1; additionally, the drain command evicts existing pods, not schedules new ones. Option D is wrong because cordon marks the node as unschedulable, not schedulable, and the drain command evicts all pods except DaemonSets, not all pods.

Full explanation →

509

Multi-Selectmedium

Which TWO of the following are correct methods to check the health of the kube-apiserver?

Select 2 answers

A.Run 'kubectl top nodes'

B.Run 'systemctl status kube-apiserver'

C.Run 'kubectl get pods -n kube-system -l component=kube-apiserver'

D.Run 'journalctl -u kubelet'

E.Run 'curl -k https://localhost:6443/healthz'

AnswersC, E

The kube-apiserver runs as a static pod in the kube-system namespace, labelled component=kube-apiserver on kubeadm clusters, so listing pods with that label selector reveals its phase and restart count. This checks control-plane health through the API itself.

Why this answer

Option C is correct because kube-apiserver typically runs as a static pod in the kube-system namespace, so 'kubectl get pods -n kube-system -l component=kube-apiserver' lets you verify the pod's status, readiness, and restart count. Option E is correct because the kube-apiserver exposes a /healthz endpoint on its secure port (6443 by default), and 'curl -k https://localhost:6443/healthz' returns 'ok' when the API server is healthy. Option A is wrong because 'kubectl top nodes' reports CPU and memory usage from metrics-server, not API server health.

Option B is wrong because kube-apiserver is usually a static pod managed by the kubelet, not a systemd unit, so 'systemctl status kube-apiserver' would typically fail. Option D is wrong because 'journalctl -u kubelet' shows kubelet logs, which may reveal pod issues but does not directly check the kube-apiserver's health.

Exam trap

On the CKA exam, remember that control plane components (kube-apiserver, kube-controller-manager, kube-scheduler, etcd) in a kubeadm cluster run as static pods. Do not attempt to manage or check them using `systemctl`. Only the `kubelet` and container runtime (e.g., `containerd`) run as systemd services on the nodes.

Full explanation →

510

MCQeasy

An administrator needs to initialize a new Kubernetes control plane node using kubeadm. Which of the following is the correct command to initialize the control plane with a specific pod network CIDR of 10.244.0.0/16?

A.kubeadm init --pod-network-cidr=10.244.0.0/16

B.kubeadm init --cidr=10.244.0.0/16

C.kubeadm init --network-cidr=10.244.0.0/16

D.kubeadm init --service-cidr=10.244.0.0/16

AnswerA

This option is correct because kubeadm's --pod-network-cidr flag defines the IPv4 CIDR range from which pod IP addresses are allocated. It is required when installing a pod network add-on such as Flannel, which commonly expects the 10.244.0.0/16 range. The kube-controller-manager then uses this range to assign per-node subnets, enabling cross-node pod communication.

Why this answer

`kubeadm init` uses the `--pod-network-cidr` flag to specify the CIDR range for the pod network, which is required by many CNI plugins (e.g., Flannel defaults to 10.244.0.0/16). This flag tells kubeadm to configure the control plane components (like the controller manager) to allocate pod IPs from this range.

Exam trap

The trap here is confusing `--pod-network-cidr` with `--service-cidr` or inventing flags like `--cidr` or `--network-cidr`, leading candidates to pick options that either do not exist or configure the wrong network range.

How to eliminate wrong answers

Option B is wrong because `--cidr` is not a valid flag for `kubeadm init`; it is used by other tools like `kube-proxy` or `kubectl` but not for initializing the control plane. Option C is wrong because `--network-cidr` is not a recognized flag in kubeadm; the correct flag is `--pod-network-cidr`. Option D is wrong because `--service-cidr` specifies the CIDR for Kubernetes services (default 10.96.0.0/12), not the pod network; using it for pod CIDR would misconfigure the cluster.

Full explanation →

511

MCQmedium

A pod uses a PersistentVolumeClaim named 'claim-log'. The PVC is pending. You run 'kubectl describe pvc claim-log' and see the event: 'waiting for a volume to be created, either by external provisioner or manually'. The StorageClass 'standard' has provisioner: 'kubernetes.io/no-provisioner'. What is the most likely cause?

A.The StorageClass 'standard' does not have a dynamic provisioner configured

B.The StorageClass is missing the volumeBindingMode

C.The PVC's access mode is incompatible with the StorageClass

D.The PVC requires a larger storage size than any available PV

AnswerA

When a StorageClass uses 'kubernetes.io/no-provisioner' as its provisioner, Kubernetes cannot automatically create a backing PersistentVolume (PV) when a PersistentVolumeClaim (PVC) is submitted. This requires an administrator to manually pre-create a matching PV with the correct storage capacity, access modes, and storageClassName before the PVC can transition from Pending to Bound.

Why this answer

The StorageClass 'standard' has provisioner: 'kubernetes.io/no-provisioner', which is a static provisioner that does not automatically create volumes. Since the PVC is pending with the event 'waiting for a volume to be created, either by external provisioner or manually', it indicates that no dynamic provisioner is available to automatically provision a PersistentVolume (PV) for the PVC. The most likely cause is that the StorageClass lacks a dynamic provisioner, so a PV must be manually created or an external provisioner must be configured.

Exam trap

A common pitfall in the CKA exam is assuming that a StorageClass with 'kubernetes.io/no-provisioner' can automatically provision volumes. This provisioner indicates static provisioning only; a PersistentVolume must be created manually or by an external provisioner. Candidates often overlook this and expect dynamic provisioning to occur.

How to eliminate wrong answers

Option B is wrong because volumeBindingMode (e.g., Immediate or WaitForFirstConsumer) affects when binding occurs, not whether a volume can be provisioned; the PVC would still wait for a volume even with volumeBindingMode set. Option C is wrong because access mode incompatibility would typically result in a different event, such as 'FailedBinding' or 'no persistent volumes available', not the specific event about waiting for a volume to be created. Option D is wrong because if the PVC required a larger size than any available PV, the event would likely indicate 'no persistent volumes available for this claim' or a similar binding failure, not a waiting state for volume creation.

Full explanation →

512

MCQmedium

You need to back up etcd data for a cluster with etcd running as a static Pod. Which command should you use?

A.kubectl cp etcd-master:/var/lib/etcd /backup/

B.etcdctl snapshot save /backup/snapshot.db

C.kubectl exec -n kube-system etcd-master -- etcdctl snapshot save /backup/snapshot.db

D.ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /backup/snapshot.db

AnswerD

This command correctly sets the ETCDCTL_API=3 environment variable to use the modern v3 API required for snapshots. It also provides the necessary loopback endpoint and references the correct CA certificate, client certificate, and private key paths to successfully authenticate via mutual TLS (mTLS) against the secure etcd member.

Why this answer

It uses the `etcdctl` command with the required API version 3, specifies the etcd endpoint, and provides the necessary TLS certificates (CA, server cert, and key) to authenticate to the etcd server. When etcd runs as a static Pod, it uses TLS for client-server communication, so these flags are mandatory for a successful snapshot.

Exam trap

The trap here is that candidates often forget to include the TLS certificates and endpoint flags when using `etcdctl`, assuming the command will work with defaults, or they mistakenly think `kubectl cp` can produce a valid etcd backup.

How to eliminate wrong answers

Option A is wrong because `kubectl cp` copies files from a Pod's filesystem, but it cannot be used to take a consistent etcd snapshot; copying the data directory while etcd is running can result in a corrupted or inconsistent backup. Option B is wrong because it omits the `--endpoints` and TLS flags, so it will fail to connect to the secured etcd endpoint (which uses HTTPS on port 2379). Option C is wrong because it runs `etcdctl` inside the etcd container without specifying the endpoint or TLS certificates; the default `etcdctl` configuration inside the container may not have the correct environment or credentials, and the command will likely fail due to authentication errors.

Full explanation →

513

MCQmedium

A cluster administrator needs to create a PersistentVolume that can be mounted as a block device (not a filesystem) by a Pod. Which field in the PersistentVolume spec must be set to enable this?

A.persistentVolumeReclaimPolicy: Retain

B.volumeMode: Filesystem

C.accessModes: ReadWriteOnce

D.volumeMode: Block

AnswerD

Setting `volumeMode: Block` in a PersistentVolume definition instructs Kubernetes to expose the underlying storage resource as a raw block device directly to the consuming pod. This bypasses the traditional filesystem layer, allowing applications to perform direct I/O operations on the unformatted volume. This capability is crucial for high-performance applications like databases or custom storage engines that require fine-grained control over storage, making it the correct choice for providing a raw block device.

Why this answer

Setting `volumeMode: Block` in the PersistentVolume spec specifies that the volume is to be presented as a raw block device, without a filesystem. This allows a Pod to mount the volume as a block device (e.g., `/dev/sdb`) rather than a mounted directory, which is required for applications that need direct access to the underlying storage, such as databases or custom storage engines.

Exam trap

The trap here is that candidates often confuse `volumeMode` with `accessModes` or `persistentVolumeReclaimPolicy`, assuming that access modes or reclaim policies control the block device behavior, when in fact only `volumeMode: Block` enables raw block volume mounting.

How to eliminate wrong answers

Option A is wrong because `persistentVolumeReclaimPolicy: Retain` controls what happens to the PV when the PVC is released (e.g., retain, recycle, delete), not how the volume is presented to the Pod. Option B is wrong because `volumeMode: Filesystem` is the default mode that creates a filesystem on the volume, which is the opposite of what is needed for a block device mount. Option C is wrong because `accessModes: ReadWriteOnce` defines the access mode (e.g., single node read-write), not the volume mode; it does not enable block device mounting.

Full explanation →

514

MCQhard

You have a kubeconfig file with multiple contexts. You want to temporarily switch to a different context for a single kubectl command. Which flag should you use?

A.--context

B.--user

C.--cluster

D.--kubeconfig

AnswerA

The `--context` flag allows you to temporarily override the active context defined in your kubeconfig for a single `kubectl` execution. This is highly useful for executing commands against a different environment (like production or staging) without permanently changing your active context via `kubectl config use-context`. It targets the specific combination of cluster, user, and namespace defined under that named context.

Why this answer

The `--context` flag allows you to override the current context from the kubeconfig file for a single kubectl command. This is the correct way to temporarily switch contexts without modifying the kubeconfig file's current-context field. The flag accepts the context name as defined in the kubeconfig's contexts array.

Exam trap

The trap here is that candidates confuse `--context` with `--kubeconfig` or `--cluster`, thinking they need to specify the file or cluster directly, when the correct approach is to use the context name that bundles cluster, user, and namespace together.

How to eliminate wrong answers

Option B is wrong because `--user` specifies the user credential to use for authentication, not the context; it does not change the cluster or namespace. Option C is wrong because `--cluster` specifies the cluster endpoint to target, but it does not include the associated user or namespace, so it cannot fully define a context. Option D is wrong because `--kubeconfig` specifies an alternative kubeconfig file to use, not a context switch within the current file.

Full explanation →

515

Multi-Selectmedium

Which TWO of the following are valid commands to view cluster events sorted by timestamp?

Select 2 answers

A.kubectl get events

B.kubectl get events --sort-by=.metadata.creationTimestamp

C.kubectl get events -w

D.kubectl get events --sort-by=.metadata.name

E.kubectl get events --all-namespaces

AnswersA, B

kubectl get events is correct because the default output of the events command is already sorted by lastTimestamp, the moment each event was last observed, from most to least recent. This gives an effective chronological view without needing extra flags, satisfying the requirement to view events sorted by a time field.

Why this answer

Options A and B are correct. 'kubectl get events' shows events sorted by last timestamp by default, which satisfies the requirement. 'kubectl get events --sort-by=.metadata.creationTimestamp' explicitly sorts by creation timestamp, also valid. Option C uses -w to watch, not sort. Option D sorts by name, not timestamp.

Option E shows events from all namespaces but does not sort by timestamp.

Full explanation →

516

MCQeasy

Which command displays the expiration date of all certificates managed by kubeadm?

A.kubeadm certs check-expiration

B.kubeadm alpha certs check-expiration

C.kubeadm certs list

D.kubectl get certificates

AnswerA

kubeadm certs check-expiration is the official command that reads the X.509 certificates under /etc/kubernetes/pki and prints a table containing each certificate's common name, expiry date, and residual time. It also highlights certificates that are already expired or about to expire, allowing administrators to plan a kubeadm certificate renew or upgrade. This is the only command that directly answers the question of certificate expiration for kubeadm-managed clusters.

Why this answer

`kubeadm certs check-expiration` is the dedicated command in kubeadm v1.15+ that inspects the expiration dates of all certificates managed by kubeadm, including those for the API server, kubelet, and etcd. It reads certificate files from `/etc/kubernetes/pki/` and displays their remaining validity period in a human-readable table.

Exam trap

The trap here is that candidates confuse `kubeadm` certificate management commands with `kubectl` CSR resources, or assume an outdated `alpha` subcommand is still valid, leading them to pick B or D instead of the correct A.

How to eliminate wrong answers

Option B is wrong because `kubeadm alpha certs check-expiration` was deprecated in kubeadm v1.15 and removed in v1.20; the `alpha` subcommand no longer exists in current versions, making this command invalid. Option C is wrong because `kubeadm certs list` is not a valid kubeadm subcommand; the correct verb is `check-expiration`, not `list`. Option D is wrong because `kubectl get certificates` targets Kubernetes CertificateSigningRequest (CSR) resources, not the static certificate files managed by kubeadm; it shows CSR status, not expiration dates of the actual X.509 certificates on disk.

Full explanation →

517

MCQhard

A cluster uses a CSI driver for dynamic provisioning. An administrator creates a StorageClass with 'volumeBindingMode: WaitForFirstConsumer' and a PVC. The pod using the PVC is scheduled to a node. However, the PV is never provisioned. What is the most likely cause?

A.The PVC is not bound to a PV because no PV exists.

B.The CSI driver is not installed or malfunctioning.

C.The pod does not have the correct node selector.

D.The StorageClass uses 'Immediate' binding mode.

AnswerB

The StorageClass references a CSI provisioner (e.g., csi.contoso.com), and Kubernetes relies on the external-provisioner sidecar to send CreateVolume RPCs to the CSI driver controller. If that driver controller is not installed, the DaemonSet pods are CrashLooping, or the CSI socket is unavailable, the provisioner cannot create the backend volume, so no PV is bound and the PVC remains Pending with events like 'Failed to provision volume with storage class'. Inspecting the csi-controller logs and the driver DaemonSet status will confirm the malfunction.

Why this answer

When `volumeBindingMode: WaitForFirstConsumer` is set, the PV is not provisioned until a pod using the PVC is scheduled to a node. If the PV is never provisioned after scheduling, the most likely cause is that the CSI driver is not installed or malfunctioning, because the dynamic provisioning request is sent to the CSI driver, and without a functioning driver, the PV creation will fail silently or not occur at all.

Exam trap

The trap here is that candidates may assume 'WaitForFirstConsumer' delays binding indefinitely or that a missing PV is the root cause, rather than recognizing that dynamic provisioning requires a functioning CSI driver to create the PV after scheduling.

How to eliminate wrong answers

Option A is wrong because dynamic provisioning creates a PV on demand; the absence of a pre-existing PV is expected and not a problem. Option C is wrong because the pod's node selector does not affect the CSI driver's ability to provision the PV; the issue is with the driver itself. Option D is wrong because the StorageClass explicitly uses 'WaitForFirstConsumer' binding mode, not 'Immediate', so this option describes a configuration that is not present.

Full explanation →

518

MCQmedium

A node in your cluster is in the 'NotReady' state. You SSH into the node and run 'systemctl status kubelet' which shows the kubelet is active but not functioning correctly. Which command should you use to get detailed logs to troubleshoot the kubelet?

A.kubectl describe node <node-name>

B.journalctl -u kubelet

C.kubectl logs kubelet -n kube-system

D.systemctl restart kubelet

AnswerB

Because the kubelet typically runs as a systemd service on the host operating system rather than as a containerized pod, its logs are managed by systemd-journald. Running `journalctl -u kubelet` allows you to view the service's standard output and error streams directly on the node. This is the standard method for diagnosing startup failures, certificate issues, or connection timeouts to the control plane.

Why this answer

`journalctl -u kubelet` retrieves the systemd journal logs specifically for the kubelet service, which is the standard way to access detailed, timestamped logs when the kubelet is running but malfunctioning. Since the kubelet is active (not stopped), its logs are captured by systemd and can be inspected without restarting the service, preserving the current state for troubleshooting.

Exam trap

The trap here is that candidates confuse the kubelet (a systemd service) with a Kubernetes pod and incorrectly choose `kubectl logs`, not realizing that the kubelet is not managed by the Kubernetes API server and its logs must be accessed via the node's system journal.

How to eliminate wrong answers

Option A is wrong because `kubectl describe node` shows cluster-level node status and conditions from the control plane's perspective, not the kubelet's detailed logs; it relies on the node being reachable and the kubelet reporting, which may be stale or incomplete when the node is NotReady. Option C is wrong because `kubectl logs` retrieves container logs from a pod, not the kubelet binary's logs; the kubelet runs as a systemd service, not as a pod in the kube-system namespace, so this command would fail or return unrelated output. Option D is wrong because `systemctl restart kubelet` restarts the service, which may temporarily fix the issue but destroys the current log buffer and prevents diagnosis of the root cause; it is a recovery action, not a diagnostic command.

Full explanation →

519

MCQmedium

A node in your cluster shows status 'NotReady'. You have SSH access to the node. What is the first command you should run to check the kubelet status?

A.systemctl status docker (or containerd)

B.cat /var/log/kubelet.log

C.systemctl status kubelet

D.journalctl -u kubelet

AnswerC

The kubelet is the primary node agent that communicates with the Kubernetes control plane to report node status and heartbeat. Running systemctl status kubelet immediately reveals whether the service is active, inactive, or failing, which is the most direct and efficient first step when troubleshooting a NotReady node via SSH.

Why this answer

When a node is NotReady, the first step is to check if the kubelet service is running, because the kubelet is the primary agent responsible for reporting node status to the control plane. Running `systemctl status kubelet` immediately shows whether the kubelet service is active, failed, or stopped, along with recent log snippets, making it the fastest diagnostic command.

Exam trap

The trap here is that candidates often jump to checking logs (option B or D) first, but the CKA exam expects you to follow a systematic troubleshooting hierarchy: start with service status, then logs, then runtime checks.

How to eliminate wrong answers

Option A is wrong because checking the container runtime (docker or containerd) is a secondary step; the node status is reported by the kubelet, not the runtime, and a runtime failure would manifest as pod issues, not necessarily a NotReady node. Option B is wrong because reading the full kubelet log file is a deeper investigation step after confirming the service status; it is not the first command and can be time-consuming. Option D is wrong because `journalctl -u kubelet` provides detailed logs but is more verbose and slower than `systemctl status kubelet` for an initial health check; the first command should be the service status command to quickly see if the kubelet is running or failed.

Full explanation →

520

MCQhard

You need to back up etcd on a single control plane node. Which command correctly creates a snapshot?

A.ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 snapshot save /backup/etcd-snapshot.db

B.ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db

C.etcdctl snapshot save /backup/etcd-snapshot.db

AnswerD

This is the correct backup command: it forces the v3 API, explicitly connects to the local etcd endpoint via HTTPS, and supplies the CA certificate and client certificate/key from the standard kubeadm PKI paths. Those credentials satisfy etcd's mutual TLS requirement and allow a verified snapshot to be written to /backup/etcd-snapshot.db.

Why this answer

It uses the required `ETCDCTL_API=3` environment variable and specifies the necessary TLS client certificates (`--cacert`, `--cert`, `--key`) to authenticate to the etcd server, which by default listens on `https://127.0.0.1:2379` with mutual TLS enabled. The `snapshot save` command creates a point-in-time backup of the etcd data store, essential for disaster recovery in a Kubernetes control plane.

Exam trap

The trap here is that candidates often forget the TLS certificates or the `ETCDCTL_API=3` variable, assuming a simple `etcdctl snapshot save` will work, but the CKA exam environment enforces secure connections requiring full authentication flags.

How to eliminate wrong answers

Option A is wrong because it omits the required TLS certificate flags (`--cacert`, `--cert`, `--key`), so the command will fail with a certificate verification error when connecting to the etcd server over HTTPS. Option B is wrong because `snapshot restore` is used to restore a snapshot to a new data directory, not to create a backup; it does not produce a snapshot file. Option C is wrong because it lacks both the `ETCDCTL_API=3` environment variable (which enables the v3 API) and the required TLS flags, and it does not specify the endpoint, so it defaults to the v2 API and will fail to connect.

Full explanation →

521

MCQeasy

Which component is responsible for maintaining network rules on each worker node to enable service discovery and load balancing?

A.kube-controller-manager

B.CoreDNS

C.kube-proxy

D.kubelet

AnswerC

kube-proxy is the network agent running on each node that implements the Kubernetes Service abstraction. It watches the API server for changes to Service and EndpointSlice objects, translating them into local OS-level network rules using backends like iptables, IPVS, or eBPF to forward traffic to the correct backend Pods.

Why this answer

kube-proxy is the component responsible for maintaining network rules on each worker node. It implements the Kubernetes Service concept by managing IP tables or IPVS rules to route traffic to the correct Pods, enabling service discovery and load balancing across Pod endpoints.

Exam trap

The trap here is confusing the responsibility for DNS-based service discovery (CoreDNS) with the responsibility for network-level traffic routing and load balancing (kube-proxy), leading candidates to incorrectly select CoreDNS.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager runs controller loops (e.g., ReplicaSet, Node, Endpoint controllers) but does not directly manage per-node network rules or packet forwarding. Option B is wrong because CoreDNS provides service discovery via DNS name resolution (e.g., translating service names to ClusterIPs) but does not enforce network rules or perform load balancing of traffic. Option D is wrong because kubelet is the primary node agent that registers nodes, manages Pod lifecycle, and reports node status, but it does not handle network rule maintenance or traffic routing.

Full explanation →

522

MCQmedium

You want to expose an application running in the cluster on a public IP address. Which Service type should you use?

A.NodePort

B.LoadBalancer

C.ExternalName

D.ClusterIP

AnswerB

LoadBalancer is the Service type that provisions an external load balancer—often via your cloud provider's API—and assigns it a stable public IP address. It automatically routes incoming traffic to the Service's endpoints and performs health checks, so it is the direct way to expose an application to the internet without manual configuration. This is exactly what is required when "exposing an application running in the cluster" means giving it a routable external endpoint.

Why this answer

The LoadBalancer service type provisions an external load balancer (e.g., from a cloud provider) that assigns a public IP address to the service, directing external traffic to the application pods. This is the correct choice when you need a publicly accessible IP address without manual node-level configuration.

Exam trap

The trap here is that candidates often confuse NodePort with a public IP solution, forgetting that NodePort only exposes the service on node IPs, which are typically private and require an additional load balancer or ingress for public access.

How to eliminate wrong answers

Option A (NodePort) is wrong because it exposes the service on a static port on each node's IP address, but the node IPs are often private or not directly accessible from the internet without additional routing or a load balancer. Option C (ExternalName) is wrong because it maps the service to an external DNS name (via CNAME records) and does not expose any internal pods or provide a public IP address. Option D (ClusterIP) is wrong because it exposes the service only on a cluster-internal IP address, which is unreachable from outside the cluster.

Full explanation →

523

Multi-Selecthard

You need to grant a ServiceAccount named 'monitor-sa' in namespace 'monitoring' the ability to read Pods and Services across all namespaces. Which TWO resources are needed? (Choose TWO.)

Select 2 answers

A.ClusterRoleBinding binding the ClusterRole to the ServiceAccount

B.ServiceAccount token secret

C.ClusterRole with rules for pods and services

D.RoleBinding in each namespace

E.Role in the 'monitoring' namespace

AnswersA, C

A ClusterRoleBinding is required to apply the permissions defined in a ClusterRole to a subject, such as a ServiceAccount, globally across the entire Kubernetes cluster. This binding mechanism ensures that the ServiceAccount can access resources like pods and services in all namespaces without needing individual namespace-scoped RoleBindings. It is the standard RBAC resource for granting cluster-wide authorization.

Why this answer

Option C is correct because reading Pods and Services across all namespaces requires a ClusterRole, which is a cluster-scoped resource whose rules (e.g., apiGroups: [""], resources: ["pods", "services"], verbs: ["get", "list", "watch"]) apply across the entire cluster. Option A is correct because a ClusterRole alone grants nothing; a ClusterRoleBinding must bind that ClusterRole to the ServiceAccount subject (kind: ServiceAccount, name: monitor-sa, namespace: monitoring) to actually confer the permissions cluster-wide. Option B is not needed because token secrets are only for obtaining a long-lived bearer token and are unrelated to RBAC authorization.

Option D is wrong because a RoleBinding is namespace-scoped and would have to be created in every namespace individually, which does not satisfy the 'across all namespaces' requirement. Option E is wrong because a Role in the 'monitoring' namespace only grants permissions within that single namespace, not cluster-wide.

Exam trap

The trap here is that candidates often confuse RoleBindings with ClusterRoleBindings, thinking a RoleBinding can grant cluster-wide permissions if bound to a ClusterRole, but a RoleBinding only applies to the namespace it is created in, not across all namespaces.

Full explanation →

524

MCQhard

You are troubleshooting a service named 'api' in the 'prod' namespace that is not reachable from other pods. You run 'kubectl get endpoints api -n prod' and see that the endpoints list is empty. The service selector is 'app=api', and there are three pods with that label running. Which of the following is the MOST likely cause?

A.The pods are not passing their readiness probes, so they are excluded from the service endpoints.

B.The service's targetPort does not match the containerPort, causing the endpoints controller to ignore the pods.

C.The pods are not in the same namespace as the service.

D.The service is of type ExternalName, which does not use selectors or endpoints.

AnswerA

Kubernetes only includes pods in a service's endpoints if they are in the Ready state. If the readiness probe fails, the pod is not considered ready, and its IP is not added to the endpoints. Even if the pods are running and have the correct label, they will not receive traffic. Checking the pod status with 'kubectl get pods -n prod -l app=api' and describing them to see readiness probe failures is the next step.

Why this answer

A service's endpoints are populated only with the IP addresses of pods that match the selector and are in the Ready state. If the readiness probe fails, the pod is not considered ready, and the endpoint is not created. This is a common cause of empty endpoints.

Checking pod readiness and probe configurations is essential. Other factors like namespace mismatch or port issues would not typically result in an empty endpoints list when pods are running.

Exam trap

The trap here is focusing on port mismatches or selector typos, when the most frequent cause of empty endpoints for a service with matching pods is failing readiness probes.

Full explanation →

525

MCQeasy

You have a pod named 'web-pod' that is in a CrashLoopBackOff state. To examine the logs from the previous instance of the container, which command should you use?

A.kubectl logs web-pod --previous

B.kubectl exec web-pod -- cat /var/log/app.log

C.kubectl describe pod web-pod

D.kubectl logs web-pod

AnswerA

kubectl logs web-pod --previous fetches the log stream from the last terminated container instance, which is exactly where the application's crash output is preserved. The --previous flag reads the container's previous log file that survives restarts, allowing you to see the exception, error, or stack trace that triggered the CrashLoopBackOff rather than an empty or fresh current log.

Why this answer

The correct command is kubectl logs web-pod --previous (Option A). This retrieves the logs from the previous instance of the container, which is essential when a pod is in CrashLoopBackOff because the container has restarted and the current logs may be empty or not show the error from the previous run. Option B uses kubectl exec to read a log file, but it does not access previous logs and requires the container to be running.

Option C shows pod details but not logs. Option D shows current logs only, which may not capture the crash reason.

Full explanation →

Certified Kubernetes Administrator CKA (CKA) — Questions 451–525