Certified Kubernetes Administrator CKA CKA Questions 151–225 | Page 3/5

151

MCQeasy

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

A.etcd

B.kube-controller-manager

C.kube-apiserver

D.kube-scheduler

AnswerA

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

Why this answer

etcd is the distributed key-value store that serves as the single source of truth for the entire cluster, storing all cluster state data such as configurations, secrets, service endpoints, and resource specifications. The kube-apiserver reads from and writes to etcd exclusively, making it the only component that directly persists the cluster's desired and current state.

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

152

MCQhard

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

A./api/v1/users

B.ImplementationSpecific: depends on the Ingress controller

C./api

D.No match, returns 404

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

153

MCQhard

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

A.db-service.svc.cluster.local

B.db-service

C.db-service.backend.cluster.local

D.db-service.backend.svc.cluster.local

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

154

MCQmedium

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

A.kubectl logs coredns -n kube-system

B.kubectl describe svc kubernetes

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

D.kubectl exec <pod-name> -- nslookup kubernetes.default

AnswerD

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

Why this answer

The correct command to test DNS resolution from within a pod is `kubectl exec <pod-name> -- nslookup kubernetes.default`. This runs the nslookup command inside an existing pod, directly testing DNS resolution from that pod's perspective. Option A (kubectl logs coredns) shows CoreDNS logs, not a DNS test.

Option B (kubectl describe svc kubernetes) shows service details, not DNS resolution. Option C (kubectl run test --image=busybox -- nslookup kubernetes.default) creates a new pod to run the command, but the question asks for testing from within an existing pod, so exec is appropriate.

Full explanation →

155

MCQhard

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

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

B.A NetworkPolicy is blocking the traffic

C.The service's targetPort is incorrect

D.The pod is running on a different node without proper routing

AnswerB

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

Why this answer

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

Exam trap

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

Why the other options are wrong

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

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

ClusterIP services work across nodes; no extra routing needed.

Full explanation →

156

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Delete the namespace and redeploy all workloads

B.Increase the CPU request for the container

C.Delete and recreate the pod to clear the crash loop

D.Increase the memory limit in the pod's container resource specification

AnswerD

An `OOMKilled` event signifies that the container exceeded its configured memory limit, prompting the Linux kernel's Out-Of-Memory killer to terminate the process. By increasing the `memory.limits` within the pod's container resource specification, we provide the application with a larger memory ceiling. This directly addresses the root cause, allowing the container to consume the necessary RAM without being terminated, thereby resolving the `CrashLoopBackOff`.

Why this answer

The 'OOMKilled' status indicates the container was terminated because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to use more memory without being killed by the Out-of-Memory (OOM) killer. This directly addresses the root cause of the CrashLoopBackOff state.

Exam trap

The trap here is that candidates may confuse CPU and memory resource management, incorrectly assuming that increasing CPU requests (option B) will resolve memory exhaustion, or they may opt for a superficial fix like recreating the pod (option C) without addressing the underlying resource limit.

How to eliminate wrong answers

Option A is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not address the underlying memory constraint; it would only restart the pod with the same insufficient memory limit. Option B is wrong because increasing the CPU request does not affect memory usage or prevent OOM kills; CPU and memory are separate resources managed independently by the kubelet. Option C is wrong because deleting and recreating the pod would only restart it with the same memory limit, leading to the same OOMKilled crash loop; it does not resolve the resource exhaustion.

Full explanation →

157

MCQeasy

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

A.kubectl rollout undo deployment web-app --revision=1

B.kubectl rollout undo deployment web-app --to-revision=1

C.kubectl rollback deployment web-app --to-revision=1

D.kubectl rollout undo deployment web-app

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

158

MCQhard

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

A.The nodes have insufficient resources

B.The pod has a requiredDuringSchedulingIgnoredDuringExecution anti-affinity rule that is too restrictive

C.The pod has a taint tolerance issue

D.The nodes are all cordoned

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

159

MCQmedium

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

A.kubectl logs <pod-name>

B.kubectl describe pod <pod-name>

C.kubectl top pod <pod-name>

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

160

MCQmedium

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

A.The Ingress controller must be configured to use the NodePort of the service.

B.The service 'api-service' must be of type NodePort.

C.The service 'api-service' must have a valid ClusterIP and at least one endpoint.

D.The Ingress must have an IngressClass annotation.

AnswerC

The Ingress controller forwards traffic to the service's ClusterIP, and endpoints must exist for the service to forward to pods.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

161

Multi-Selectmedium

Which THREE components are required for a pod to resolve a Service DNS name?

Select 3 answers

A.The Service exists in the cluster

B.CoreDNS is running and has a Service entry for the cluster domain

C.kubelet configures the pod's /etc/resolv.conf

D.kube-proxy is running in iptables mode

E.A CNI plugin is installed

AnswersA, B, C

The Service must exist in the cluster because the cluster DNS system only creates DNS A/AAAA records for Service objects, not for individual pods or arbitrary endpoints. When a Service is created, the DNS controller registers a name in the form <service>.<namespace>.svc.<cluster-domain>, and without that object there is no record for the resolver to return. This is a prerequisite independent of the DNS server itself or the pod's resolver configuration: even a healthy CoreDNS and correctly set resolv.conf cannot resolve a Service name that was never defined.

Why this answer

A Pod resolves a Service DNS name by querying the cluster's DNS service, which only returns an A/AAAA record if the Service object exists. Without the Service, the DNS name has no corresponding cluster IP to resolve, so the query fails with NXDOMAIN.

