Certified Kubernetes Administrator CKA CKA Questions 526–600 | Page 8/14

526

MCQmedium

A developer runs 'kubectl port-forward service/my-service 8080:80'. What does this command do?

A.It creates a proxy that routes traffic from the service's ClusterIP to the local machine on port 8080.

B.It forwards incoming traffic on local port 8080 to port 80 on the service's ClusterIP.

C.It exposes the service as a NodePort on port 8080.

D.It creates a new service of type LoadBalancer on port 8080.

AnswerB

Correct description.

Why this answer

It forwards local port 8080 to port 80 on the service, allowing the developer to access the service from localhost.

Full explanation →

527

MCQhard

You are managing a Kubernetes cluster that hosts a microservices application. One of the services, 'payment-processor', is critical and must always be available. It has a Deployment with 3 replicas, each requesting 1 CPU and 2Gi memory. Recently, the team added a new service 'data-analyzer' that runs as a DaemonSet on all nodes, consuming significant CPU and memory. After the addition, you notice that 'payment-processor' pods are occasionally being evicted, and new pods are slow to be scheduled. You check node resource usage and find that some nodes are overcommitted. You want to ensure that 'payment-processor' pods are never evicted and are scheduled before less critical workloads. Which action should you take?

A.Add a taint to nodes that have low resources and add tolerations only to 'payment-processor' pods

B.Increase the resource requests for 'payment-processor' pods to guarantee resources

C.Create a PriorityClass with a high value and assign it to the 'payment-processor' Deployment

D.Use node affinity to ensure 'payment-processor' pods run on dedicated nodes

AnswerC

High priority ensures that 'payment-processor' pods are scheduled before lower priority pods and can preempt them if necessary.

Why this answer

PriorityClass with a high value ensures that 'payment-processor' pods are considered higher priority than other pods during scheduling and eviction. When nodes are overcommitted, the Kubernetes scheduler will preempt lower-priority pods to make room for higher-priority pods, and the kubelet will evict lower-priority pods first when resources are scarce. This directly addresses the requirement that 'payment-processor' pods are never evicted and are scheduled before less critical workloads.

Exam trap

The trap here is that candidates often confuse taints/tolerations or node affinity with priority and preemption, but those features only affect scheduling placement, not eviction ordering or preemption behavior.

How to eliminate wrong answers

Option A is wrong because taints and tolerations control which pods can be scheduled on a node, but they do not provide a mechanism for eviction priority or guarantee that 'payment-processor' pods will be scheduled before other pods on the same node; taints only repel pods without tolerations, and adding tolerations to 'payment-processor' would allow them to schedule on tainted nodes but not prevent eviction. Option B is wrong because increasing resource requests for 'payment-processor' pods would require more resources to schedule them, potentially making scheduling harder, and it does not affect eviction ordering; requests only affect scheduling decisions, not eviction priority. Option D is wrong because node affinity only influences scheduling placement, not eviction behavior; it can ensure pods run on specific nodes but does not prevent eviction when those nodes are overcommitted, nor does it prioritize scheduling over other workloads.

Full explanation →

528

MCQeasy

Which kubectl command creates a service of type NodePort that exposes a deployment named 'web' on port 80?

A.kubectl create service nodeport web --tcp=80:8080

B.kubectl expose deployment web --port=80 --target-port=8080

C.kubectl create service clusterip web --tcp=80:8080

D.kubectl expose deployment web --type=NodePort --port=80

AnswerD

This command creates a NodePort service exposing deployment 'web' on port 80.

Why this answer

The correct command is 'kubectl expose deployment web --type=NodePort --port=80'. Option A is correct. Option B uses '--target-port' unnecessarily and misses '--type=NodePort'.

Option C creates a ClusterIP service. Option D incorrectly uses 'create service nodeport' syntax which is not valid.

Full explanation →

529

Multi-Selecthard

Which TWO statements about EndpointSlices are correct?

Select 2 answers

A.EndpointSlices improve scalability compared to Endpoints.

B.EndpointSlices include topology information like zone.

C.EndpointSlices are created manually by the user.

D.Each EndpointSlice can contain only one endpoint.

E.EndpointSlices are only used with ClusterIP services.

AnswersA, B

Correct. They distribute endpoints across multiple objects.

Why this answer

Options B and D are correct. EndpointSlices scale better than Endpoints for large clusters because they split endpoints into smaller slices. Each slice contains a subset of endpoints, and slices are automatically managed.

Option A is false: EndpointSlices are managed by the control plane. Option C is false: They can contain multiple endpoints (up to 100 by default). Option E is false: EndpointSlices work with all service types.

Full explanation →

530

MCQeasy

A developer created a Deployment with 3 replicas and a ClusterIP Service named 'app-service' on port 80 targeting port 8080 on the pods. Pod logs show that the container is listening on 8080, but curl from another pod in the same namespace to http://app-service:80 fails with 'Connection refused'. What is the most likely cause?

A.The Service selector does not match the pod labels.

B.The container port is 8080 but the Service targetPort is 80.

C.The Service type should be NodePort for inter-pod communication.

D.The DNS resolution for 'app-service' is failing.

AnswerA

If labels don't match, the Service has no endpoints, causing connection refused.

Why this answer

The most likely cause is that the Service's selector does not match the pod labels. A ClusterIP Service routes traffic to pods based on label selectors; if the selector does not match the labels on the pods (e.g., the pods have labels like 'app: myapp' but the Service selector is 'app: frontend'), the endpoints controller will not populate the Service's endpoints, and traffic will be dropped, resulting in a 'Connection refused' error.

Exam trap

The trap here is that candidates often confuse 'port' and 'targetPort' and assume a mismatch causes 'Connection refused', but the actual issue is a selector mismatch, which is a common misconfiguration in CKA troubleshooting scenarios.

How to eliminate wrong answers

Option B is wrong because the Service targetPort is correctly set to 8080 (matching the container port), and the Service port is 80; this is a valid configuration where the Service listens on port 80 and forwards to the container's port 8080. Option C is wrong because NodePort is not required for inter-pod communication; ClusterIP is the default and sufficient for pod-to-pod communication within the cluster. Option D is wrong because if DNS resolution were failing, the curl command would return a 'could not resolve host' error, not 'Connection refused'; the fact that 'Connection refused' occurs indicates that the Service IP was resolved but no pod is accepting connections on the target port.

Full explanation →

531

Drag & Dropmedium

Drag and drop the steps to troubleshoot a Node that is in NotReady state into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

Start with kubectl to identify the node, then SSH, check kubelet and runtime, review logs, then restart.

Full explanation →

532

MCQmedium

You are trying to debug a network connectivity issue between two pods. Pod A can reach the internet but cannot reach Pod B's IP address. Which command should you use to test connectivity from within Pod A to Pod B's service?

A.kubectl exec pod-a -- nslookup service-b

B.curl http://<node-ip>:<nodeport>

C.ssh node-ip 'curl http://<pod-b-ip>:80'

D.kubectl exec pod-a -- curl http://service-b:80

AnswerD

This runs curl inside Pod A to the service name of Pod B, testing both DNS resolution and network connectivity from the pod's perspective.

Why this answer

Option B is correct. 'kubectl exec pod-a -- curl http://service-b:80' runs the curl command inside Pod A to test connectivity to Service B. Option A tests from the node, not from within the pod. Option C tests DNS resolution but not HTTP connectivity.

Option D tests connectivity from outside the cluster.

Full explanation →

533

MCQhard

You have a Deployment 'db' with 3 replicas. Each pod writes to a PersistentVolumeClaim (PVC). A StatefulSet is required for stable network identities and ordered pod management. Which of the following is a key characteristic that differentiates a StatefulSet from a Deployment?

A.StatefulSets support rolling updates but not canary deployments

B.StatefulSets automatically create a Service for each pod

C.StatefulSets cannot use PersistentVolumeClaims

D.StatefulSets maintain a sticky identity for each pod, including stable hostnames and persistent storage

AnswerD

Each pod in a StatefulSet gets a unique ordinal index and stable hostname, and retains its storage across rescheduling.

Why this answer

Option D is correct because StatefulSets assign each pod a unique, stable network identity (e.g., a hostname derived from the StatefulSet name and ordinal index) and guarantee that each pod's PersistentVolumeClaim is bound to the same PersistentVolume across rescheduling. This ensures that each pod retains its identity and data, which is critical for stateful applications like databases. Deployments, in contrast, treat pods as interchangeable and do not guarantee stable hostnames or persistent storage binding.

Exam trap