Exam trap

A common trap is confusing kube-proxy's role in Service traffic routing with DNS name resolution. kube-proxy handles load balancing of traffic to Service pods, but it does not resolve DNS names. DNS resolution relies solely on CoreDNS and the pod's resolv.conf configuration.

Full explanation →

162

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

Creating a PriorityClass with a high integer value and assigning it to the 'payment-processor' Deployment is the most effective solution. Pods with higher priority are preferentially scheduled by the kube-scheduler. Crucially, if a high-priority 'payment-processor' pod cannot be scheduled due to insufficient resources on any node, the scheduler will attempt to preempt (evict) lower-priority pods on suitable nodes to free up the necessary resources, thereby ensuring the critical workload runs.

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 →

163

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

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

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

Full explanation →

164

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 is the most effective command because `kubectl exec` runs `curl` directly within the network namespace of `pod-a`, simulating the exact origin of the communication. By targeting `http://service-b:80`, it simultaneously tests DNS resolution of the service name, the ability to establish a TCP connection to the service's ClusterIP on port 80, and the application's responsiveness. This provides a comprehensive end-to-end test from the perspective of the source pod.

Why this answer

It uses `kubectl exec` to run a command inside Pod A, then uses `curl` to reach Pod B's service by its DNS name (`service-b`) and port 80. This tests connectivity from Pod A's network namespace to the ClusterIP service, which is the correct way to verify pod-to-service communication within the cluster. Using the service name leverages Kubernetes internal DNS (CoreDNS) to resolve to the service's virtual IP, and `curl` sends an HTTP request to confirm reachability.

Exam trap

The trap here is that candidates confuse testing pod-to-service connectivity (which requires using the service DNS name from within the pod) with testing node-to-pod or DNS-only checks, leading them to pick options that bypass the pod's network namespace or only test DNS resolution.

How to eliminate wrong answers

Option A is wrong because `nslookup` only tests DNS resolution of the service name, not actual network connectivity to the service IP or pod. Option B is wrong because it tests connectivity from the node to the NodePort, not from within Pod A to the service; this bypasses Pod A's network namespace and does not verify pod-to-service communication. Option C is wrong because it runs `curl` from the node (via SSH) to Pod B's IP, which tests node-to-pod connectivity, not pod-to-service connectivity from within Pod A.

Full explanation →

165

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

StatefulSets are designed to provide a stable, unique identity to each pod they manage, which is crucial for stateful applications. This identity includes a stable network hostname, typically in the format `$(pod-name).$(headless-service-name)`, and persistent storage that remains associated with the pod's ordinal index even if the pod is rescheduled to a different node. This ensures data integrity and consistent application behavior across pod lifecycle events.

Why this answer

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 →

166

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

kubectl config current-context is the dedicated subcommand that reads the kubeconfig file and prints the name of the currently active context to standard output. It returns exactly one line—the context name—with no additional formatting, making it ideal for scripting and automation. This directly satisfies the admin's need to view the current context, so it is the correct command.

Why this answer

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

167

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 command correctly uses the `--from-file` flag, which instructs `kubectl` to read the entire content of the specified file, `config.properties`. It then creates a ConfigMap named `app-config` where the key for this entry defaults to the filename, `config.properties`, and its corresponding value is the complete textual content of that file. This is the standard and intended method for incorporating file contents directly into a ConfigMap.

Why this answer

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

168

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

Executing `kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local` is the most direct and effective method for debugging DNS resolution issues from within a specific pod. This command leverages `kubectl exec` to run `nslookup` directly inside `my-pod`, utilizing that pod's `/etc/resolv.conf` and its configured DNS server. It precisely tests whether the pod itself can successfully resolve the fully qualified domain name (FQDN) of the `kubernetes` service, providing immediate insight into its DNS capabilities.

Why this answer

`kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local` runs the `nslookup` command directly inside the running pod, which uses the pod's configured DNS resolver (typically CoreDNS) to resolve the Kubernetes service FQDN. This is the standard method to test DNS resolution from within a pod, as it bypasses any external DNS and validates the cluster's internal DNS chain.

Exam trap

The trap here is that candidates often choose Option B (curl) thinking it tests DNS, but curl tests HTTP connectivity, not resolution; or they choose Option C (kubectl run) which creates a new pod with default DNS settings, missing the specific pod's DNS configuration that may be the root cause of the issue.

How to eliminate wrong answers

Option A is wrong because `kubectl describe svc kubernetes -n default` only shows the service's metadata and endpoints, not DNS resolution; it does not test the pod's ability to resolve the name. Option B is wrong because `curl` tests HTTP connectivity, not DNS resolution; a successful curl could still hide a DNS failure if the IP is cached or resolved via other means, and busybox may not include curl by default. Option C is wrong because `kubectl run test --image=busybox -- nslookup ...` creates a new ephemeral pod, which is unnecessary and slower; it also does not test DNS from the existing pod that is experiencing the issue, missing the specific pod's DNS configuration (e.g., dnsPolicy, resolv.conf).

Full explanation →

169

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 (IP Virtual Server) is a kernel-level transport-layer load balancer that exposes multiple scheduling algorithms, including round-robin (rr), least-connections (lc), destination hashing (dh), and source hashing (sh). kube-proxy in IPVS mode programs these algorithms into the kernel, allowing operators to select a traffic distribution strategy that best fits their workload instead of being limited to iptables' simple random or default behavior.

Why this answer

IPVS (IP Virtual Server) supports multiple load balancing algorithms, such as round-robin, least-connection, source-hashing, and others, which is a key advantage over iptables mode. This allows kube-proxy to distribute traffic across pods more flexibly and efficiently, especially in high-traffic environments.

Exam trap

The trap here is that candidates often confuse IPVS with iptables, assuming IPVS still relies on iptables rules for service discovery, when in fact IPVS uses a separate kernel-level mechanism with its own scheduling algorithms.

How to eliminate wrong answers

Option B is wrong because IPVS uses a hash table and kernel-level load balancing, not iptables rules, for service discovery and packet forwarding; iptables mode is a separate kube-proxy mode. Option C is wrong because IPVS is not the default mode since Kubernetes 1.0; iptables mode was the default for many years, and IPVS became an optional mode later (introduced as alpha in 1.8 and stable in 1.11). Option D is wrong because IPVS is specifically designed to handle large numbers of services efficiently, using a hash table that scales better than iptables linear rule processing.

Full explanation →

170

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

kubectl logs api-6f4d7b9d4c-abcde -n production --previous is the correct command because it fetches the stdout/stderr from the previous, now-terminated container instance in the pod. In a CrashLoopBackOff, the currently restarted container usually has no useful logs — it may not have started, or it immediately restarted before writing anything — while the last crashed instance carries the actual error that triggered the restart. This gives you the application-level failure message (e.g., uncaught exception, missing config, listen EADDRINUSE) needed to fix the root cause; pair it with kubectl describe pod to see the last exit code and restart count.

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 →

171

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

The pod is pending because the single node in the cluster (0/1 nodes available) has two blocking issues: 1) Insufficient memory to satisfy the pod's request, and 2) a control-plane taint that the pod does not tolerate. To resolve this and allow the pod to schedule on this node, both issues must be addressed: you must reduce the memory request in the container spec to fit the available memory (Option A) AND add a toleration for the control-plane taint to the pod spec (Option E).

Exam trap

In a single-node cluster (indicated by '0/1 nodes are available'), any scheduling failure message lists all reasons why that single node failed. You must resolve all listed constraints (both the taint and the resource insufficiency) for the pod to schedule.

Full explanation →

172

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

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

173

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 →

174

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 →

175

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

If a container demands more memory than its limit allows, the image has already been successfully pulled and the container has started, so the failure mode is OOMKilled or an overloaded kubelet eviction, not ImagePullBackOff. ImagePullBackOff is exclusively a pre-start image acquisition failure, making this the one option that could never produce that state.

Why this answer

Insufficient memory would cause OOMKilled, not ImagePullBackOff. ImagePullBackOff is caused by issues pulling the container image: wrong image name (C), nonexistent tag (B), authentication failure (A), or registry unreachable. Options A, B, and C are all common causes of ImagePullBackOff.

Full explanation →

176

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

The `kubectl describe pod` command is the correct diagnostic because it aggregates the pod's status conditions, container states, and, crucially, the recent Events list from the kubelet and the image puller. For an `ImagePullBackOff`, the events will contain a specific reason such as `ErrImagePull`, `ImagePullBackOff`, `Failed to pull image`, or a registry authentication/not found error with the exact HTTP status. This detailed output is exactly what you need to pinpoint whether the problem is a typo in the image tag, missing credentials, or network connectivity to the registry.

Why this answer

`kubectl describe pod <pod-name>` provides detailed event logs, including the exact error message from the kubelet when it failed to pull the container image. This output includes the reason for the ImagePullBackOff state, such as authentication failures, image not found, or network issues, which is the most comprehensive information for troubleshooting.

Exam trap

The trap here is that candidates often think `kubectl logs` will show the error, but since the container never started, there are no logs; the real diagnostic data is in the pod's events and status conditions, which only `kubectl describe` reveals.

How to eliminate wrong answers

Option A is wrong because `kubectl get pod` only shows the current status (e.g., ImagePullBackOff) without any details about why the pull failed. Option B is wrong because `kubectl logs <pod-name>` retrieves container logs, but if the container never started due to an image pull failure, there are no logs to display. Option C is wrong because `kubectl edit pod <pod-name>` opens the pod specification for editing, which does not show the pull failure reason; it only allows you to modify the pod definition, which is not diagnostic.

Full explanation →

177

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 exhibit's event message contains the exact Kubernetes error string: the secret `my-secret` could not be found in the pod's namespace, so the kubelet is unable to inject the environment variable or volume content required by the container spec. Every Secret reference is namespaced, and the kubelet queries the API server for the secret exactly as it appears in the pod manifest; any typo, wrong namespace, or omitted resource will immediately produce this failure. Because the error is explicit and points to a missing API object, the most likely cause is that `my-secret` simply does not exist in the namespace where the Pod is running.

Why this answer

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 →

178

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 canonical way to specify resource requirements in Kubernetes: each container has a `resources` field containing `requests` and `limits`. The `cpu` value `"500m"` means 500 milliCPUs (half a core), and `"1"` means one full core; memory uses binary suffixes, with `"512Mi"` and `"1Gi"` being valid mebibyte units. These strings are parsed by Kubernetes quantity format, and this structure is accepted by the API server while satisfying both scheduling and kubelet constraints.

Why this answer

Options C and D are both correct. Option C uses the correct YAML structure with a `resources` block containing both `requests` and `limits`, and specifies CPU as a string (e.g., "500m") and memory as a string (e.g., "512Mi"). Option D is also valid because Kubernetes allows specifying only `limits` without `requests`; the request defaults to the limit if omitted.