The trap here is that candidates often confuse the automatic creation of a Headless Service (which is required but not automatically created) with the automatic creation of a Service for each pod, leading them to incorrectly select Option B.

How to eliminate wrong answers

Option A is wrong because StatefulSets do support canary deployments via the `partition` parameter in the rolling update strategy, allowing a subset of pods to be updated while others remain unchanged. Option B is wrong because StatefulSets do not automatically create a Service for each pod; they require a Headless Service (with `clusterIP: None`) to provide stable network identities, but the Service itself is not automatically created by the StatefulSet controller. Option C is wrong because StatefulSets can and commonly do use PersistentVolumeClaims, and the StatefulSet controller manages the creation and binding of PVCs for each pod based on a `volumeClaimTemplate`.

Full explanation →

534

MCQmedium

An admin wants to view the current context in their kubeconfig. Which command should they use?

A.kubectl config get-contexts

B.kubectl cluster-info

C.kubectl config current-context

D.kubectl config view

AnswerC

This outputs the current context name.

Why this answer

Option C is correct because `kubectl config current-context` is the exact command to display the currently active context from the kubeconfig file. The context includes the cluster, namespace, and user that `kubectl` will use by default. This is a direct query of the `current-context` field in the kubeconfig YAML/JSON structure.

Exam trap

The trap here is that candidates often confuse `get-contexts` (which lists all contexts) with `current-context` (which shows only the active one), or they mistakenly think `cluster-info` or `config view` will directly reveal the current context without additional parsing.

How to eliminate wrong answers

Option A is wrong because `kubectl config get-contexts` lists all available contexts from the kubeconfig file, not just the current one; it requires the user to visually identify the active context (marked with an asterisk). Option B is wrong because `kubectl cluster-info` displays information about the cluster endpoints (e.g., master and services), not the current context from the kubeconfig. Option D is wrong because `kubectl config view` outputs the entire kubeconfig file contents, which includes all contexts, clusters, and users, but does not specifically highlight or return only the current context.

Full explanation →

535

MCQhard

You are designing an Ingress to expose multiple services on the same hostname based on path. Which Ingress specification is valid?

A.spec.rules[0].host: example.com; spec.rules[0].http.paths[0].path: /api; backend.service.name: api-svc; spec.rules[0].http.paths[1].path: /web; backend.service.name: web-svc

B.spec.rules[0].host: example.com; spec.rules[0].http.paths[0].path: /api; backend.service.name: api-svc; spec.rules[1].host: example.com; spec.rules[1].http.paths[0].path: /web; backend.service.name: web-svc

AnswerA

Correct: multiple paths under same rule with different backends.

Why this answer

A valid Ingress uses spec.rules with a host and multiple paths pointing to different services.

Full explanation →

536

Multi-Selectmedium

Which THREE statements about PersistentVolumeClaims (PVCs) are correct?

Select 3 answers

A.A PVC defines the reclaim policy for the underlying PersistentVolume.

B.A PVC binds to a PersistentVolume that satisfies its storage request and access modes.

C.A PVC can request storage expansion if the StorageClass allows it.

D.A PVC is a cluster-scoped resource.

E.A PVC can be mounted by multiple Pods if it is bound to a PV with ReadWriteMany access mode.

AnswersB, C, E

PVC binding requires matching capacity and access modes.

Why this answer

PVCs request storage from PVs (A). PVCs can be used by pods once bound (B). PVCs can be expanded if the StorageClass allows (D).