Both options conform to the Kubernetes API specification for resource management in Pod containers. Options A, B, and E contain invalid syntax: A uses CPU and memory directly under the container without a resources block; B uses the singular `resource` instead of the plural `resources`; E uses invalid units ('millicores' and 'MB').

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 →

179

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

kubectl config current-context is the dedicated kubectl subcommand that prints exactly the name of the context currently selected for use, reading the current-context field from your kubeconfig. It is the most direct, script-friendly way to determine which cluster and user your kubectl commands will target, and it returns a nonzero exit status if no current context is set.

Why this answer

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

180

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

etcdctl snapshot save <filename> is the canonical etcd backup operation: it connects to the etcd endpoint (default https://127.0.0.1:2379), takes a consistent point-in-time snapshot of the keyspace, and writes it to the specified file. The resulting snapshot is the input used by etcdctl snapshot restore to rebuild a cluster, and it should be created with endpoint, CA, cert, and key flags when TLS is enabled.

Why this answer

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

181

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

`kubectl describe pod pod-name` is a correct first step because it shows container states (Waiting, Running, Terminated) with detailed reason and message fields—for example, `CrashLoopBackOff`, `ImagePullBackOff`, or `OOMKilled`. It also lists recent events specific to that pod, such as failed volume mounts or failed liveness probes, which directly explain why a container may have never produced logs or why its log stream was cut short. When `kubectl logs` returns nothing, this command reveals whether the container even started, and if it did, what caused it to terminate or restart, making it an essential troubleshooting action.

Why this answer

Run 'kubectl describe pod pod-name' (option C) to check container state and events, and 'kubectl logs --previous pod-name' (option D) to retrieve logs from the previous container instance if the pod restarted. These are the two most direct steps to troubleshoot missing logs.

Full explanation →

182

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

A Kubernetes Service only forwards traffic to Pod IPs listed in its Endpoints object, which are populated by the controller based on matching selectors and the readiness status of pods. If the selector matches no pods, or the pods are not Ready (e.g., failing readiness probes or CrashLoopBackOff), the Endpoints object is empty, so connections to the Service's ClusterIP are dropped or refused. Running 'kubectl get endpoints' is the quickest way to confirm whether the Service actually has healthy, Ready backends, directly exposing the most common cause of communication failure.

Why this answer

Options B, C, and E are correct. Checking endpoints (B) verifies the service has healthy pods. Exec into the pod and using curl (C) tests connectivity to the service's cluster IP.

Exec into the pod and running nslookup (E) checks DNS resolution of the service name. Option A checks node status, which is not directly related to pod-to-pod communication via service name. Option D checks logs of the target pod, which may not reveal network issues.

Full explanation →

183

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

This is the correct Fully Qualified Domain Name (FQDN) for a Kubernetes service. It adheres to the standard format: `<service-name>.<namespace-name>.svc.<cluster-domain>`. Here, `my-service` is the service name, `ns1` is its namespace, `svc` denotes it as a service, and `cluster.local` is the default cluster domain. This FQDN provides an unambiguous and universally resolvable address for the service from any pod within the cluster, regardless of the querying pod's own namespace.

Why this answer

Kubernetes DNS resolves services using the FQDN format `<service>.<namespace>.svc.cluster.local`. Since the pod in namespace 'ns2' needs to resolve 'my-service' which resides in namespace 'ns1', the FQDN must include the target namespace 'ns1' to perform a cross-namespace DNS lookup. Omitting the namespace would default to the pod's own namespace, which would fail to resolve the service.

Exam trap

The trap here is that candidates often forget to include the namespace in the FQDN for cross-namespace service resolution, assuming that the default search path will find the service, but it only searches the pod's own namespace first and will not resolve a service in a different namespace without the explicit namespace qualifier.

How to eliminate wrong answers

Option A is wrong because it omits the namespace, so the DNS query would default to the pod's own namespace (ns2), not ns1, and would not resolve the service. Option B is wrong because it uses the incorrect domain suffix 'cluster.local' without the 'svc' subdomain; Kubernetes DNS records for services are always under 'svc.cluster.local', not directly under 'cluster.local'. Option D is wrong because it specifies namespace 'ns2', which is the pod's own namespace, not the namespace where the service actually exists (ns1); this would only work if the service were in ns2.

Full explanation →

184

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

The ReadWriteOnce (RWO) access mode permits a PersistentVolume to be mounted as read-write by a single node at any given time. Crucially, once mounted by that node, any number of pods scheduled onto that specific node can concurrently access the volume for both reading and writing operations. This perfectly satisfies the question's requirement for multiple pods to read and write, provided they are co-located on the same host.

Why this answer

ReadWriteOnce (RWO) allows a PersistentVolume to be mounted as read-write by a single node, but multiple pods on that same node can all access the volume simultaneously. This is because the access mode restriction is per node, not per pod, so all pods scheduled on the same node share the same mount and can read and write concurrently.

Exam trap

The trap here is that candidates often confuse 'node-level' access with 'pod-level' access, mistakenly thinking ReadWriteOnce means only one pod can use the volume, when in fact it allows multiple pods on the same node to read and write concurrently.

How to eliminate wrong answers

Option B (ReadOnlyMany) is wrong because it only permits read-only access, not read-write, and the question explicitly requires both reading and writing. Option C (ReadWriteMany) is wrong because it allows read-write access from multiple nodes, not just multiple pods on the same node, and it requires a distributed filesystem (e.g., NFS, GlusterFS) that supports concurrent node access, which is broader than the scenario described. Option D (ReadWriteOncePod) is wrong because it restricts the volume to a single pod on a single node, preventing multiple pods from accessing it simultaneously even on the same node.

Full explanation →

185

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

The kube-proxy is the essential component on each worker node responsible for implementing the Kubernetes Service abstraction. It continuously watches the Kubernetes API server for Service and EndpointSlice objects and translates them into network rules, typically using iptables or IPVS, within the node's kernel. This ensures that requests directed to a Service IP are correctly routed and load-balanced to the healthy Pods backing that Service, effectively maintaining the data plane for cluster networking.

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 →

186

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

The emptyDir volume type is created when a Pod is assigned to a node and exists as long as the Pod is running. It provides a shared writable directory for all containers within the same Pod, and its contents are deleted when the Pod is removed from the node. This makes it the correct choice for ephemeral data sharing between containers.

Exam trap

The trap here is that candidates often confuse emptyDir with hostPath, thinking hostPath also provides ephemeral storage, but hostPath data persists on the node even after the Pod is deleted, which violates the requirement of data deletion upon Pod removal.

How to eliminate wrong answers

Option A is wrong because hostPath mounts a file or directory from the host node's filesystem into the Pod, and the data persists on the node even after the Pod is deleted, which does not match the requirement of data being deleted with the Pod. Option C is wrong because configMap is used to inject configuration data into Pods as files or environment variables, and it is not designed for sharing writable data between containers; its data is read-only by default and persists independently of the Pod lifecycle. Option D is wrong because secret is used to store sensitive information like passwords or tokens, and while it can be mounted into containers, it is read-only and not intended for ephemeral data sharing between containers.

Full explanation →

187

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

kubectl describe pod pod-name is correct for CrashLoopBackOff because it displays the pod's full lifecycle events, container states, restart counts, and the last reason/exit code from the previous terminated container. Those events often reveal the root cause, such as image pull failures, failed readiness/liveness probes, or OOMKilled. It also shows the current backoff state and timestamps, making it the first diagnostic command to run.

Why this answer

`kubectl describe pod pod-name` provides detailed information about the pod's current state, including recent events, container restart counts, and the reason for the CrashLoopBackOff (e.g., exit code 137 from OOMKill or 1 from application error). This is the first step to understand the root cause of the crash loop.

Exam trap

The CKA exam often tests the misconception that `kubectl exec` can be used to debug a crashing pod, but in CrashLoopBackOff the container is not running, so exec fails; candidates must remember to use `kubectl logs --previous` to access logs from the terminated instance.

Full explanation →

188

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

A NetworkPolicy with an empty `podSelector: {}` targets all pods within its namespace. When no `ingress` rules are explicitly defined, or an empty `ingress: []` array is present, and `policyTypes` implicitly defaults to `["Ingress"]`, the policy effectively denies all incoming network connections to these selected pods. This creates a secure-by-default posture for ingress traffic across the entire namespace, preventing any external or internal pod-to-pod communication unless explicitly allowed by another policy.

Why this answer

A NetworkPolicy with a podSelector matching all pods and no rules defaults to denying all ingress traffic because the policy's empty `ingress` rules array means no traffic is allowed. This implements a default-deny ingress behavior for the selected pods, as Kubernetes NetworkPolicy rules are whitelist-based: any traffic not explicitly allowed is denied.

Exam trap

The trap here is that candidates assume an empty policy has no effect, but in Kubernetes, a NetworkPolicy with no rules creates a default-deny for the selected direction (ingress or egress), which is a common point of confusion in the CKA exam.

How to eliminate wrong answers

Option A is wrong because a NetworkPolicy does not require at least one rule to take effect; an empty rules array still creates a policy that denies all ingress traffic. Option B is wrong because NetworkPolicy does not have implicit allow rules; it operates on a whitelist model where no rules means no traffic is permitted. Option D is wrong because this policy has no `egress` rules specified, so it does not affect egress traffic; egress is only denied if an egress rule is present or if a separate egress policy is applied.

Full explanation →

189

MCQeasy

Which kubectl command will show the rollout history of a Deployment named 'web-app'?

A.kubectl describe deployment web-app

B.kubectl rollout status deployment web-app

C.kubectl rollout history deployment web-app

D.kubectl get deployment web-app -o yaml

AnswerC

kubectl rollout history deployment web-app is correct because it is the dedicated kubectl subcommand for viewing the Deployment's rollout history. It lists all revisions with their change-cause annotations (if set), and can be combined with --revision to inspect a specific revision; this history is actually derived from the underlying ReplicaSets created for each change to the pod template.

Why this answer

`kubectl rollout history deployment web-app` is the dedicated command to display the rollout history of a Deployment, including revision numbers and change-cause annotations. This command retrieves the stored ReplicaSet revisions associated with the Deployment, allowing you to see past rollout states.

Exam trap

The trap here is that candidates confuse `rollout status` (which shows live progress) with `rollout history` (which shows past revisions), or assume `describe` or `get -o yaml` will expose the revision list, but neither command formats the rollout history in the concise, revision-based output that `rollout history` provides.

How to eliminate wrong answers

Option A is wrong because `kubectl describe deployment web-app` shows the current state and metadata of the Deployment, but does not display the rollout history or revision list. Option B is wrong because `kubectl rollout status deployment web-app` shows the current progress of a rollout (e.g., waiting for pods to become ready), not the historical record of past rollouts. Option D is wrong because `kubectl get deployment web-app -o yaml` outputs the full YAML manifest of the Deployment, which includes the `spec.revisionHistoryLimit` and `status.observedGeneration` but does not present the formatted rollout history with revision numbers and change-causes.

Full explanation →

190

MCQhard

You have a ResourceQuota in a namespace that sets limits: pods: 10, requests.cpu: 4, requests.memory: 8Gi. You try to create a Pod with requests.cpu: 1, requests.memory: 2Gi, and no limits. The namespace currently has 8 pods using 3 CPUs and 5Gi memory in total requests. What happens?

A.The pod is created successfully.

B.The pod is rejected because it exceeds the memory request quota.

C.The pod is rejected because it exceeds the CPU request quota.

D.The pod is rejected because it does not specify CPU and memory limits.

AnswerA

The new pod's resource requests are 1 CPU and 2Gi memory. When combined with the existing pods' total requests of 3 CPU and 5Gi memory, the cumulative resource consumption becomes 4 CPU and 7Gi memory. Since the ResourceQuota specifies hard limits of 4 CPU and 8Gi memory for requests, both the CPU and memory totals remain at or below their respective quotas. Therefore, the admission controller allows the pod to be created without any quota violations.

Why this answer

The ResourceQuota only enforces the total sum of requests across all pods in the namespace. Currently, the namespace has 8 pods using 3 CPUs and 5Gi memory. Adding a pod with requests.cpu: 1 and requests.memory: 2Gi would bring totals to 4 CPUs (3+1) and 7Gi memory (5+2), both within the quota limits of 4 CPUs and 8Gi.

The pod does not specify limits, but ResourceQuota does not require limits unless a LimitRange enforces default limits; here, no LimitRange is mentioned, so the pod is allowed.

Exam trap

The trap here is that candidates often assume a ResourceQuota enforces both requests and limits simultaneously, or that creating a pod without limits will be rejected, but Kubernetes only rejects pods if the sum of requests (or limits, if specified) would exceed the quota, and it does not require limits unless a LimitRange is present.

How to eliminate wrong answers

Option B is wrong because the total memory requests after creation would be 7Gi, which is under the 8Gi quota limit, so it does not exceed the memory request quota. Option C is wrong because the total CPU requests after creation would be exactly 4 CPUs, which is at the quota limit but not exceeded (the quota allows up to 4 CPUs, and equality is permitted). Option D is wrong because ResourceQuota does not require pods to specify CPU and memory limits; it only enforces requests and limits if they are set, and without a LimitRange, a pod can be created without limits.

Full explanation →

191

Multi-Selecthard

Which THREE of the following are valid ways to restrict or influence pod scheduling using taints and tolerations? (Select THREE.)

Select 3 answers

A.Adding a taint with effect NoSchedule to a node

B.Adding a toleration to a pod to prevent it from being scheduled on certain nodes

C.Adding a taint with effect PreferNoSchedule to a node

D.Applying a nodeSelector to a pod to match node labels

E.Adding a taint with effect NoExecute to a node

AnswersA, C, E

A NoSchedule taint on a node instructs the Kubernetes scheduler to exclude any Pod that does not have a matching toleration from being placed onto that node. It is a hard scheduling constraint: the scheduler will not assign new Pods to that node unless the Pod's toleration matches the taint's key, value, and effect. However, Pods already running on the node are not evicted by this effect, so it is useful for cordoning off nodes for maintenance without disrupting workloads.

Why this answer

Adding a taint with effect NoSchedule (option A) prevents scheduling of pods without matching tolerations onto the node. Adding a taint with effect PreferNoSchedule (option C) is a soft preference that tries to avoid scheduling pods without tolerations onto the node but does not guarantee it. Adding a taint with effect NoExecute (option E) not only prevents scheduling but also evicts any existing pods that do not tolerate the taint.

Options B and D are not valid uses of taints and tolerations: tolerations allow pods to be scheduled on tainted nodes, not prevent scheduling, and nodeSelector is a separate mechanism not based on taints and tolerations.

Exam trap

The trap here is that candidates often confuse tolerations as a way to repel pods from nodes, when in fact tolerations allow pods to be scheduled onto tainted nodes, while taints themselves repel pods.

Full explanation →

192

MCQhard

A cluster has a PersistentVolumeClaim (PVC) named 'data-claim' bound to a PersistentVolume (PV) with reclaim policy 'Retain'. The PVC is deleted. The PV now shows status 'Released'. What must be done so that the PV can be reused by a new PVC?

A.Nothing; the PV will automatically become Available after some time.

B.Delete and recreate the PersistentVolume.

C.Create a new PVC with the same name.

D.Change the reclaim policy to Delete.

AnswerB

Deleting and recreating the PersistentVolume resource is a standard and clean way to make the underlying storage available for new claims. Because the reclaim policy is Retain, deleting the Kubernetes PV object does not destroy the actual data on the external storage provider. Recreating the PV with the same storage details allows a new PVC to bind to it successfully.

Why this answer

When a PVC is deleted and the PV has a reclaim policy of 'Retain', the PV enters a 'Released' state, meaning it still contains the data but is no longer bound to the original PVC. The PV cannot be directly reused by a new PVC because its claim reference is still set to the deleted PVC's UID. To make the PV available again, you must manually delete and recreate the PV (or at least delete it and re-create it with a clean claimRef), which resets its status to 'Available'.

Exam trap

The CKA exam often tests the misconception that a 'Released' PV will automatically become 'Available' over time, but the 'Retain' policy requires explicit administrative action to clear the claim reference.

How to eliminate wrong answers

Option A is wrong because a PV with reclaim policy 'Retain' does not automatically transition from 'Released' to 'Available'; manual intervention is required. Option C is wrong because creating a new PVC with the same name does not clear the existing PV's claimRef; the PV remains 'Released' and will not bind to the new PVC unless the PV is manually cleaned. Option D is wrong because changing the reclaim policy to 'Delete' would cause the PV to be deleted (and its underlying storage potentially removed), not make it 'Available' for reuse; the correct action is to delete and recreate the PV.

Full explanation →

193

MCQmedium

Which component is responsible for implementing the NetworkPolicy rules?

A.CoreDNS

B.kube-controller-manager

C.kube-proxy

D.CNI plugin

AnswerD

The correct answer is the CNI plugin. The Container Network Interface plugin manages pod networking and, depending on the implementation (e.g., Calico, Cilium, Weave, or Antrea), also enforces NetworkPolicy by programming dataplane rules. When a NetworkPolicy is created or updated, the CNI plugin receives the pod metadata and translates the allow/deny rules into iptables, eBPF, or other forwarding constructs. Without a CNI plugin that supports NetworkPolicy, the rules are stored by the API server but have no effect on traffic.

Why this answer

NetworkPolicy rules are enforced by the Container Network Interface (CNI) plugin, not by kube-proxy or any other Kubernetes control plane component. The CNI plugin (e.g., Calico, Cilium, Weave Net) implements the actual network policy by programming iptables, eBPF, or other data-plane mechanisms to allow or deny traffic between pods based on the policy selectors and rules defined in the NetworkPolicy resource.

Exam trap

The trap here is that candidates often confuse kube-proxy's role in service traffic with network policy enforcement, but kube-proxy only handles load balancing for Services, not the pod-to-pod access control defined by NetworkPolicy.

How to eliminate wrong answers

Option A is wrong because CoreDNS is the cluster DNS resolver, responsible for service discovery and name resolution, not for enforcing network traffic policies. Option B is wrong because kube-controller-manager runs controllers like the Node Controller and Replication Controller, but it does not handle packet filtering or network policy enforcement. Option C is wrong because kube-proxy implements service load balancing (via iptables, IPVS, or userspace mode) and handles cluster IP traffic, but it does not enforce NetworkPolicy rules; those are implemented by the CNI plugin at the pod network level.

Full explanation →

194

Multi-Selectmedium

Which TWO components are part of the Kubernetes control plane? (Select two.)

Select 2 answers

A.kubelet

B.etcd

C.kube-proxy

D.container runtime

E.kube-controller-manager

AnswersB, E

etcd is a distributed, strongly consistent key-value store that holds the authoritative state of the entire Kubernetes cluster, including all objects, configs, and secrets. It is a foundational control plane component because every API read/write is persisted there, and control plane controllers rely on its data. Without a healthy etcd quorum, the cluster cannot function correctly.

Why this answer

etcd is a distributed key-value store that serves as the primary datastore for the Kubernetes cluster, storing all cluster state and configuration data. The kube-controller-manager runs controller processes that regulate the state of the cluster, such as the node controller, replication controller, and endpoints controller. Both are core control plane components that run on the master node(s).

Exam trap

CNCF often tests the distinction between control plane components and node-level agents; the trap here is that candidates confuse kubelet or kube-proxy as control plane components because they are essential to cluster operation, but they actually run on every node and are not part of the control plane.

Full explanation →

195

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 →

196

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 →

197

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 →

198

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 →

199

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

Why this answer

Kube-proxy is responsible for implementing ClusterIP Service networking rules (iptables/IPVS) on each node; if it is not running, traffic to the Service's ClusterIP will not be forwarded to endpoints. Option B is correct because if the container is listening on a different port than the Service's targetPort, the connection will fail at the pod level. Option C is incorrect because a failing readiness probe would cause the pod to be removed from the Service's endpoints, contradicting the premise that the Service has endpoints.

Option D is incorrect because service name length is not a factor for reachability (max is 63 characters).

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 →

200

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 →

201

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

Memory pressure prevents the scheduler from placing the pod on that node.

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 →

202

MCQhard

A cluster was upgraded from v1.28 to v1.29 using kubeadm. After upgrading the control plane, nodes remain at v1.28. What is the correct next step to upgrade a worker node?

A.Drain the node, then run 'kubeadm upgrade node' on the worker node.

B.SSH into the worker node and run 'kubeadm upgrade node', then upgrade kubelet and kubectl, then restart kubelet.

C.Upgrade kubelet on the worker node using the package manager and restart kubelet.

D.Run 'kubeadm upgrade apply' on the worker node.

AnswerB

This is the standard procedure for upgrading a worker node with kubeadm.

Why this answer

After upgrading the control plane with kubeadm, worker nodes must be upgraded individually. The correct sequence is to SSH into the worker node, run 'kubeadm upgrade node' to upgrade the kubelet configuration and static pod manifests, then upgrade the kubelet and kubectl binaries (typically via the package manager), and finally restart the kubelet to pick up the new version. This ensures the node runs the same Kubernetes version as the control plane.

Exam trap

The trap here is that candidates often assume simply upgrading the kubelet binary via the package manager is sufficient, but the CKA exam tests the understanding that 'kubeadm upgrade node' must be run first to update the node's configuration and static pod manifests, ensuring a complete and consistent upgrade.

How to eliminate wrong answers

Option A is wrong because 'kubeadm upgrade node' is the correct command, but draining the node before running it is not strictly required as the first step; the standard procedure is to upgrade the node first, then drain and uncordon as needed for workload migration. Option C is wrong because upgrading only the kubelet binary without running 'kubeadm upgrade node' will not update the node's kubelet configuration or static pod manifests, leading to version mismatches and potential cluster instability. Option D is wrong because 'kubeadm upgrade apply' is used only on the control plane node to upgrade the cluster state; running it on a worker node is invalid and will fail.

Full explanation →

203

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 →

204

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 →

205

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 →

206

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 →

207

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 →

208

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 error '0/3 nodes are available: 3 node(s) didn't match node selector' directly indicates that the pod has a nodeSelector that does not match any node's labels. Option A (PVC not bound) would show a different error like 'persistentvolumeclaim not found'. Option B (insufficient resources) would show 'Insufficient memory/cpu'.

Option C (taints not tolerated) would show 'node(s) had taints'. Therefore, the most likely cause is that the pod's nodeSelector does not match any node labels, which is Option D.

Full explanation →

209

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

RWX allows multiple nodes to mount the volume as read-write.

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 →

210

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 →

211

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 →

212

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 →

213

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 →

214

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 →

215

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 →

216

Multi-Selectmedium

You want to check resource usage of pods and nodes. Which TWO commands should you use?

Select 2 answers

A.kubectl top pod --nodes

B.kubectl top pods

C.kubectl top nodes

D.kubectl resource usage

E.kubectl top node --containers

AnswersB, C

Shows CPU/memory usage of pods.

Why this answer

To check resource usage, use `kubectl top pods` (B) for pods and `kubectl top nodes` (C) for nodes. The incorrect options use invalid flags: `kubectl top pod --nodes` and `kubectl top node --containers` are not supported, making them syntactically invalid.

Full explanation →

217

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 →

218

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 →

219

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 →

220

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 →

221

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

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/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 →

222

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 →

223

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 →

224

MCQeasy

A developer accidentally runs 'kubectl delete pvc data-claim'. What is the immediate effect on the PersistentVolume pv-data?

A.The PV pv-data is automatically deleted.

B.The PV pv-data remains Bound to the deleted PVC.

C.The PV pv-data immediately becomes Available and can be reused.

D.The PV pv-data enters the Released state and is not deleted.

AnswerD

With the Retain reclaim policy configured, deleting the bound PVC causes the PV to enter the Released state rather than being deleted or recycled. This means the PV still exists and its underlying storage resources—such as disk data—remain intact, but it is no longer bound to any claim. The PV will remain in Released status until an administrator manually intervenes, typically by deleting the PV and recreating it or by editing its claimRef to allow rebinding. This preserves data for recovery but leaves the PV unused until explicit manual action is taken.

Why this answer

When a PVC is deleted, the associated PV enters the 'Released' state, not 'Available'. This is because the PV still contains data from the previous claim (the retain policy is 'Retain' by default), and Kubernetes does not automatically delete or reuse it. The PV remains in 'Released' until an administrator manually clears the claimRef or deletes the PV.

Exam trap

The trap here is that candidates assume the PV's reclaim policy is 'Delete' by default, or that deleting a PVC automatically makes the PV 'Available' for reuse, when in fact the default policy is 'Retain' and the PV enters 'Released'.

How to eliminate wrong answers

Option A is wrong because the PV is not automatically deleted when the PVC is deleted; the PV's lifecycle is independent and depends on its reclaim policy (default is 'Retain'). Option B is wrong because the PV does not remain 'Bound' to the deleted PVC; the binding is removed, and the PV transitions to 'Released'. Option C is wrong because the PV does not immediately become 'Available'; it enters 'Released' and cannot be reused until the claimRef is manually cleared by an administrator.

Full explanation →

225

Multi-Selecteasy

Which TWO of the following are valid commands to check the status of control plane components?

Select 2 answers

A.systemctl status kube-apiserver

B.kubectl get nodes

C.kubectl get pods -n kube-system

D.kubectl get events --all-namespaces

E.kubectl top nodes

AnswersA, C

On clusters where control plane components are managed by systemd (e.g., packaged Kubernetes distributions or those set up with kubeadm before static pods became the default), `systemctl status kube-apiserver` queries the service manager for the exact process state, reporting whether the service is active, running, or failed. It also surfaces recent journal logs, making it a direct and authoritative check of the kube-apiserver service. However, this command is only valid when the component actually runs as a systemd unit; on clusters using static pods, it would return an error, so it is environment-specific but nonetheless a correct approach for systemd-based clusters.

Why this answer

`systemctl status kube-apiserver` directly queries the systemd service manager for the status of the kube-apiserver process, which is a core control plane component. Option C is correct because `kubectl get pods -n kube-system` lists all pods in the kube-system namespace, which includes control plane components like etcd, kube-scheduler, and kube-controller-manager when they run as static pods or Deployments. Both commands provide direct visibility into the health of control plane components.

Exam trap

The CKA exam often tests the distinction between commands that check node-level health versus component-level health, trapping candidates who confuse `kubectl get nodes` (node status) with direct control plane component checks.

Full explanation →

Certified Kubernetes Administrator CKA (CKA) — Questions 151–225