PVCs do not define the reclaim policy (that's on PV) (C), and PVCs are namespaced resources (E is false).

Full explanation →

537

MCQmedium

A DevOps team needs to provide persistent storage to a set of pods that all require read-write access to the same data simultaneously. Which volume type should they use?

A.PersistentVolumeClaim with ReadWriteMany

B.hostPath

C.emptyDir

D.PersistentVolumeClaim with ReadWriteOnce

AnswerA

ReadWriteMany allows multiple pods to read and write simultaneously, which is required here.

Why this answer

A PersistentVolumeClaim with ReadWriteMany (RWX) is the correct choice because it allows multiple pods to mount the same volume simultaneously with read-write access. This access mode is supported by network-based storage backends like NFS, GlusterFS, or CephFS, which provide the necessary concurrency controls for shared access across pods.

Exam trap

The trap here is that candidates often confuse ReadWriteOnce (RWO) with multi-pod access, forgetting that RWO explicitly limits the volume to a single pod mount, while ReadWriteMany (RWX) is required for simultaneous shared access.

How to eliminate wrong answers

Option B (hostPath) is wrong because it mounts a directory from the host node's filesystem into the pod, which does not support simultaneous read-write access from pods running on different nodes; it is also not portable and poses security risks. Option C (emptyDir) is wrong because its lifecycle is tied to the pod — data is deleted when the pod is removed, and it cannot be shared across pods on different nodes. Option D (PersistentVolumeClaim with ReadWriteOnce) is wrong because ReadWriteOnce (RWO) restricts the volume to be mounted as read-write by a single pod on a single node, making it unsuitable for multi-pod shared access.

Full explanation →

538

MCQeasy

Which command creates a ConfigMap named 'app-config' from the file 'config.properties'?

A.kubectl create configmap app-config --file=config.properties

B.kubectl create configmap app-config --from-env-file=config.properties

C.kubectl create configmap app-config --from-literal=config.properties

D.kubectl create configmap app-config --from-file=config.properties

AnswerD

This creates a ConfigMap with a key 'config.properties' and the file content as value.

Why this answer

Option D is correct because `kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the content of the file 'config.properties'. The `--from-file` flag reads the file and stores its entire content as a single key-value pair, where the key defaults to the filename (config.properties) and the value is the file's content. This is the standard syntax for creating a ConfigMap from a file in Kubernetes.

Exam trap

The trap here is confusing `--from-file` with `--from-env-file`; candidates often mistakenly choose `--from-env-file` because they think it reads any configuration file, but it only works with files formatted as environment variable definitions (KEY=VALUE per line), not arbitrary files like config.properties.

How to eliminate wrong answers

Option A is wrong because `--file` is not a valid flag for `kubectl create configmap`; the correct flag is `--from-file`. Option B is wrong because `--from-env-file` is used to import a file containing key-value pairs in a line-by-line format (like a .env file), not to store the entire file content as a single key. Option C is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to reference a file.

Full explanation →

539

Multi-Selectmedium

Which TWO of the following are valid methods to authenticate to the Kubernetes API server?

Select 2 answers

A.Client certificate

B.ServiceAccount token

C.Secrets

D.RBAC

E.Node authorization

AnswersA, B

Client certificates are used for user and component authentication.

Why this answer

Client certificate authentication (option A) is valid because the Kubernetes API server can be configured with TLS to require clients to present a valid X.509 certificate signed by the cluster's Certificate Authority (CA). The API server verifies the certificate's Common Name (CN) or Subject Alternative Name (SAN) against the user identity, and the 'organizational unit' (O) field can map to Kubernetes groups. This is a core authentication method used by tools like kubectl and kubelet.

Exam trap

The trap here is confusing authorization (RBAC, Node authorization) with authentication, or thinking that Secrets are a credential type presented to the API server, when they are merely storage objects that can hold tokens for later use.

Full explanation →

540

MCQmedium

You are debugging a DNS issue from within a pod. The pod is running 'busybox'. Which command would you use to test DNS resolution for 'kubernetes.default.svc.cluster.local'?

A.kubectl describe svc kubernetes -n default

B.kubectl exec -it my-pod -- curl kubernetes.default.svc.cluster.local

C.kubectl run test --image=busybox -- nslookup kubernetes.default.svc.cluster.local

D.kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local

AnswerD

This runs nslookup inside the pod to test DNS resolution of the service name.

Why this answer

nslookup is a standard DNS troubleshooting tool available in many images.

Full explanation →

541

MCQhard

You have a kube-proxy running in ipvs mode. Which of the following is true about IPVS?

A.IPVS supports multiple load balancing algorithms.

B.IPVS uses iptables rules for service discovery.

C.IPVS is the default kube-proxy mode since Kubernetes 1.0.

D.IPVS cannot handle large numbers of services.

AnswerA

IPVS supports algorithms like rr, lc, dh, etc.

Why this answer

IPVS uses the Netfilter hook but implements more efficient load balancing algorithms like round-robin, least-connection, etc.

Full explanation →

542

MCQmedium

You run `kubectl expose deployment web --port=80 --target-port=8080 --type=NodePort` and the Service is created. What is the effect of this command?

A.It creates a NodePort Service, making the deployment accessible on each node's IP on a high port.

B.It creates a LoadBalancer Service and provisions a cloud load balancer.

C.It creates a ClusterIP Service that is only accessible within the cluster.

D.It creates an ExternalName Service that maps to an external DNS name.

AnswerA

NodePort exposes the Service on each node's IP at a static port (30000-32767).

Why this answer

The command creates a NodePort Service named 'web' that listens on port 80 and forwards traffic to container port 8080.

Full explanation →

543

MCQmedium

Based on the exhibit, the pod is in CrashLoopBackOff. Which command should you run NEXT to identify the root cause?

A.kubectl describe node node-1

B.kubectl top pod api-6f4d7b9d4c-abcde -n production

C.kubectl get deployment api -n production -o yaml

D.kubectl logs api-6f4d7b9d4c-abcde -n production --previous

AnswerD

Shows logs from the crashed container instance.

Why this answer

The pod is in CrashLoopBackOff, which means the container starts, crashes, and restarts repeatedly. The `kubectl logs --previous` command retrieves the logs from the previous (crashed) container instance, which is the fastest way to see the error that caused the crash. This directly reveals the root cause, such as a missing dependency, configuration error, or application panic.

Exam trap

The trap here is that candidates may think `kubectl describe pod` or `kubectl get deployment` is needed to check the pod's status or configuration, but the fastest way to see the crash reason is the previous container's logs, not the current (restarted) container's logs which may be empty.

How to eliminate wrong answers

Option A is wrong because `kubectl describe node` shows node-level conditions and resource usage, not the application error causing the container to crash. Option B is wrong because `kubectl top pod` shows current CPU/memory metrics, which are irrelevant to a crash loop caused by an application error. Option C is wrong because `kubectl get deployment -o yaml` shows the desired state and pod template, but not the runtime logs or crash reason from the container.

Full explanation →

544

Multi-Selecthard

You are troubleshooting a pod that is in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 Insufficient memory, 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate'. Which TWO actions can resolve the issue?

Select 2 answers

A.Reduce the memory request in the container spec to fit available memory

B.Add a node selector to the pod spec to target a specific node

C.Increase the memory request to prioritize scheduling

D.Add resource limits without changing requests

E.Add a toleration for the control-plane taint to the pod spec

AnswersA, E

Reducing memory request may allow the pod to fit on a node.

Why this answer

Adding a toleration (B) and reducing memory request (C) address the two issues: taint and insufficient memory. Adding a node selector (A) would not help if taint is not tolerated. Increasing memory request (D) worsens the problem.

Adding resource limits (E) does not resolve scheduling constraints.

Full explanation →

545

Drag & Dropmedium

Drag and drop the steps to configure a NetworkPolicy that allows ingress traffic from a specific pod into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

First ensure the namespace exists, then define the policy with podSelector and ingress from specific pods, apply, and test.

Full explanation →

546

MCQhard

An ingress resource is defined with the following snippet: ```yaml spec: tls: - hosts: - app.example.com secretName: app-tls rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: app-service port: number: 80 ``` The secret 'app-tls' exists and contains a valid certificate. However, accessing https://app.example.com returns a certificate warning in the browser. What is the most likely cause?

A.The TLS secret is in a different namespace than the ingress resource

B.The ingress controller does not support TLS termination

C.The path type is Prefix but should be Exact

D.The secret name does not match the TLS section host

AnswerA

TLS secrets must reside in the same namespace as the ingress resource, otherwise the ingress controller cannot access it.

Why this answer

The TLS configuration only specifies the host, but the ingress controller may require the TLS section to be correctly associated with the rule or the secret may be in the wrong namespace. However, the most common issue is that the ingress controller does not have a default certificate and the TLS secret is not being used because the ingress spec is missing a reference to the secret in the TLS field? Actually the snippet shows it correctly. Another possibility is that the certificate is not trusted by the browser (self-signed).

But among the options, D is plausible: the ingress controller might not support TLS termination for that path. However, Option C is a known issue: the secret must be in the same namespace as the ingress. Option A is false because the secret name is correct.

Option B is false because the path is fine. Option C is correct: the secret must be in the same namespace as the ingress resource. The stem says secret exists, but does not specify namespace; if it's in a different namespace, the ingress controller cannot access it.

Option D: Ingress controllers typically support TLS termination at the ingress level, so that's less likely.

Full explanation →

547

Multi-Selecteasy

Which TWO of the following are valid reasons a pod might be stuck in 'Pending' state?

Select 2 answers

A.Container is killed due to OOM

B.Container image pull fails because of authentication error

C.Not enough CPU or memory available on any node

D.Node is rebooted

E.Node has a taint that the pod does not tolerate

AnswersC, E

Resource constraints prevent scheduling, causing Pending.

Why this answer

Insufficient resources and taint/toleration mismatch are common reasons for Pending. Option C (OOMKilled) would cause CrashLoopBackOff. Option D (image pull) causes ImagePullBackOff.

Option E (node reboot) would cause the pod to be rescheduled or terminated.

Full explanation →

548

MCQhard

After running 'kubeadm certs check-expiration', an admin sees that the 'apiserver' certificate expires in 30 days. Which command should be used to renew it?

A.kubeadm upgrade node

B.openssl req -new -x509 -days 365 -key /etc/kubernetes/pki/apiserver.key -out /etc/kubernetes/pki/apiserver.crt

C.kubeadm certs renew apiserver

D.kubectl certificate renew apiserver

AnswerC

This renews the apiserver certificate.

Why this answer

Option C is correct because `kubeadm certs renew apiserver` is the dedicated kubeadm command to renew the API server certificate without restarting the control plane. It updates the certificate in place using the existing CA, and the new certificate is automatically picked up after a static pod restart or kubelet reload.

Exam trap

The trap here is that candidates may confuse `kubeadm certs renew` with `kubectl certificate` (which handles CSR approval, not renewal) or attempt a manual openssl command that breaks the trust chain, while the correct approach is the kubeadm-managed renewal that preserves CA-signed trust.

How to eliminate wrong answers

Option A is wrong because `kubeadm upgrade node` is used to upgrade the kubelet configuration on worker nodes, not to renew certificates on the control plane. Option B is wrong because `openssl req -new -x509` creates a self-signed certificate, which would break the PKI trust chain; Kubernetes requires certificates signed by the cluster CA, not self-signed ones. Option D is wrong because `kubectl certificate renew` is not a valid kubectl command; certificate renewal in kubeadm is handled by the `kubeadm certs` subcommand, not kubectl.

Full explanation →

549

Multi-Selecthard

Which THREE of the following are characteristics of DaemonSets?

Select 3 answers

A.A DaemonSet runs exactly one pod per node

B.DaemonSets support rolling updates

C.DaemonSets can be scaled down by reducing the number of replicas

D.DaemonSets can be scheduled on specific nodes using nodeSelector

E.A DaemonSet can be used to run a batch job that completes

AnswersA, B, D

DaemonSet ensures one pod per node.

Why this answer

A DaemonSet ensures that exactly one pod runs on each node in the cluster (or a subset of nodes if node selectors are used). When a new node is added, the DaemonSet automatically schedules a pod on it; when a node is removed, the pod is garbage collected. This is enforced by the DaemonSet controller, which does not use a replica count like a Deployment or StatefulSet.

Exam trap

CNCF often tests the misconception that DaemonSets can be scaled by adjusting a replica count, similar to Deployments, but the correct behavior is that DaemonSets are node-driven, not replica-driven.

Full explanation →

550

MCQhard

A cluster has a CSI driver installed. A pod using a CSI volume is in CrashLoopBackOff. 'kubectl describe pod' shows: 'failed to mount volume: rpc error: code = DeadlineExceeded desc = context deadline exceeded'. What is the MOST likely cause?

A.The CSI driver is failing to respond in time.

B.The PVC is not bound.

C.The CSI driver is not installed.

D.The volume mode is Block but the pod expects Filesystem.

AnswerA

The error indicates a timeout, meaning the driver did not complete the mount operation within the deadline.

Why this answer

A DeadlineExceeded error from the CSI driver indicates that the mount operation timed out, possibly due to network issues or driver unavailability.

Full explanation →

551

MCQeasy

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

A.The pod's container image is not found

B.The pod has a resource request that cannot be met by any node

C.The nodes are unreachable or have network issues

D.The PersistentVolumeClaim is not bound

AnswerC

The taint node.kubernetes.io/unreachable is automatically added by the node controller when a node becomes unreachable. The pod does not tolerate this taint, so it cannot be scheduled.

Why this answer

The taint 'node.kubernetes.io/unreachable' indicates nodes are unreachable, often due to node failure or network issues.

Full explanation →

552

MCQmedium

You are using kubeadm to initialize a cluster. After running 'kubeadm init', you follow the instructions to set up the kubeconfig for the regular user. Which of the following commands should you run to allow kubectl to communicate with the cluster?

A.sudo cp /etc/kubernetes/controller-manager.conf $HOME/.kube/config

B.sudo cp /etc/kubernetes/scheduler.conf $HOME/.kube/config

C.sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

D.sudo cp /etc/kubernetes/kubelet.conf $HOME/.kube/config

AnswerC

This copies the admin kubeconfig to the user's home directory, which kubectl uses by default.

Why this answer

After running 'kubeadm init', the admin.conf file is generated in /etc/kubernetes/ and contains the cluster CA certificate, client certificate, and API server endpoint. This is the only kubeconfig file that grants full administrative access to the cluster, making it the correct file to copy to the user's $HOME/.kube/config for kubectl to communicate with the cluster.

Exam trap

The trap here is that candidates confuse the various kubeconfig files generated by kubeadm (each tied to a specific control plane component) and mistakenly copy a component-specific config (like controller-manager.conf or kubelet.conf) instead of the admin.conf, which is the only one designed for administrative kubectl access.

How to eliminate wrong answers

Option A is wrong because /etc/kubernetes/controller-manager.conf is the kubeconfig used by the kube-controller-manager component, not for regular user kubectl access. Option B is wrong because /etc/kubernetes/scheduler.conf is the kubeconfig used by the kube-scheduler component, not for regular user kubectl access. Option D is wrong because /etc/kubernetes/kubelet.conf is the kubeconfig used by the kubelet on the node, not for regular user kubectl access.

Full explanation →

553

MCQmedium

You need to expose a service named 'my-svc' on a static port 30080 on every node. Which service type should you use?

A.LoadBalancer

B.NodePort

C.ExternalName

D.ClusterIP

AnswerB

NodePort exposes a port on every node.

Why this answer

NodePort service exposes a port on every node's IP. The nodePort can be specified in the service spec.

Full explanation →

554

MCQeasy

Which command shows resource usage (CPU and memory) for nodes in a cluster?

A.kubectl describe nodes

B.kubectl logs nodes

C.kubectl get nodes -o wide

D.kubectl top nodes

AnswerD

Shows CPU and memory usage of nodes.

Why this answer

kubectl top nodes displays resource usage if metrics-server is installed.

Full explanation →

555

MCQhard

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

A.kubeadm certs renew apiserver

B.kubeadm certs check-expiration

C.kubeadm certs renew all

D.kubeadm upgrade apply

AnswerC

Renews all certificates managed by kubeadm.

Why this answer

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

Exam trap

The trap here is that candidates confuse `kubeadm certs renew all` with `kubeadm upgrade apply`, thinking an upgrade is required to renew certificates, when in fact the dedicated renew command exists and is the correct tool for certificate-only renewal without changing cluster version.

How to eliminate wrong answers

Option A is wrong because `kubeadm certs renew apiserver` only renews the API server certificate, not all certificates (e.g., etcd, kubelet, controller-manager). Option B is wrong because `kubeadm certs check-expiration` only displays expiration dates and does not perform any renewal. Option D is wrong because `kubeadm upgrade apply` upgrades the cluster version and may renew certificates as a side effect, but it is not the dedicated command for certificate renewal and may introduce version changes or fail if only renewal is needed.

Full explanation →

556

Multi-Selecthard

You have taken an etcd snapshot using 'ETCDCTL_API=3 etcdctl snapshot save snapshot.db'. Which TWO commands are needed to restore this snapshot to a new etcd member? (Choose TWO.)

Select 2 answers

A.etcdctl endpoint health

B.etcdctl snapshot save backup.db

C.Update the etcd configuration (e.g., --data-dir) and restart the etcd service

D.etcdctl snapshot restore snapshot.db --data-dir=/var/lib/etcd-restore

E.etcdctl snapshot status snapshot.db

AnswersC, D

After restore, you must configure etcd to use the new data directory.

Why this answer

Option C is correct because after restoring an etcd snapshot, the etcd service must be configured to use the restored data directory (e.g., via `--data-dir` or the `ETCD_DATA_DIR` environment variable) and then restarted. This ensures the new etcd member loads the snapshot data instead of starting with an empty or default state.

Exam trap

The trap here is that candidates often confuse snapshot status or health checks with actual restoration steps, forgetting that `snapshot restore` must be followed by updating the etcd configuration and restarting the service to make the restored data active.

Full explanation →

557

Multi-Selecthard

Which THREE of the following are valid methods to authenticate to the Kubernetes API server? (Select 3)

Select 3 answers

A.Service account bearer tokens

B.Anonymous requests

C.Static token file

D.Password file with usernames and passwords

E.X.509 client certificates

AnswersA, C, E

Used by pods to authenticate.

Why this answer

Service account bearer tokens are a valid authentication method to the Kubernetes API server. When a pod is associated with a service account, Kubernetes automatically mounts a token into the pod at /var/run/secrets/kubernetes.io/serviceaccount/token. This token is a signed JWT that the API server validates against the TokenReview API, allowing the pod to authenticate as that service account.

Exam trap

CNCF often tests the misconception that static token files and password files are equivalent, but static token files (option C) are valid while password files (option D) were deprecated and removed, so candidates must remember the deprecation timeline.

Full explanation →

558

MCQmedium

You have a service 'my-svc' of type ClusterIP with no selector defined. You manually create an Endpoints object with the same name. Which statement is true?

A.The service will automatically create an Endpoints object based on the service ports.

B.The Endpoints object must have the same labels as the service.

C.The service will route traffic to the IPs defined in the Endpoints object.

D.The service must be of type ExternalName to use manually created Endpoints.

AnswerC

Manually created Endpoints are used to route traffic to external IPs.

Why this answer

A service without a selector can have a manually created Endpoints object to route traffic to external endpoints. The service must have the same name as the Endpoints object.

Full explanation →

559

Matchingmedium

Match each security context setting to its effect.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Specifies the user ID for the container's process

Prevents running as root (UID 0)

Grants elevated privileges to the container

Makes the container's root filesystem read-only

Adds or drops Linux capabilities

Why these pairings

Security contexts define Pod or container privileges and restrictions.

Full explanation →

560

MCQmedium

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

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

B.The service 'svc' does not exist in namespace 'ns2'.

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

D.The pod's DNS policy is set to Default.

AnswerC

Correct. For cross-namespace access, the full DNS name including namespace is required.

Why this answer

Option B is correct. By default, CoreDNS resolves names within the same namespace without the full FQDN. For cross-namespace, the full name is required.

Option A is not an issue. Option C: if the service didn't exist, DNS would return NXDOMAIN. Option D: pod DNS policy defaults to ClusterFirst, which should work.

Full explanation →

561

MCQeasy

A pod is in CrashLoopBackOff. You want to see the current container's logs. Which command do you use?

A.kubectl exec pod-name -- cat /var/log/app.log

B.kubectl describe pod pod-name

C.kubectl logs pod-name --previous

D.kubectl logs pod-name

AnswerD

Shows current container logs.

Why this answer

kubectl logs pod-name shows logs of the currently running container.

Full explanation →

562

MCQmedium

An Ingress resource is defined with the following spec snippet. What is the minimal requirement for this Ingress to work correctly?

A.The Ingress must have a TLS section configured

B.An IngressClass named 'nginx' must be defined and a compatible Ingress controller must be running

C.The Ingress must be in the same namespace as the backend Service

D.A Service named 'api-svc' of type NodePort must exist

AnswerB

The Ingress references an IngressClass; the controller must be running.

Why this answer

An IngressClass resource named 'nginx' must exist and be configured with a controller (e.g., ingress-nginx). The IngressClass defines which controller implements the Ingress.

Full explanation →

563

Multi-Selectmedium

Which TWO actions can help troubleshoot a service that is not reachable from within a pod?

Select 2 answers

A.Use kubectl delete svc and recreate

B.Use kubectl exec to curl the service IP from a pod

C.Use kubectl logs on the service pod to see application logs

D.Use kubectl top nodes to check resource usage

E.Use kubectl describe svc to check endpoints

AnswersB, E

Correct. This tests connectivity directly.

Why this answer

Checking endpoints and using curl from a pod are direct troubleshooting steps.

Full explanation →

564

MCQmedium

A pod is in 'ImagePullBackOff' state. Which of the following is NOT a common cause?

A.The image registry requires authentication and no imagePullSecrets are configured

B.The image tag does not exist

C.The image name is misspelled

D.The container requires more memory than the limit allows

AnswerD

Memory issues cause OOMKilled, not ImagePullBackOff.

Why this answer

Option B is correct. Insufficient memory would cause OOMKilled, not ImagePullBackOff. ImagePullBackOff is caused by issues pulling the container image: wrong image name, authentication failure, registry unreachable, or image not found.

Option A, C, and D are all common causes.

Full explanation →

565

MCQeasy

A pod is in ImagePullBackOff state. Which command would give you the most information about why the image pull failed?

A.kubectl get pod

B.kubectl logs <pod-name>

C.kubectl edit pod <pod-name>

D.kubectl describe pod <pod-name>

AnswerD

Shows events with error details.

Why this answer

kubectl describe pod shows events including the exact error message from the kubelet when trying to pull the image.

Full explanation →

566

MCQhard

Based on the exhibit, what is the most likely cause of the pod not running?

A.The volume driver is not installed on node-1.

B.The pod has exceeded its resource limits.

C.The node 'node-1' is experiencing disk pressure.

D.The Secret 'my-secret' does not exist in the namespace.

AnswerD

The event explicitly says secrets "my-secret" not found.

Why this answer

The correct answer is D because the pod's status indicates it is waiting for a secret to be mounted, and the error message 'secret "my-secret" not found' directly points to the missing Secret resource. Without the Secret existing in the same namespace as the pod, the volume mount fails, preventing the pod from starting.

Exam trap

The trap here is that candidates may assume the issue is node-level (disk pressure or driver) or resource-related, overlooking the specific error message about the missing Secret, which is a common misdirection in CKA troubleshooting questions.

How to eliminate wrong answers

Option A is wrong because a missing volume driver would typically result in a different error, such as 'failed to mount volume' or 'driver not supported', not a secret not found error. Option B is wrong because exceeding resource limits would cause the pod to be in a CrashLoopBackOff or OOMKilled state, not a waiting state for a secret. Option C is wrong because disk pressure on node-1 would manifest as pod eviction or scheduling failures, not a secret mount error.

Full explanation →

567

MCQeasy

A pod is unable to start because the PersistentVolumeClaim it references is still in 'Pending' state. What is the most likely cause?

A.The PersistentVolumeClaim's storage class does not exist or cannot provision a volume

B.The pod's YAML has a syntax error

C.The pod is using a hostPath volume

D.The node has insufficient CPU resources

AnswerA

If the StorageClass is missing or misconfigured, the PVC will stay Pending.

Why this answer

A PersistentVolumeClaim (PVC) remains in 'Pending' state when it cannot find a suitable PersistentVolume (PV) to bind to or when its storage class cannot dynamically provision one. The most common cause is that the referenced storage class does not exist, is misspelled, or lacks a provisioner that can create the volume, leaving the PVC unbound and the pod unable to start.

Exam trap

The trap here is that candidates often confuse 'Pending' state for a PVC with pod scheduling issues, thinking it is a resource constraint on the node, rather than recognizing it as a storage binding or provisioning failure.

How to eliminate wrong answers

Option B is wrong because a YAML syntax error would typically prevent the pod from being created at all, not cause the PVC to remain in 'Pending' state; the pod would fail with a validation error. Option C is wrong because using a hostPath volume does not involve a PVC, so it would not cause a PVC to be stuck in 'Pending'; the pod would start directly if the host path exists. Option D is wrong because insufficient CPU resources on a node would result in the pod being in 'Pending' state due to resource scheduling issues, not because of a PVC being in 'Pending'; the pod would show a different reason such as 'Unschedulable'.

Full explanation →

568

Drag & Dropmedium

Drag and drop the steps to create a Kubernetes cluster using kubeadm into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

kubeadm requires a container runtime first, then you initialize the control plane, configure kubectl, install a CNI plugin, and finally join workers.

Full explanation →

569

Multi-Selectmedium

Which THREE of the following are valid reasons for a Pod to be in Pending state? (Choose THREE.)

Select 3 answers

A.The node selector does not match any available node.

B.The PersistentVolumeClaim used by the Pod is not bound.

C.The cluster does not have enough resources to schedule the Pod.

D.The Pod has a restartPolicy of OnFailure and the container exits with code 0.

E.The container image does not exist.

AnswersA, B, C

If no node matches the nodeSelector, the Pod remains unscheduled.

Why this answer

A Pod enters Pending state when it cannot be scheduled onto a node. Option A is correct because if the Pod's node selector specifies labels that no node in the cluster possesses, the scheduler cannot find a matching node, leaving the Pod unscheduled and in Pending state.

Exam trap

CNCF often tests the distinction between scheduling failures (Pending) and runtime failures (ImagePullBackOff, CrashLoopBackOff), so candidates may mistakenly think a missing image causes Pending instead of the correct ImagePullBackOff state.

Full explanation →

570

Multi-Selecthard

Which TWO of the following are valid ways to specify resource requests and limits for a container in a pod? (Select 2)

Select 2 answers

A.spec: containers: - name: app cpu: 0.5 memory: 512Mi

B.spec: containers: - name: app resource: request: cpu: 1 memory: 1Gi limit: cpu: 2 memory: 2Gi

C.spec: containers: - name: app resources: requests: cpu: "500m" memory: "512Mi" limits: cpu: "1" memory: "1Gi"

D.spec: containers: - name: app resources: limits: cpu: "1" memory: "1Gi"

E.spec: containers: - name: app resources: requests: cpu: "500 millicores" memory: "512 MB"

AnswersC, D

This is the correct YAML structure for requests and limits.

Why this answer

Option C is correct because it uses the correct YAML structure with a `resources` block containing `requests` and `limits` subfields, and specifies CPU as a string (e.g., "500m") and memory as a string (e.g., "512Mi") under the container spec. This matches the Kubernetes API specification for resource management in Pod containers.

Exam trap

The trap here is that candidates often confuse the singular `resource` with the correct plural `resources`, or they incorrectly place CPU/memory fields directly under the container spec without the proper nesting, mimicking the syntax of Docker Compose or older Kubernetes versions.

Full explanation →

571

MCQeasy

Which command allows you to view the current context in a kubeconfig file?

A.kubectl config get-contexts

B.kubectl cluster-info

C.kubectl config view

D.kubectl config current-context

AnswerD

Correct command to display the current context.

Why this answer

Option D is correct because `kubectl config current-context` is the dedicated kubectl command that displays the currently active context from the kubeconfig file. It reads the `current-context` field from the kubeconfig (typically `~/.kube/config`) and outputs its name, making it the most direct way to view the current context.

Exam trap

The trap here is that candidates often confuse `kubectl config get-contexts` (which lists all contexts) with `kubectl config current-context` (which shows only the active one), leading them to choose A because they see the current context listed with an asterisk, but the question specifically asks for the command that 'allows you to view the current context' — not all contexts.

How to eliminate wrong answers

Option A is wrong because `kubectl config get-contexts` lists all available contexts in the kubeconfig file, but it does not specifically isolate or highlight the current context; it requires visual inspection to identify the one marked with an asterisk. Option B is wrong because `kubectl cluster-info` displays information about the cluster endpoints (e.g., Kubernetes master and services), not the current context from the kubeconfig. Option C is wrong because `kubectl config view` outputs the entire kubeconfig file contents (including contexts, clusters, users, and current-context), which is more verbose and not a targeted way to view just the current context.

Full explanation →

572

Multi-Selectmedium

Which TWO of the following are valid ways to expose a Service externally in a Kubernetes cluster running on-premises (no cloud provider)?

Select 2 answers

A.LoadBalancer

B.NodePort

C.Ingress

D.ClusterIP

E.ExternalName

AnswersB, C

NodePort exposes the Service on each node's IP at a static port.

Why this answer

NodePort and Ingress are valid for on-premises clusters. LoadBalancer requires a cloud provider. ExternalName is not for external exposure.

Full explanation →

573

MCQeasy

Which command is used to backup etcd data using etcdctl?

A.etcdctl backup

B.etcdctl export

C.etcdctl snapshot save

D.etcdctl dump

AnswerC

This creates a snapshot backup of etcd.

Why this answer

Option C is correct because `etcdctl snapshot save` is the official command in etcdctl v3 to create a point-in-time backup of the etcd data store. This command captures the entire key-value store and metadata into a snapshot file, which can later be restored using `etcdctl snapshot restore` to recover the cluster state.

Exam trap

The trap here is that candidates confuse the deprecated v2 `etcdctl backup` command with the correct v3 `etcdctl snapshot save` command, or they assume any 'export' or 'dump' verb is sufficient for a full backup.

How to eliminate wrong answers

Option A is wrong because `etcdctl backup` is not a valid command in etcdctl v3; it was used in the deprecated v2 API but is no longer supported. Option B is wrong because `etcdctl export` dumps key-value pairs in JSON format but does not create a consistent, restorable snapshot of the entire etcd data store. Option D is wrong because `etcdctl dump` is not a valid etcdctl command; it may be confused with `etcdctl snapshot save` or other dump utilities but does not exist in the etcdctl CLI.

Full explanation →

574

Multi-Selectmedium

Which two of the following are correct statements about EndpointSlices?

Select 2 answers

A.EndpointSlices are only used for services of type LoadBalancer.

B.EndpointSlices replace the Endpoints resource entirely.

C.EndpointSlices are automatically created by the EndpointSlice controller.

D.EndpointSlices are an alpha feature and must be enabled via feature gate.

E.EndpointSlices can contain up to 100 endpoints per slice by default.

AnswersC, E

The controller manages them.

Why this answer

EndpointSlices were introduced to improve scalability over Endpoints. They can contain up to 100 endpoints by default and can be managed by a controller. They are not a replacement for Endpoints; both coexist.

Full explanation →

575

MCQeasy

Which command creates a ConfigMap named 'app-config' from a file named 'config.properties'?

A.kubectl create configmap app-config --from-file=config.properties

B.kubectl create configmap app-config --from-file=app-config=config.properties

C.kubectl create configmap app-config --from-env=config.properties

D.kubectl create configmap app-config --from-literal=config.properties

AnswerA

Correct command. The file content is stored under the key 'config.properties'.

Why this answer

Option A is correct because the `kubectl create configmap` command with the `--from-file` flag creates a ConfigMap from the contents of a specified file. When you use `--from-file=config.properties`, Kubernetes reads the file and creates a ConfigMap with a single key named after the filename (config.properties) and the file's content as the value. This is the standard method for importing configuration data from a properties file into a ConfigMap.

Exam trap

CNCF often tests the distinction between `--from-file`, `--from-literal`, and `--from-env-file` flags, and the trap here is confusing `--from-env` (which doesn't exist) with `--from-env-file` or misusing `--from-literal` to reference a file path instead of a key-value pair.

How to eliminate wrong answers

Option B is wrong because `--from-file=app-config=config.properties` uses an explicit key-value syntax where 'app-config' is the key name, not the ConfigMap name; this would create a ConfigMap named 'app-config' but with a key 'app-config' and value from the file, which is not the standard way to import a file with its original name. Option C is wrong because `--from-env` is not a valid flag for `kubectl create configmap`; the correct flag for importing environment-style files is `--from-env-file`, and `--from-env` would cause a syntax error. Option D is wrong because `--from-literal` is used to specify key-value pairs directly in the command line (e.g., `--from-literal=key=value`), not to reference a file; using `--from-literal=config.properties` would treat the string 'config.properties' as a literal key with no value, which is incorrect.

Full explanation →

576

Multi-Selectmedium

You run 'kubectl logs pod-name' and get no output. Which TWO steps should you take to troubleshoot further?

Select 2 answers

A.Run 'kubectl get events --all-namespaces'

B.Run 'kubectl top pod pod-name' to check resource usage

C.Run 'kubectl describe pod pod-name' to check container state and events

D.Run 'kubectl logs --previous pod-name'

E.Run 'kubectl exec pod-name -- cat /var/log/container.log'

AnswersC, D

Describes the pod and may reveal why logs are missing.

Why this answer

kubectl logs --previous (A) retrieves logs from the previous container instance, useful if the pod restarted. kubectl describe pod (B) shows container state and events. 'kubectl exec' (C) runs commands but does not show logs. 'kubectl top pod' (D) shows resource usage. 'kubectl get events' (E) shows cluster events; though useful, the two most direct steps for missing logs are --previous and describe.

Full explanation →

577

MCQhard

You have an Ingress resource with a TLS section specifying a secret named 'tls-secret'. The certificate in 'tls-secret' is expired. What happens when a client connects via HTTPS to the Ingress host?

A.TLS handshake succeeds but the client receives a warning about the expired certificate

B.The Ingress controller returns an error and refuses to terminate TLS

C.The Ingress controller automatically renews the certificate

D.The secret is ignored and HTTP is used instead

AnswerA

The certificate is used as-is; browsers warn about expiration.

Why this answer

Kubernetes Ingress controllers will serve the certificate even if expired; TLS termination still occurs but browsers will warn.

Full explanation →

578

Multi-Selectmedium

Which TWO of the following are valid methods to restore an etcd cluster from a snapshot? (Choose TWO.)

Select 2 answers

A.etcdctl restore

B.kubectl apply -f etcd-backup.yaml

C.Stopping all etcd members, copying the snapshot to the data directory, and starting etcd

D.etcdctl snapshot restore

E.kubeadm reset

AnswersC, D

If you replace the data directory with the snapshot, etcd will use it on startup.

Why this answer

Option C is correct because restoring an etcd cluster from a snapshot can be done by stopping all etcd members, copying the snapshot file to the etcd data directory (typically `/var/lib/etcd`), and then restarting the etcd service. This manual method works when you replace the entire data directory with the snapshot content, allowing etcd to rebuild its state from the snapshot on startup.

Exam trap

CNCF often tests the distinction between `etcdctl restore` (invalid) and `etcdctl snapshot restore` (valid), and the trap here is that candidates may confuse the deprecated `etcdctl restore` command with the correct `etcdctl snapshot restore` subcommand, or think that `kubectl apply` can handle binary snapshot files.

Full explanation →

579

Multi-Selecthard

You are troubleshooting a scenario where a pod cannot communicate with another pod in the same namespace via service name. Which THREE steps would you take to diagnose the issue? (Select 3)

Select 3 answers

A.Run 'kubectl get nodes' to check node status

B.Run 'kubectl get endpoints' to verify the service has healthy endpoints

C.Exec into the pod and use curl to test connectivity to the service's cluster IP

D.Run 'kubectl logs' on the target pod to check application logs

E.Exec into the pod and run nslookup to verify DNS resolution of the service name

AnswersB, C, E

If endpoints are missing, the service cannot route traffic to pods.

Why this answer

Options A, B, and C are correct. Testing DNS resolution with nslookup, checking connectivity with curl, and examining the service's endpoints are standard troubleshooting steps. Option D checks node status, which is less direct.

Option E checks pod logs, which may not reveal network issues.

Full explanation →

580

MCQeasy

Which component is responsible for maintaining the desired state of the cluster, such as ensuring the correct number of replicas for a Deployment?

A.kube-apiserver

B.kubelet

C.kube-controller-manager

D.kube-scheduler

AnswerC

Runs controllers like Deployment controller.

Why this answer

The kube-controller-manager is responsible for running controller processes that regulate the state of the cluster. It includes the Deployment controller, which watches the API server for changes to Deployment objects and ensures the actual number of replicas matches the desired state by creating or deleting Pods via the ReplicaSet controller.

Exam trap

The trap here is that candidates often confuse the kubelet's role in maintaining Pod health on a node with the controller-manager's cluster-wide reconciliation of desired state, especially since both involve 'ensuring' something is running.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the front-end for the Kubernetes control plane, exposing the Kubernetes API; it does not actively reconcile desired state but rather validates and processes requests. Option B is wrong because kubelet is an agent running on each worker node that ensures containers are running in a Pod as specified by the PodSpec, but it does not manage cluster-level desired state like replica counts. Option D is wrong because kube-scheduler is responsible for assigning Pods to nodes based on resource availability and constraints, not for maintaining the desired number of replicas.

Full explanation →

581

MCQeasy

A pod is stuck in Pending state. You run 'kubectl describe pod my-pod' and see the event '0/1 nodes are available: 1 Insufficient cpu'. What is the most likely cause?

A.The pod's memory limit is too low

B.The pod is trying to use a GPU that is not available

C.The pod's CPU request exceeds available node CPU

D.The kubelet on the node is not running

AnswerC

Correct. The event explicitly states insufficient CPU.

Why this answer

The event indicates that no node has enough free CPU to satisfy the pod's CPU request.

Full explanation →

582

MCQmedium

A pod is in ImagePullBackOff. Which command would help determine the exact reason?

A.kubectl logs <pod>

B.kubectl describe pod <pod>

C.kubectl get events

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

AnswerB

Why this answer

The `kubectl describe pod <pod>` command provides detailed information about the pod, including the container state, the exact error message from the image pull (e.g., 'ImagePullBackOff'), and the underlying reason (e.g., 'Back-off pulling image', 'manifest for image not found', or 'unauthorized: authentication required'). This is the most direct way to see the specific error without needing to access the container or parse raw events.

Exam trap

CNCF often tests the misconception that `kubectl logs` can diagnose startup failures, but logs are only available after the container has started, making `kubectl describe pod` the correct tool for pre-start errors like ImagePullBackOff.

Why the other options are wrong

Container hasn't started; no logs.

Shows all events, not specific to pod.

Pod not running.

Full explanation →

583

MCQmedium

You have a Service named 'my-service' in namespace 'ns1'. Another pod in namespace 'ns2' needs to resolve 'my-service' using DNS. What FQDN should the pod use?

A.my-service.svc.cluster.local

B.my-service.cluster.local

C.my-service.ns1.svc.cluster.local

D.my-service.ns2.svc.cluster.local

AnswerC

The FQDN format is <service>.<namespace>.svc.cluster.local.

Why this answer

Services are reachable via DNS as <service>.<namespace>.svc.cluster.local.

Full explanation →

584

Multi-Selecteasy

Which TWO commands show cluster events that can help in troubleshooting?

Select 2 answers

A.kubectl cluster-info

B.kubectl logs <pod-name>

C.kubectl top pods

D.kubectl describe pod <pod-name>

E.kubectl get events

AnswersD, E

Includes events related to the pod.

Why this answer

Option D is correct because `kubectl describe pod <pod-name>` provides a detailed summary of a pod's lifecycle, including events such as failed pulls, backoff restarts, and scheduling failures. These events are embedded in the pod's status and are essential for troubleshooting pod-level issues. Option E is correct because `kubectl get events` lists all cluster-wide events sorted by timestamp, allowing you to see node failures, volume mount errors, and other cluster-level anomalies.

Exam trap

The trap here is that candidates often confuse `kubectl logs` (which shows container output) with event viewing, or assume `kubectl cluster-info` provides troubleshooting events, when in fact only `kubectl describe` and `kubectl get events` surface the cluster's event history.

Full explanation →

585

MCQmedium

Which command is used to check the expiration of certificates managed by kubeadm?

A.kubeadm certs status

B.kubeadm certs check-expiration

C.kubeadm certs list

D.kubeadm certs renew

AnswerB

This command shows the expiration dates of each certificate.

Why this answer

The correct command to check the expiration of certificates managed by kubeadm is `kubeadm certs check-expiration`. This command reads the certificate files located in `/etc/kubernetes/pki/` and displays their remaining validity period, allowing administrators to proactively renew certificates before they expire.

Exam trap

The trap here is that candidates may confuse `kubeadm certs check-expiration` with `kubeadm certs renew`, thinking the latter also shows expiration status, but `renew` only performs the renewal action without displaying current expiration data.

How to eliminate wrong answers

Option A is wrong because `kubeadm certs status` is not a valid kubeadm subcommand; the correct subcommand for checking expiration is `check-expiration`. Option C is wrong because `kubeadm certs list` does not exist; kubeadm does not provide a `list` subcommand for certificates. Option D is wrong because `kubeadm certs renew` is used to renew certificates, not to check their expiration status, and it requires prior verification of expiration to avoid unnecessary renewals.

Full explanation →

586

MCQhard

You have an etcd cluster with three members. You need to take a snapshot for disaster recovery. Which command correctly creates a snapshot?

A.etcdctl snapshot restore /backup/snapshot.db

B.ETCDCTL_API=2 etcdctl backup --data-dir /var/lib/etcd

C.ETCDCTL_API=3 etcdctl snapshot save /backup/snapshot.db --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

D.etcdctl snapshot save /backup/snapshot.db

AnswerC

Correct command with API v3, snapshot save, and required TLS flags.

Why this answer

Option C is correct because it uses the etcdctl v3 API with the `snapshot save` command, which is the proper method for creating a consistent point-in-time backup of an etcd cluster. The command includes mandatory TLS authentication flags (`--cacert`, `--cert`, `--key`) and the `--endpoints` flag to target a specific etcd member, ensuring a secure and successful snapshot operation.

Exam trap

The trap here is that candidates often forget to include TLS flags or the `--endpoints` flag, assuming a local default connection works, or they confuse `snapshot save` with `snapshot restore` or the deprecated v2 API backup command.

How to eliminate wrong answers

Option A is wrong because `etcdctl snapshot restore` is used to restore a snapshot, not to create one. Option B is wrong because `ETCDCTL_API=2 etcdctl backup` uses the deprecated v2 API, which does not support snapshotting the v3 data store and is not recommended for disaster recovery in modern etcd clusters. Option D is wrong because it omits the required `--endpoints` and TLS flags; without these, the command will fail to connect to the etcd server (which listens on a secure port by default) or will default to localhost without authentication, resulting in a permission error or connection refusal.

Full explanation →

587

MCQeasy

Which access mode allows multiple pods to read and write to a PersistentVolume simultaneously when all pods are on the same node?

A.ReadWriteOnce

B.ReadOnlyMany

C.ReadWriteMany

D.ReadWriteOncePod

AnswerA

ReadWriteOnce allows a single node to mount the volume read-write. When multiple pods are scheduled on that same node, they can all read and write simultaneously.

Why this answer

RWO (ReadWriteOncePod) is not a valid access mode. ReadWriteOnce (RWO) allows only one node to mount the volume read-write. ReadOnlyMany (ROX) allows multiple nodes to mount read-only.

ReadWriteMany (RWX) allows multiple nodes to mount read-write. However, if all pods are on the same node, ReadWriteOnce (RWO) allows multiple pods on that node to read and write simultaneously.

Full explanation →

588

MCQhard

A pod is in CrashLoopBackOff. 'kubectl logs my-pod --previous' shows: 'Error: failed to start: exec: "/app/start.sh": stat /app/start.sh: no such file or directory'. What is the most likely cause?

A.The pod's service account lacks permissions.

B.The container image is missing the startup script.

C.The pod's liveness probe is misconfigured.

D.The pod has run out of memory.

AnswerB

The error 'no such file or directory' for /app/start.sh means the script is not present in the image.

Why this answer

The error indicates the specified entrypoint script is missing. This is often due to the container image not containing the script at the expected path, or the command/args in the pod spec referencing a non-existent file.

Full explanation →

589

MCQeasy

Which component on a worker node is responsible for maintaining network rules and forwarding traffic to the correct pod?

A.Container runtime

B.kubelet

C.kube-proxy

D.kube-scheduler

AnswerC

kube-proxy handles network rules and traffic forwarding for Services.

Why this answer

kube-proxy is the correct component because it runs on each worker node and is responsible for implementing Kubernetes Service concepts by maintaining network rules (iptables or IPVS) that allow network communication to Pods from inside or outside the cluster. It forwards traffic to the correct Pod by load-balancing across the endpoints of a Service, using the cluster IP and port.

Exam trap

The trap here is that candidates often confuse kube-proxy with kubelet, thinking the node agent manages networking, but kubelet only ensures Pods are running while kube-proxy specifically handles Service-to-Pod traffic rules.

How to eliminate wrong answers

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

Full explanation →

590

Multi-Selectmedium

You run 'kubectl get pods' and see a pod with status 'CrashLoopBackOff'. Which TWO commands can help you investigate the cause?

Select 2 answers

A.kubectl exec pod-name -- /bin/sh

B.kubectl logs pod-name

C.kubectl get events

D.kubectl top pod pod-name

E.kubectl describe pod pod-name

AnswersB, E

Shows container logs that may reveal crash reasons.

Why this answer

'kubectl logs pod-name' (C) shows the container logs, and 'kubectl describe pod pod-name' (D) shows events and state. 'kubectl get events' (A) can help but is less direct. 'kubectl top pod' (B) shows resource usage but not crash details. 'kubectl exec' (E) might not work if the pod is crashing.

Full explanation →

591

MCQmedium

An admin wants to check the expiration date of all certificates used by kubeadm components. Which command should be used?

A.kubeadm certs check-expiration

B.kubeadm upgrade plan

C.kubeadm certs renew

D.kubectl get certificates

AnswerA

This command checks certificate expiration.

Why this answer

The `kubeadm certs check-expiration` command is the correct tool to inspect the expiration dates of all certificates generated by kubeadm for cluster components, such as the API server, controller-manager, scheduler, and etcd. It reads the certificate files from the default kubeadm certificate directory (`/etc/kubernetes/pki`) and displays their remaining validity period in a human-readable table. This command is part of the kubeadm certificate management suite and is specifically designed for this purpose.

Exam trap

The trap here is that candidates confuse `kubeadm certs check-expiration` with `kubeadm upgrade plan` or `kubectl get certificates`, mistakenly thinking that upgrade planning or a generic kubectl command can reveal certificate expiry, when in fact only the kubeadm-specific subcommand provides this information.

How to eliminate wrong answers

Option B is wrong because `kubeadm upgrade plan` checks the feasibility of upgrading the cluster to a newer Kubernetes version and lists available versions, but it does not display certificate expiration dates. Option C is wrong because `kubeadm certs renew` is used to renew all or specific certificates, not to check their expiration status; running it without prior inspection could lead to unnecessary renewals. Option D is wrong because `kubectl get certificates` is not a valid command; Kubernetes does not have a built-in `certificates` resource type in the core API, and this command would return an error or no relevant output.

Full explanation →

592

MCQeasy

Which volume type in Kubernetes allows a Pod to share data between its containers, with the data being deleted when the Pod is removed?

A.hostPath

B.emptyDir

C.configMap

D.secret

AnswerB

emptyDir is created when the Pod is assigned to a node and exists as long as that Pod is running. It is used for sharing data between containers and is deleted when the Pod is removed.

Why this answer

emptyDir volumes are created when a Pod is assigned to a node and exist as long as that Pod is running. They are initially empty and allow containers in the same Pod to share data. When the Pod is deleted, the emptyDir is deleted permanently. hostPath persists beyond Pod lifecycle, configMap and secret are used for configuration data, not for sharing data between containers in a transient manner.

Full explanation →

593

MCQhard

You have a PriorityClass named 'high-priority' with value 1000 and 'low-priority' with value 100. A Pod with 'high-priority' is pending because no node has enough resources. Another Pod with 'low-priority' is running on a node. Will the high-priority Pod preempt the low-priority Pod?

A.No, because preemption only works on nodes with taints

B.No, because preemption is disabled by default

C.Yes, but only if the high-priority Pod has tolerations for the node's taints

D.Yes, because the high-priority Pod has a higher priority value and the scheduler will try to preempt lower-priority pods

AnswerD

The scheduler will attempt to preempt a lower-priority pod if necessary.

Why this answer

Option B is correct. Pod preemption occurs when a higher-priority pod cannot be scheduled because of insufficient resources on nodes. The scheduler will attempt to preempt (evict) lower-priority pods to make room.

Option A is incorrect because preemption is enabled by default but can be disabled. Option C is incorrect because preemption is not limited to nodes with taints. Option D is incorrect because priority values determine preemption behavior; higher value can preempt lower value.

Full explanation →

594

MCQhard

An administrator runs 'kubectl get pods' and sees a pod stuck in 'Pending' state. Which of the following is NOT a typical cause?

A.Insufficient CPU or memory resources on any node

B.PersistentVolumeClaim is pending and not bound

C.A required ConfigMap does not exist

D.Node selector labels do not match any node

AnswerC

Why this answer

A missing ConfigMap does not prevent a pod from being scheduled; it only causes the pod to fail at runtime when it tries to mount or use the ConfigMap. The 'Pending' state specifically indicates that the pod has not been scheduled to a node, which is a scheduling issue, not a runtime configuration issue. Therefore, a missing ConfigMap is not a typical cause of a pod stuck in 'Pending'.

Exam trap

The trap here is that candidates confuse scheduling failures (which cause 'Pending') with runtime configuration errors (which cause 'CrashLoopBackOff' or 'Error'), leading them to incorrectly think a missing ConfigMap could prevent scheduling.

How to eliminate wrong answers

Option A is wrong because insufficient CPU or memory resources on any node is a classic cause of 'Pending' — the scheduler cannot find a node with enough allocatable resources to satisfy the pod's resource requests. Option B is wrong because if a pod references a PersistentVolumeClaim that is pending (not bound to a PV), the scheduler will not schedule the pod until the PVC is bound, as the pod's volume requirements cannot be satisfied. Option D is wrong because if a pod uses a nodeSelector that does not match any node's labels, the scheduler will leave the pod in 'Pending' as no node meets the selection criteria.

Full explanation →

595

MCQeasy

You suspect the kubelet on a worker node is not functioning correctly. Which command should you use to check the kubelet service status?

A.kubectl get nodes

B.systemctl status kubelet

C.kubectl describe node <node-name>

D.journalctl -u kubelet

AnswerB

Directly checks the kubelet service status on the node.

Why this answer

systemctl status kubelet shows the current status, recent logs, and whether the service is active. kubectl get nodes shows node status but not kubelet service details.

Full explanation →

596

Multi-Selectmedium

Which TWO statements about PersistentVolume (PV) reclaim policies are correct?

Select 2 answers

A.Delete policy: both the PV and the underlying storage are deleted.

B.Recycle policy: the PV is deleted and data is scrubbed.

C.Delete policy: the PV remains but the underlying storage is deleted.

D.Retain policy: the PV remains in the cluster and the underlying storage is not deleted.

E.Retain policy: the PV is automatically deleted after 30 days.

AnswersA, D

Delete removes both the cluster resource and external storage.

Why this answer

Option A is correct because the Delete reclaim policy removes both the PersistentVolume object from the cluster and the associated underlying storage asset (e.g., an EBS volume or GCE PD). This is the default behavior for dynamically provisioned PVs, ensuring no orphaned storage resources remain after the PV is released.

Exam trap

The trap here is confusing the Recycle policy with Delete or Retain, or assuming that Retain includes an automatic cleanup timer, when in fact Retain requires manual administrative action and never auto-deletes.

Full explanation →

597

MCQmedium

A pod is using a PersistentVolumeClaim (PVC) named 'mypvc' which is bound to a PersistentVolume (PV) with reclaim policy 'Retain'. The pod is deleted and then the PVC is deleted. What happens to the PV?

A.The PV remains but is in 'Released' state.

B.The PV is automatically deleted.

C.The PV is immediately bound to another PVC.

D.The PV is recycled for reuse.

AnswerA

With 'Retain', the PV is not deleted or recycled; it stays in 'Released' state and retains data.

Why this answer

With reclaim policy 'Retain', the PV is not deleted or recycled after the PVC is deleted. It remains in the 'Released' state, and its data persists for manual reclamation.

Full explanation →

598

Multi-Selecthard

You have a pod that is in CrashLoopBackOff. Which two troubleshooting steps should you take first? (Choose two.)

Select 2 answers

A.kubectl describe pod pod-name

B.kubectl delete pod pod-name

C.kubectl logs pod-name --previous

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

E.kubectl rollout restart deployment

AnswersA, C

Shows events and recent state changes.

Why this answer

Check the logs with kubectl logs --previous to see the crash reason, and describe the pod to see events and state.

Full explanation →

599

Multi-Selectmedium

Which TWO of the following statements about Kubernetes DaemonSets are correct?

Select 2 answers

A.DaemonSets are used for stateless applications that require multiple replicas.

B.DaemonSets can be updated using a rolling update strategy.

C.DaemonSets ignore taints and tolerations by default.

D.DaemonSets have a desired replica count that can be scaled independently.

E.DaemonSets ensure that a copy of a Pod runs on all or a subset of Nodes.

AnswersB, E

DaemonSets support RollingUpdate and OnDelete update strategies.

Why this answer

Option B is correct because DaemonSets support a rolling update strategy via the `spec.updateStrategy.type: RollingUpdate` field. This allows you to update the Pod template (e.g., image or command) across all nodes in a controlled manner, with `maxUnavailable` and `maxSurge` parameters controlling the pace, ensuring minimal disruption to the daemon workload.

Exam trap

The trap here is that candidates confuse DaemonSets with Deployments or StatefulSets, assuming they can be scaled manually via `replicas`, or they forget that DaemonSets respect taints and tolerations like any other Pod, leading them to incorrectly select options C or D.

Full explanation →

600

MCQmedium

A NetworkPolicy named 'deny-all' has only a podSelector matching all pods and no rules. What is the effect?

A.Has no effect because NetworkPolicy requires at least one rule

B.Allows all traffic because there are no explicit deny rules

C.Denies all ingress traffic to all pods in the namespace

D.Denies all egress traffic from all pods in the namespace

AnswerC

An empty rules section means no traffic is allowed, effectively denying all ingress.

Why this answer

A NetworkPolicy with an empty podSelector (matchLabels: {}) selects all pods in the namespace. With no ingress rules, it defaults to denying all ingress traffic to those pods. Similarly, if no egress rules, it denies all egress traffic.

Full explanation →

Certified Kubernetes Administrator CKA (CKA) — Questions 526–600