Certified Kubernetes Administrator CKA CKA Questions 601–675 | Page 9/10

601

MCQeasy

You want to view the resource usage of all pods in the cluster. What command should you run?

A.kubectl top pods --all-namespaces

B.kubectl describe nodes

C.kubectl get pods -o wide

D.kubectl top nodes

AnswerA

kubectl top pods --all-namespaces is the correct command because it retrieves current CPU and memory utilization for every pod running in every namespace. It sources these figures from the metrics API (backed by metrics-server) and displays them per pod along with the pod's namespace and node. Because the question asks for resource usage of all pods cluster-wide, this command is the only one that directly provides that data without omitting any namespace.

Why this answer

The `kubectl top pods --all-namespaces` command retrieves real-time CPU and memory usage metrics for all pods across every namespace in the cluster. This is the correct way to view resource usage of all pods, as it relies on the metrics server to collect and expose pod-level resource consumption data.

Exam trap

CNCF often tests the distinction between `kubectl top pods` and `kubectl top nodes`, where candidates mistakenly choose `kubectl top nodes` thinking it covers all pods, but it only shows node-level aggregates, not per-pod usage.

How to eliminate wrong answers

Option B is wrong because `kubectl describe nodes` shows node-level resource capacity, requests, and limits, but does not display actual real-time resource usage of individual pods. Option C is wrong because `kubectl get pods -o wide` only lists pod metadata and IP addresses, not resource usage metrics. Option D is wrong because `kubectl top nodes` shows aggregate node-level CPU and memory usage, not per-pod resource usage.

Full explanation →

602

MCQmedium

You are troubleshooting DNS resolution from within a pod. You exec into the pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command fails with 'connection timed out; no servers could be reached'. However, 'kubectl get svc -n kube-system' shows the kube-dns service with a ClusterIP. What is the MOST likely cause?

A.The CoreDNS pods are not running or are crashing

B.The pod's /etc/resolv.conf has incorrect search domains

C.A network policy is blocking traffic to the kube-dns service

D.The DNS name does not exist

AnswerA

This is the correct answer because if the CoreDNS pods are not running or are crashing, the Kubernetes `kube-dns` service will have no healthy endpoints. The `kube-proxy` component, responsible for managing service IPs, will be unable to forward DNS queries from pods to any functional CoreDNS instance. Consequently, any DNS lookup attempt from a pod will result in a connection timeout as the query never reaches an active DNS server to be processed.

Why this answer

The error 'connection timed out; no servers could be reached' from nslookup indicates that the pod cannot reach any DNS server at all. Since the kube-dns service exists (as shown by kubectl), the most likely cause is that the backend CoreDNS pods are not running or are crashing, so there are no endpoints to forward traffic to. Without running CoreDNS pods, the service's ClusterIP has no backing pods, causing all DNS queries to time out.

Exam trap

The trap here is that candidates see the kube-dns service exists and assume DNS is working, but they forget that a service without healthy backend pods (CoreDNS) cannot serve requests, leading to timeouts rather than immediate failures.

How to eliminate wrong answers

Option B is wrong because incorrect search domains in /etc/resolv.conf would cause name resolution failures for short names (e.g., 'kubernetes'), but the fully qualified domain name 'kubernetes.default.svc.cluster.local' would still resolve if the DNS server were reachable; the error here is a connection timeout, not a lookup failure. Option C is wrong because a network policy blocking traffic to the kube-dns service would typically result in a connection refused or timeout, but the question states the service exists and the error is a timeout; however, the most likely cause is the CoreDNS pods not running, as network policies are less common in default clusters and would not prevent the service from having endpoints. Option D is wrong because the DNS name 'kubernetes.default.svc.cluster.local' is a standard Kubernetes service name that exists by default; if it did not exist, nslookup would return 'NXDOMAIN' (non-existent domain), not a connection timeout.

Full explanation →

603

MCQeasy

During a 'kubeadm init', the administrator sees the message 'Your Kubernetes control-plane has been initialized successfully!' but the 'kubectl get nodes' shows the control plane node as 'NotReady'. What is the most likely missing step?

A.Generate a join token for worker nodes.

B.Install a CNI plugin such as Calico or Flannel.

C.Copy the kubeconfig to the user's home directory.

D.Check that the kubelet is running on the control plane node.

AnswerB

Kubernetes requires a Container Network Interface (CNI) plugin to establish the pod network. Until a CNI provider like Calico or Flannel is deployed, CoreDNS pods will remain in a Pending state, and the control plane node will report a status of NotReady due to the missing network configuration.

Why this answer

The 'NotReady' status indicates that the kubelet on the control plane node is running but cannot report readiness because the node's network is not configured. A CNI plugin (e.g., Calico, Flannel, Weave) must be installed to set up the pod network, which is required for the kubelet to register the node as 'Ready'. Without a CNI plugin, the node's network conditions remain unmet, and the control plane cannot function properly.

Exam trap

The trap here is that candidates often assume 'kubeadm init' success means the cluster is fully functional, but they overlook the mandatory post-init step of installing a CNI plugin to make the node 'Ready'.

How to eliminate wrong answers

Option A is wrong because generating a join token for worker nodes is only needed after the control plane is fully operational and ready to accept worker nodes; it does not affect the control plane node's own readiness. Option C is wrong because copying the kubeconfig to the user's home directory enables 'kubectl' access but does not resolve the underlying network issue causing the node to be 'NotReady'. Option D is wrong because the 'kubeadm init' success message implies the kubelet is running; if it were not, the initialization would have failed or the node would show a different status (e.g., 'Unknown').

Full explanation →

604

MCQmedium

You initialize a cluster with 'kubeadm init' and want to join a worker node. What is the correct command to generate the join command?

A.kubeadm token create --print-join-command

B.kubeadm join --token <token> <control-plane>:6443

C.kubeadm init phase upload-config kubelet

D.kubeadm token list

AnswerA

This command is the standard way to generate a new bootstrap token and immediately print the complete `kubeadm join` command, including the API server endpoint, the token, and the `--discovery-token-ca-cert-hash`. It simplifies node provisioning by outputting a ready-to-run command for worker nodes.

Why this answer

`kubeadm token create --print-join-command` generates a new bootstrap token and immediately outputs the full `kubeadm join` command, including the token, control-plane endpoint, and discovery token CA cert hash. This is the recommended way to obtain a ready-to-use join command after initializing the cluster with `kubeadm init`.

Exam trap

The trap here is that candidates often assume `kubeadm token list` (Option D) is sufficient to get the join command, but it only shows existing tokens without the required CA cert hash, leading to an incomplete or insecure join attempt.

How to eliminate wrong answers

Option B is wrong because it is an incomplete join command — it lacks the `--discovery-token-ca-cert-hash` flag, which is required for secure discovery of the control plane's CA certificate. Option C is wrong because `kubeadm init phase upload-config kubelet` only uploads the kubelet configuration to a ConfigMap; it does not generate or print a join command. Option D is wrong because `kubeadm token list` only displays existing tokens without printing the full join command, and it does not create a new token if none exist.

Full explanation →

605

MCQmedium

Which kubeconfig context is currently active?

A.kubectl config view

B.kubectl cluster-info

C.kubectl config get-contexts

D.kubectl config current-context

AnswerD

This subcommand reads the kubeconfig's current-context field and prints the name of the context kubectl will use by default, directly answering which context is active. It queries configuration state rather than cluster resources, so no API server call is needed.

Why this answer

`kubectl config current-context` is the dedicated kubectl command that displays the name of the currently active context from the kubeconfig file. The active context determines which cluster, user, and namespace are used by default for kubectl commands, making this the precise way to identify the active context.

Exam trap

The trap here is that candidates often confuse `kubectl config get-contexts` (which shows all contexts with an asterisk on the active one) with a command that directly outputs only the active context, leading them to choose option C instead of the more precise D.

How to eliminate wrong answers

Option A is wrong because `kubectl config view` displays the entire kubeconfig file contents (clusters, users, contexts) but does not explicitly indicate which context is currently active; it requires manual inspection to find the `current-context` field. Option B is wrong because `kubectl cluster-info` shows information about the cluster the current context points to (e.g., control plane endpoints), not the name of the active context itself. Option C is wrong because `kubectl config get-contexts` lists all available contexts and marks the active one with an asterisk (*) in the output, but it does not directly output just the active context name; it requires parsing the list.

Full explanation →

606

Multi-Selecthard

Which FOUR are correct ways to configure a default deny all ingress traffic NetworkPolicy? (Choose 4)

Select 4 answers

A.A NetworkPolicy with podSelector: {} and an ingress rule with from: []

B.A NetworkPolicy with podSelector: {} and an ingress rule with from: [{}]

C.A NetworkPolicy with podSelector: {} and ingress: []

D.A NetworkPolicy with podSelector: {} and no rules at all (only metadata and spec)

E.A NetworkPolicy with podSelector: {} and no ingress rules

AnswersA, C, D, E

An empty from list does not match any sources, but the rule itself is an ingress rule; however, it still results in no allowed traffic, but it's not a default deny pattern (it's an allow rule that allows nothing). The classic default deny has no ingress rules.

Why this answer

Option C is correct because `podSelector: {}` selects all pods in the namespace and `ingress: []` defines an empty ingress rule set, which denies all ingress traffic to those pods. Option D is correct because a NetworkPolicy with `podSelector: {}` and no rules at all (only metadata and spec) has no ingress rules, so it isolates all selected pods and denies all ingress by default. Option E is correct because omitting the `ingress` field entirely is equivalent to having an empty ingress rule set, which denies all ingress traffic to the selected pods.

Option A is also correct: an ingress rule with `from: []` contains an empty list of sources, which matches no sources and therefore allows no ingress traffic; the presence of the rule does not permit traffic because no source matches. Option B is incorrect because `from: [{}]` contains an empty object, which matches all sources and therefore allows all ingress traffic, the opposite of deny all.

Exam trap

The exam often tests the subtle difference between `from: []` (empty array, denies all) and `from: [{}]` (empty object, allows all), as well as the fact that a NetworkPolicy with no rules at all (only podSelector) still enforces a default deny, which candidates may mistakenly think requires an explicit empty ingress list.

Full explanation →

607

MCQeasy

Which command shows the logs of a pod that has crashed and restarted?

A.kubectl logs pod-name --previous

B.kubectl logs pod-name

C.kubectl logs pod-name -c container-name

D.kubectl describe pod pod-name

AnswerA

The --previous flag retrieves log output from the previous terminated container instance. After a pod crashes and the container restarts, the newly started container starts with a fresh log file, so only --previous exposes the output from the failed run that triggered the restart. This is the standard way to diagnose why a container exited.

Why this answer

kubectl logs --previous shows logs from the previous container instance.

Full explanation →

608

MCQmedium

A cluster uses Flannel as the CNI plugin. Which of the following best describes Flannel's networking model?

A.It requires an external etcd to store network state.

B.It uses BGP to distribute routes across the cluster.

C.It provides network policies with full support for ingress and egress rules.

D.It assigns a /24 subnet to each node and uses VXLAN encapsulation.

AnswerD

By default, Flannel allocates a unique /24 IPv4 subnet from a larger pre-configured cluster CIDR to each node and encapsulates inter-node pod traffic using VXLAN (Virtual Extensible LAN) at Layer 2 over Layer 3, facilitating seamless overlay communication.

Why this answer

Flannel's default networking model assigns a /24 subnet to each node and uses VXLAN encapsulation to create an overlay network. This allows pods on different nodes to communicate without requiring changes to the underlying physical network, as VXLAN tunnels traffic between nodes using UDP encapsulation.

Exam trap

The trap here is that candidates confuse Flannel's simple overlay model with more feature-rich CNI plugins like Calico, assuming Flannel supports BGP routing or network policies, when in fact it only provides basic pod-to-pod connectivity via VXLAN encapsulation.

How to eliminate wrong answers

Option A is wrong because Flannel does not require an external etcd; it stores network state in the Kubernetes API server (or optionally in etcd, but not as a mandatory external dependency). Option B is wrong because Flannel does not use BGP to distribute routes; BGP is used by other CNI plugins like Calico. Option C is wrong because Flannel does not natively support Kubernetes Network Policies; it only provides basic connectivity, and network policy enforcement requires a separate component like Calico or Cilium.

Full explanation →

609

Multi-Selectmedium

Which TWO of the following are components of the Ingress API? (Select TWO.)

Select 2 answers

A.rules

B.IngressClass

C.Service

D.Endpoints

E.tls

AnswersA, E

The `rules` field is the core routing engine of the Ingress API; each rule defines an optional hostname and a list of HTTP paths, and each path has an associated `pathType` and a `backend` that references a Service name and port. When a request arrives, the Ingress controller evaluates these rules in order and forwards traffic to the specified backend, making rules the fundamental component for host- and path-based traffic routing.

Why this answer

Option A, rules, is correct because the Ingress spec is fundamentally built around a list of rules that map incoming HTTP/HTTPS host and path requests to backend Services, making rules a core component of the Ingress API. Option E, tls, is correct because the Ingress resource includes a tls field that declares TLS configuration (hosts and secretName) so the ingress controller can terminate TLS for specified hosts. IngressClass (B) is a separate API resource used to select which controller implements an Ingress, not a component inside the Ingress object itself.

Service (C) and Endpoints (D) are distinct core/v1 resources that Ingress rules reference as backends; they are not part of the Ingress API's own structure.

Exam trap

The CKA exam often tests the distinction between fields within the Ingress spec (like `rules` and `tls`) versus separate Kubernetes resources that are referenced by Ingress (like `IngressClass`, `Service`, and `Endpoints`), causing candidates to confuse API components with related but distinct objects.

Full explanation →

610

MCQmedium

A Kubernetes cluster has a Service of type ClusterIP named 'my-svc' in the 'default' namespace. You deploy a pod and want it to resolve the service's cluster IP using DNS. What FQDN should the pod use?

A.my-svc.default.pods.cluster.local

B.my-svc.cluster.local

C.my-svc.default.svc.cluster.local

D.my-svc.default.svc.cluster.com

AnswerC

This is the standard, fully qualified DNS name for a Kubernetes service. CoreDNS creates an A record for every ClusterIP service under <service-name>.<namespace>.svc.<cluster-domain>, so with the service in the default namespace and the standard cluster.local domain, my-svc.default.svc.cluster.local correctly resolves to the service's ClusterIP. Applications can use this FQDN both within and outside the namespace to reach the service.

Why this answer

The standard FQDN for a Kubernetes Service is `<service-name>.<namespace>.svc.cluster.local`. This DNS record resolves to the ClusterIP of the Service, allowing pods to reach it via DNS. The `svc` subdomain is a fixed part of the cluster domain, distinguishing Service records from pod records.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or the namespace, picking a shorter form like `my-svc.cluster.local`, which is not a valid Kubernetes Service FQDN.

How to eliminate wrong answers

Option A is wrong because `pods.cluster.local` is the subdomain for pod DNS records (e.g., for headless Services), not for Services; the correct subdomain for Services is `svc.cluster.local`. Option B is wrong because it omits the namespace and the `svc` subdomain; the FQDN must include `<namespace>.svc` to be valid. Option D is wrong because the cluster domain suffix is `cluster.local`, not `cluster.com`; `cluster.local` is the default DNS domain defined in the kubelet configuration.

Full explanation →

611

MCQmedium

You need to back up etcd data for a cluster running Kubernetes v1.29. Which command correctly creates a snapshot?

A.kubectl etcd snapshot save /backup/snapshot.db

B.etcdctl backup /backup/snapshot.db

C.ETCDCTL_API=2 etcdctl snapshot save /backup/snapshot.db

D.ETCDCTL_API=3 etcdctl snapshot save /backup/snapshot.db

AnswerD

This is the correct command because it explicitly sets the API version to 3 using the ETCDCTL_API=3 environment variable, which is required to access the modern etcd v3 storage engine features. The snapshot save subcommand is the standard, officially supported method to generate a consistent, non-disruptive backup of the cluster's state.

Why this answer

Etcd v3 is the default and supported version in Kubernetes v1.29, and the `ETCDCTL_API=3` environment variable ensures the etcdctl client uses the v3 API, which provides the `snapshot save` command for creating consistent backups. The command `ETCDCTL_API=3 etcdctl snapshot save /backup/snapshot.db` correctly captures a point-in-time snapshot of the etcd data store, which is essential for disaster recovery.

Exam trap

The trap here is that candidates confuse the deprecated etcd v2 API (which uses `etcdctl backup`) with the v3 API (which uses `etcdctl snapshot save`), and they may forget to set `ETCDCTL_API=3` or incorrectly assume `kubectl` can manage etcd snapshots.

How to eliminate wrong answers

Option A is wrong because `kubectl etcd snapshot save` is not a valid kubectl command; kubectl does not have an `etcd` subcommand—etcd operations must be performed using the etcdctl binary directly. Option B is wrong because `etcdctl backup` is not a valid command in either etcd v2 or v3; the correct command for creating a snapshot is `etcdctl snapshot save`, and the `backup` subcommand does not exist. Option C is wrong because `ETCDCTL_API=2` forces the use of the deprecated etcd v2 API, which does not support the `snapshot save` command—the v2 API only offers `etcdctl backup` (which is a different, less reliable mechanism) and is not compatible with Kubernetes v1.29 clusters that use etcd v3.

Full explanation →

612

MCQhard

Which of the following CNI plugins typically uses BGP to distribute routing information across nodes?

A.Calico

B.Flannel

C.Weave

D.Cilium

AnswerA

Calico is highly regarded for its native use of the Border Gateway Protocol (BGP) to distribute routing information among Kubernetes nodes. By acting as a BGP peer, each node advertises its pod IP blocks directly to the physical network infrastructure or to a central BGP Route Reflector. This eliminates the need for packet encapsulation overhead, allowing for highly performant, bare-metal-like networking.

Why this answer

Calico uses BGP (Border Gateway Protocol) to exchange routing information between nodes, enabling direct pod-to-pod communication without overlays. Each node runs a BGP client that advertises the pod CIDRs assigned to that node, allowing the underlying network infrastructure to route traffic at Layer 3.

Exam trap

The trap here is that candidates often associate BGP only with external routing or load balancers (like MetalLB), forgetting that Calico uses BGP internally for pod-to-pod routing across nodes.

How to eliminate wrong answers

Option B is wrong because Flannel typically uses a simple overlay network (e.g., VXLAN, host-gw) and does not implement BGP for route distribution; it relies on etcd for storing subnet allocations. Option C is wrong because Weave creates its own mesh overlay using UDP encapsulation and a custom control protocol, not BGP. Option D is wrong because Cilium primarily leverages eBPF for networking and security, and while it can integrate with BGP via external tools (e.g., MetalLB), its native routing does not depend on BGP for inter-node pod communication.

Full explanation →

613

MCQmedium

To check the expiration date of all certificates managed by kubeadm, which command should you run?

A.kubectl get certificates

B.kubeadm certs check-expiration

C.kubeadm certs renew

D.kubeadm alpha certs check-expiration

AnswerB

`kubeadm certs check-expiration` is the canonical command for inspecting the lifecycle of all certificates generated by kubeadm. It reads the PKI files under `/etc/kubernetes/pki` and the embedded etcd certificates, and outputs each certificate's name, remaining validity, and expiration date. This stable subcommand is the direct way to verify expiration before planning renewals.

Why this answer

`kubeadm certs check-expiration` is the dedicated kubeadm command to display expiration dates for all certificates managed by kubeadm in the cluster. This command reads the certificate files from the default kubeadm certificate directory (typically `/etc/kubernetes/pki`) and parses their `NotAfter` field to show remaining validity.

Exam trap

The trap here is that candidates confuse `kubeadm certs check-expiration` with `kubeadm alpha certs check-expiration` (option D) from older kubeadm versions, or mistakenly think `kubectl` can inspect filesystem certificates (option A), when in fact only the `kubeadm` CLI with the correct subcommand can perform this check.

How to eliminate wrong answers

Option A is wrong because `kubectl get certificates` does not exist; `kubectl` manages Kubernetes API resources, not filesystem certificates, and there is no built-in resource named 'certificates' for this purpose. Option C is wrong because `kubeadm certs renew` is used to renew certificates, not to check their expiration dates; it performs the renewal action but does not display current expiration information. Option D is wrong because `kubeadm alpha certs check-expiration` was a legacy command from older kubeadm versions (pre-1.15) that used the `alpha` subcommand, but the `alpha` prefix was removed in later releases; the correct command is `kubeadm certs check-expiration` without `alpha`.

Full explanation →

614

MCQeasy

Which command shows resource usage (CPU/memory) of all pods in the default namespace?

A.kubectl describe pods

B.kubectl logs pods

C.kubectl top pods

D.kubectl get pods -o wide

AnswerC

kubectl top pods is the direct client for the metrics.k8s.io API, which is normally served by metrics-server after it scrapes each node's Summary API from kubelet/cAdvisor. The command shows per-pod CPU usage in cores or millicores and memory usage in MiB, making it the standard way to view live resource consumption from the command line. This is precisely the resource-usage view the user is asking for.

Why this answer

kubectl top pod shows CPU and memory metrics for pods.

Full explanation →

615

MCQhard

A team is configuring etcd for a multi-node Kubernetes cluster. They want to ensure that etcd data is encrypted at rest. Which approach should they use?

A.Use LUKS to encrypt the disk partition where etcd data is stored.

B.Create an EncryptionConfiguration resource specifying a provider like 'aescbc' and configure the kube-apiserver with --encryption-provider-config.

C.Use TLS certificates to encrypt communication between etcd and the API server.

D.Configure etcd to use encryption at rest by setting --experimental-encryption-provider.

AnswerB

An EncryptionConfiguration resource defines the order and type of providers (such as aescbc, aesgcm, secretbox, or kms) for protecting specific API resource types. The kube-apiserver must be started with --encryption-provider-config=/path/to/encryption-config.yaml, and when it writes data like Secrets to etcd it encrypts that data using the chosen provider (aescbc uses AES-CBC with a randomly generated IV and a 32-byte key). This is the canonical, Kubernetes-native mechanism for encryption at rest and is exactly what the CKA objectives expect.

Why this answer

Kubernetes supports encrypting secrets and other resources at rest via an EncryptionConfiguration object, which is passed to the kube-apiserver using the --encryption-provider-config flag. This mechanism encrypts data before it is written to etcd, ensuring that even if the etcd storage is compromised, the data remains unreadable without the encryption key.

Exam trap

The trap here is confusing encryption at rest (data on disk) with encryption in transit (TLS), leading candidates to select TLS-based options, or assuming that etcd itself handles encryption at rest when it is actually the kube-apiserver that performs the encryption before writing to etcd.

How to eliminate wrong answers

Option A is wrong because LUKS encrypts the entire disk partition at the filesystem level, which is a valid approach for encrypting etcd data at rest, but the question asks which approach the team should use in the context of a Kubernetes cluster; the recommended and Kubernetes-native method is to use the EncryptionConfiguration resource, not an OS-level disk encryption tool. Option C is wrong because TLS certificates encrypt data in transit between etcd and the API server, not at rest; encryption at rest protects data when it is stored on disk, not during network communication. Option D is wrong because etcd does not have an --experimental-encryption-provider flag; encryption at rest is configured on the kube-apiserver side, not on etcd itself.

Full explanation →

616

MCQeasy

Which of the following is a valid use case for a Headless Service?

A.To provide a stable IP address for a deployment

B.To enable DNS-based service discovery for stateful applications like StatefulSets

C.To load balance traffic across pods using iptables

D.To allow external traffic to reach pods without a load balancer

AnswerB

By setting clusterIP to None, a headless service allows CoreDNS to generate direct A or AAAA records for each individual pod associated with a StatefulSet. This enables peer-to-peer discovery and direct communication between specific replicas, which is essential for clustering databases like PostgreSQL, Cassandra, or Kafka.

Why this answer

A Headless Service (with clusterIP: None) is used to enable DNS-based service discovery, returning the IP addresses of all backing pods rather than a single virtual IP. This is essential for stateful applications like StatefulSets, where each pod requires a stable network identity and direct pod-to-pod communication without load balancing.

Exam trap

The trap here is that candidates confuse the purpose of a Headless Service with a regular ClusterIP Service, assuming it still provides load balancing or a stable virtual IP, when in fact it is designed for direct pod DNS resolution without proxying.

How to eliminate wrong answers

Option A is wrong because a Headless Service does not provide a stable IP address; it returns pod IPs via DNS, and stable IPs are provided by a regular ClusterIP Service or a StatefulSet's pod identity. Option C is wrong because load balancing traffic across pods using iptables is the default behavior of a regular ClusterIP Service, not a Headless Service, which deliberately skips proxying and DNS round-robin. Option D is wrong because allowing external traffic to reach pods without a load balancer is the role of a NodePort or LoadBalancer Service, not a Headless Service, which is only for internal DNS-based pod discovery.

Full explanation →

617

MCQmedium

A node in your cluster is marked as NotReady. You SSH into the node and run 'systemctl status kubelet'. The output shows the kubelet is inactive (dead). What should you do FIRST to restore the node?

A.Reboot the node

B.Delete the node object from the cluster

C.Run 'systemctl start kubelet'

D.Reinstall the kubelet package

AnswerC

Running 'systemctl start kubelet' is the correct first recovery action because Node NotReady status almost universally means the kubelet is not actively running or has failed to report its status. Starting the kubelet makes it contact the API server, renew its heartbeat, and re-register the node with its capacity and conditions, which allows the control plane to mark it Ready again. Before starting, you should verify the service status and check logs with 'journalctl -u kubelet', but the start command is the minimal and precise fix for a stopped kubelet daemon.

Why this answer

The kubelet service is stopped. The first step is to start it with 'systemctl start kubelet'. If it fails to start, further investigation with journalctl is needed.

Full explanation →

618

MCQmedium

In a Kubernetes cluster using CoreDNS, what is the DNS name for a Service named 'api' in namespace 'backend'?

A.backend.api.svc.cluster.local

B.api.backend.svc.cluster.local

C.api.backend.cluster.local

D.api.svc.backend.cluster.local

AnswerB

This is the correct fully qualified domain name for a Service. CoreDNS serves the record in the format '<service>.<namespace>.svc.<cluster-domain>', so 'api' is the service, 'backend' is the namespace, and 'svc' marks this as a Service record. It resolves to the Service's ClusterIP, allowing pods to reach it with a stable DNS name.

Why this answer

In Kubernetes, CoreDNS resolves Service DNS names using the format `<service>.<namespace>.svc.cluster.local`. For a Service named 'api' in namespace 'backend', the fully qualified DNS name is `api.backend.svc.cluster.local`. This allows Pods to discover the Service via DNS, with CoreDNS serving as the cluster DNS provider.

Exam trap

The trap here is that candidates often confuse the order of service and namespace, or omit the `svc` subdomain, because they think the namespace alone is sufficient for DNS resolution.

How to eliminate wrong answers

Option A is wrong because it reverses the order of service and namespace (backend.api.svc.cluster.local), which does not match the Kubernetes DNS specification. Option C is wrong because it omits the mandatory `svc` subdomain, which is required for Service DNS resolution in the cluster domain. Option D is wrong because it places `svc` before `backend`, breaking the standard `<service>.<namespace>.svc.<cluster-domain>` hierarchy.

Full explanation →

619

MCQeasy

Which command lists all events in the cluster sorted by timestamp?

A.kubectl get events --watch

B.kubectl logs --events

C.kubectl describe events

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

AnswerD

This is the correct command because `kubectl get` supports the `--sort-by` flag, which takes a JSONPath expression evaluated against each returned object. Here `.metadata.creationTimestamp` is the standard field that records when each event object was created, and the client sorts all events by that timestamp before printing them, giving chronological order. Combining the `events` resource with this sort key is the direct, supported way to list all events sorted by time.

Why this answer

'kubectl get events --sort-by=.metadata.creationTimestamp' shows events sorted by creation time. Alternatively, 'kubectl get events -w' watches events but does not sort.

Full explanation →

620

Multi-Selectmedium

Which ONE of the following is a valid field in a PodSpec for defining init containers?

Select 1 answer

A.initContainers

B.volumes

C.imagePullSecrets

D.restartPolicy

E.containers

AnswersA

The initContainers field is a specialized array within the PodSpec used to define one or more initialization containers. These containers run to completion sequentially before any app containers start, making them ideal for running setup scripts, blocking until dependencies are ready, or prepopulating data.

Why this answer

The `initContainers` field in the PodSpec is used to define init containers. The other options are separate PodSpec fields with different purposes: `volumes` for storage, `imagePullSecrets` for pulling private images, `restartPolicy` is a PodSpec field for restart behavior (not for defining init containers), and `containers` is for main application containers, not init containers.

Exam trap

The CKA exam often tests the distinction between `initContainers` and `containers` in the PodSpec, and the trap here is that candidates may mistakenly think `containers` includes init containers or that `volumes` or `imagePullSecrets` are valid fields for defining init containers, when in fact they are separate PodSpec fields with different purposes.

Full explanation →

621

MCQeasy

Which of the following is NOT a control plane component?

A.kube-apiserver

B.kube-controller-manager

C.kube-scheduler

D.kubelet

AnswerD

The kubelet is the primary node agent that runs on every worker node in the cluster, rather than being a control plane component. It is responsible for registering the node with the apiserver and ensuring that the containers described in PodSpecs are running and healthy. It acts as the execution agent on individual nodes, bridging the gap between control plane instructions and container runtimes.

Why this answer

The kubelet is the primary node agent that runs on each worker node, not on the control plane. It is responsible for ensuring that containers are running in a Pod as expected by interacting with the container runtime (e.g., containerd or CRI-O). Control plane components are those that manage the cluster's state and scheduling decisions, which run on the control plane nodes.

Exam trap

The trap here is that candidates confuse the kubelet's presence on control plane nodes (since it runs there too) with being a control plane component, but the kubelet is a node agent, not a control plane service.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the front-end for the Kubernetes control plane, exposing the Kubernetes API and handling all RESTful requests to validate and configure cluster objects. Option B is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that regulate cluster state by watching the API server for changes. Option C is wrong because kube-scheduler is responsible for assigning newly created Pods to nodes based on resource availability, policies, and constraints, making it a core control plane component.

Full explanation →

622

MCQeasy

You want to temporarily access a pod's HTTP endpoint on port 8080 from your local machine on port 9090. Which command should you use?

A.kubectl exec -it my-pod -- /bin/bash

B.kubectl proxy --port=9090

C.kubectl expose pod my-pod --port=9090 --target-port=8080

D.kubectl port-forward pod/my-pod 9090:8080

AnswerD

This command establishes a secure, temporary tunnel that forwards traffic from port 9090 on your local machine directly to port 8080 of the specified pod. It is the ideal tool for debugging and temporarily accessing a pod's web endpoint without exposing it to the public internet or creating permanent cluster resources.

Why this answer

`kubectl port-forward` creates a direct tunnel from a local port (9090) to a pod's port (8080) over the Kubernetes API server, enabling temporary access to a pod's HTTP endpoint without exposing a service. This is the standard method for debugging or testing a pod's network endpoint from a local machine.

Exam trap

The trap here is that candidates often confuse `kubectl port-forward` with `kubectl expose` or `kubectl proxy`, mistakenly thinking those commands provide direct local access to a pod's port, when in fact `kubectl expose` creates a Service (requiring additional access methods) and `kubectl proxy` targets the API server, not the pod.

How to eliminate wrong answers

Option A is wrong because `kubectl exec -it my-pod -- /bin/bash` opens an interactive shell inside the pod, not a network tunnel; it does not forward ports or provide HTTP access from the local machine. Option B is wrong because `kubectl proxy --port=9090` starts a proxy to the Kubernetes API server on port 9090, not to a specific pod's HTTP endpoint on port 8080; it accesses the API server, not the pod's application. Option C is wrong because `kubectl expose pod my-pod --port=9090 --target-port=8080` creates a Kubernetes Service object that exposes the pod as a network service within the cluster, but it does not forward ports to the local machine; it requires additional steps (like `kubectl get svc` and accessing via NodePort or proxy) to reach from outside the cluster.

Full explanation →

623

Multi-Selectmedium

Which TWO of the following will cause a pod to be rescheduled to a different node? (Select TWO.)

Select 2 answers

A.Node has a taint with effect NoExecute

B.The pod's resource requests are increased

C.The pod's node affinity is updated

D.Node has a taint with effect NoSchedule

E.A higher-priority pod preempts the current pod

AnswersA, E

A node taint with effect NoExecute triggers immediate eviction of any pod that does not tolerate the taint. The kubelet acts on this taint by evicting the running pod, and since the pod is typically managed by a controller such as a Deployment, its controller recreates the pod on another schedulable node. This eviction and recreation is the mechanism that causes the pod to be rescheduled.

Why this answer

Option A is correct because a taint with effect NoExecute on a node causes the node controller to evict pods that do not tolerate that taint, and the evicted pods are then recreated by their controller (e.g., Deployment/ReplicaSet) and rescheduled onto a different node. Option E is correct because when a higher-priority pod is scheduled and the cluster needs to free resources, the scheduler can preempt (evict) lower-priority pods; those preempted pods are deleted and their controllers recreate them, causing rescheduling to another node. Option B is not correct: increasing a pod's resource requests does not by itself trigger rescheduling — the change is not applied to an existing running pod (pod specs are largely immutable), and even if it were, it would not automatically move the pod to another node.

Option C is not correct: updating node affinity on a running pod is not a supported in-place change and does not cause the kubelet/scheduler to relocate the pod; affinity is evaluated at scheduling time. Option D is not correct: a NoSchedule taint only prevents new pods from being scheduled onto the node; it does not evict or reschedule pods already running there.

Exam trap

The trap here is confusing NoExecute (which evicts existing pods) with NoSchedule (which only blocks new pods), leading candidates to incorrectly select NoSchedule as a cause for rescheduling.

Full explanation →

624

MCQhard

A Job named 'pi' runs a container that computes pi to 2000 digits. The Job's spec has completions=3 and parallelism=2. After some time, you observe that two pods completed successfully, and the third pod is still running. What is the expected behavior when the third pod completes?

A.The Job will be marked as Complete

B.The Job will restart the completed pods

C.The Job will continue to run new pods indefinitely

D.The Job will be marked as Failed because parallelism is not fully utilized

AnswerA

In Kubernetes, a Job tracks successful pod executions to determine its overall status. Once the number of successfully terminated pods reaches the configured completions value, the Job controller updates the Job's status to Complete. No further pods are scheduled, and the Job transitions to a terminal successful state.

Why this answer

A Job with `completions=3` and `parallelism=2` is considered complete when the required number of successful pod completions (3) is reached. Since two pods have already completed and the third is still running, once it finishes successfully, the total successful completions will equal the `completions` value, and the Job controller will mark the Job as Complete. The Job does not require all pods to run concurrently or finish simultaneously.

Exam trap

The trap here is that candidates often confuse `parallelism` with a requirement for all parallel pods to finish, or think that a Job must have all pods running concurrently to succeed, leading them to incorrectly select Option D.

How to eliminate wrong answers

Option B is wrong because completed pods in a Job are not restarted; the Job controller only creates new pods to meet the `completions` count, and once the count is met, no further pods are created or restarted. Option C is wrong because a Job does not run new pods indefinitely; it stops creating pods once the `completions` threshold is reached, unless the `backoffLimit` is exhausted or the Job is configured with `spec.ttlSecondsAfterFinished`. Option D is wrong because the Job is not marked as Failed due to partial parallelism utilization; parallelism only controls the maximum number of pods running concurrently, and the Job can succeed even if parallelism is not fully used at all times.

Full explanation →

625

MCQmedium

You run 'kubectl get nodes' and one node shows 'NotReady'. Which command should you run first to check the kubelet status on that node?

A.journalctl -u kubelet

B.kubectl describe node <node-name>

C.cat /var/log/syslog | grep kubelet

D.systemctl status kube-apiserver

AnswerA

journalctl -u kubelet reads the systemd journal for the kubelet service, the daemon that registers the node and reports its status to the control plane. When a node is NotReady, kubelet logs will contain the underlying error, such as a failed heartbeat to the API server, CNI interface issues, or a misconfigured kubeconfig. This is the authoritative source because kubelet runs as a systemd unit and its stderr/stdout are captured in the journal.

Why this answer

The kubelet is responsible for node status. On the node, you can check its logs with journalctl.

Full explanation →

626

MCQhard

A pod is not able to communicate with another pod in the same namespace. Both pods are running and have IP addresses. Which command can you use to test connectivity from the first pod to the second pod's IP?

A.kubectl exec first-pod -- ping <second-pod-ip>

B.kubectl logs first-pod

C.kubectl top pod first-pod

D.kubectl exec second-pod -- ping <first-pod-ip>

AnswerA

kubectl exec first-pod -- ping <second-pod-ip> is the correct diagnostic because it enters the network namespace of the first pod and sends ICMP echo requests directly to the second pod's IP address. This actively tests layer 3 connectivity along the exact path the failing application would use, rather than relying on any proxy, load balancer, or DNS resolution. A successful reply confirms the network route and firewall rules permit traffic, while a failure localizes the problem to the pod-to-pod networking layer.

Why this answer

`kubectl exec first-pod -- ping <second-pod-ip>` runs the `ping` command inside the first pod, which uses ICMP to test IP-level connectivity to the second pod's IP address. This directly verifies whether the network path between the two pods is functional, including any CNI plugin, overlay network, or network policy rules.

Exam trap

The trap here is that candidates might choose Option D, thinking any ping between pods is equivalent, but the question specifically asks to test connectivity from the first pod to the second pod's IP, not the reverse direction.

How to eliminate wrong answers

Option B is wrong because `kubectl logs first-pod` only retrieves the container logs from the first pod, which does not test network connectivity to another pod. Option C is wrong because `kubectl top pod first-pod` shows resource usage (CPU/memory) of the first pod, not network connectivity. Option D is wrong because it runs `ping` from the second pod to the first pod's IP, which tests the reverse direction and does not diagnose connectivity from the first pod to the second pod as the question requires.

Full explanation →

627

MCQhard

A user reports that they can't authenticate to the cluster using a kubeconfig file. Running 'kubectl config view' shows the current context points to a user with client certificate and key. Which command checks the expiration date of the client certificate?

A.kubeadm upgrade plan --certificate-expiration

B.kubectl config view --raw | grep client-certificate

C.openssl x509 -in /etc/kubernetes/admin.conf -text -noout

D.kubeadm certs check-expiration

AnswerD

This subcommand is the authoritative way to inspect the lifetimes of all certificates managed by kubeadm, including the CA, apiserver, controller-manager, scheduler, kubelet, and the client certificate embedded in admin.conf. It prints a table showing the expiration date and remaining days for each component, giving immediate insight into whether certificate expiry is causing authentication problems. For kubeadm-based clusters, this is the correct first tool for diagnosing certificate-related authentication issues.

Why this answer

`kubeadm certs check-expiration` is the dedicated kubeadm command to display expiration dates for all PKI certificates in the cluster, including the client certificate used by the user's kubeconfig. This command parses the certificates directly from the `/etc/kubernetes/pki` directory and shows remaining validity, making it the precise tool for this scenario.

Exam trap

The trap here is that candidates confuse the kubeconfig file (a YAML configuration) with a certificate file, leading them to incorrectly use `openssl` directly on the kubeconfig or grep for the certificate data without parsing its expiration.

How to eliminate wrong answers

Option A is wrong because `kubeadm upgrade plan --certificate-expiration` is not a valid flag; `kubeadm upgrade plan` shows upgrade options, not certificate expiration. Option B is wrong because `kubectl config view --raw | grep client-certificate` only outputs the path or base64-encoded certificate data, not the expiration date; it does not decode or parse the certificate. Option C is wrong because `openssl x509 -in /etc/kubernetes/admin.conf -text -noout` attempts to read a kubeconfig file as a certificate, but `admin.conf` is a YAML file, not a PEM-encoded certificate; the command would fail or produce garbage.

Full explanation →

628

Multi-Selectmedium

Your cluster has three control plane nodes. You suspect the etcd cluster has a leader election issue. Which TWO commands can help diagnose the etcd cluster health and membership? (Choose TWO.)

Select 2 answers

A.etcdctl cluster-status

B.etcdctl version

C.etcdctl endpoint health --cluster

D.etcdctl snapshot save snapshot.db

E.etcdctl member list

AnswersC, E

`etcdctl endpoint health --cluster` queries every endpoint listed in the cluster's member information and reports each endpoint's health and latency. The `--cluster` flag tells the client to read the member list from an existing endpoint and check all members, not just a single address. A healthy response from all endpoints indicates the cluster is operational and has quorum, making this an effective first diagnostic.

Why this answer

`etcdctl endpoint health --cluster` queries the health status of all etcd endpoints in the cluster, which directly reveals if any node is unreachable or unhealthy—a common symptom of leader election issues. Option E is correct because `etcdctl member list` displays the current cluster membership, including each member's ID, name, peer URLs, and client URLs, allowing you to verify that all expected control plane nodes are properly joined and that no split-brain or quorum loss has occurred.

Exam trap

The trap here is that candidates may confuse `etcdctl cluster-status` (which does not exist) with the valid `etcdctl endpoint status` command, or they may think snapshot commands are diagnostic tools rather than backup utilities.

Full explanation →

629

MCQmedium

Which kubectl command correctly retrieves the list of EndpointSlices for a Service named 'my-svc' in the 'default' namespace?

A.kubectl get endpoints my-svc -n default

B.kubectl describe svc my-svc -n default

C.kubectl get endpointslice -n default --selector=kubernetes.io/service-name=my-svc

D.kubectl get endpointslices my-svc -n default

AnswerC

The label selector kubernetes.io/service-name=my-svc is the standard label automatically applied by the EndpointSlice controller to each slice that belongs to the Service. Since a Service can have multiple EndpointSlices (sharded by address type, subsets, or topology), this selector collects all of them, which is exactly what the task requires. The kubectl get endpointslice command then lists every matching EndpointSlice object in the default namespace.

Why this answer

EndpointSlices are the modern, scalable replacement for Endpoints, and they use a specific label `kubernetes.io/service-name` to associate them with a Service. The command `kubectl get endpointslice -n default --selector=kubernetes.io/service-name=my-svc` correctly filters EndpointSlices by that label, retrieving all slices belonging to 'my-svc'.

Exam trap

The trap here is that candidates often confuse the legacy `endpoints` resource with `endpointslice`, or assume that `kubectl get endpointslice my-svc` works like `kubectl get pods my-pod`, not realizing that EndpointSlices are not named after the Service and require a label selector to filter.

How to eliminate wrong answers

Option A is wrong because `kubectl get endpoints` retrieves the legacy Endpoints object, not EndpointSlices, and does not use the `--selector` flag to filter by service name. Option B is wrong because `kubectl describe svc` shows the Service's details, including its selector and endpoints, but does not list the individual EndpointSlice objects. Option D is wrong because `kubectl get endpointslices` is not a valid kubectl command (the correct resource name is `endpointslice`, not `endpointslices`), and even if corrected, it would not filter by service name without the `--selector` flag.

Full explanation →

630

MCQmedium

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

A.kubectl logs pod-name --previous

B.kubectl logs pod-name --all-containers

C.kubectl logs pod-name --last

D.kubectl logs pod-name

AnswerA

The --previous flag instructs kubectl to fetch logs from the container's prior terminated instance rather than the current one. In CrashLoopBackOff the running container has just restarted, so only the previous instance holds the crash output needed for diagnosis.

Why this answer

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

Exam trap

The trap here is that candidates often think `kubectl logs pod-name` alone will show crash logs, but it only shows logs from the currently running container (which may be empty or not yet started), and they overlook the `--previous` flag that is specifically designed for accessing logs of a terminated container.

How to eliminate wrong answers

Option B is wrong because `--all-containers` streams logs from all containers in the pod simultaneously, but it does not retrieve logs from a previous (crashed) instance; it only shows current container logs. Option C is wrong because `-p` is the shorthand for `--previous`, so this option is actually correct and identical to A; however, the question expects the explicit `--previous` flag as the answer, and `-p` is not listed as a separate correct choice. Option D is wrong because `kubectl logs pod-name` without any flag only shows logs from the currently running container; in a `CrashLoopBackOff` state, the current container may have just started and has no useful logs, or the command may fail if no container is currently running.

Full explanation →

631

MCQeasy

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

A.my-svc.my-ns.svc.cluster.local

B.my-svc.svc.cluster.local

C.my-svc.my-ns.cluster.local

D.my-svc.cluster.local

AnswerA

This is the canonical Kubernetes Service Fully Qualified Domain Name (FQDN). The layout is <service-name>.<namespace>.svc.<cluster-domain>, and for a service named my-svc in namespace my-ns, the default cluster domain cluster.local yields my-svc.my-ns.svc.cluster.local. This record is dynamically maintained by CoreDNS and resolves to the service's ClusterIP, allowing deterministic internal access for workloads in any namespace.

Why this answer

Kubernetes constructs the default DNS name for a Service using the format `<service-name>.<namespace>.svc.cluster.local`. This is defined by the cluster DNS specification (CoreDNS or kube-dns) and allows Pods to resolve the Service by its fully qualified domain name (FQDN) within the cluster. For 'my-svc' in namespace 'my-ns', the FQDN is 'my-svc.my-ns.svc.cluster.local'.

Exam trap

The trap here is that candidates often forget the 'svc' subdomain or the namespace component, mistakenly thinking the Service name alone (e.g., 'my-svc.cluster.local') or just the namespace (e.g., 'my-svc.my-ns.cluster.local') is sufficient, while Kubernetes strictly requires the full `<service>.<namespace>.svc.cluster.local` format for cross-namespace DNS resolution.

How to eliminate wrong answers

Option B is wrong because it omits the namespace component, which is required in the FQDN format `<service>.<namespace>.svc.cluster.local`; without the namespace, the DNS name is incomplete and would not resolve correctly. Option C is wrong because it uses 'cluster.local' directly after the namespace, missing the mandatory 'svc' subdomain that distinguishes Service DNS records from other object types (e.g., Pods use `<pod-ip>.<namespace>.pod.cluster.local`). Option D is wrong because it omits both the namespace and the 'svc' subdomain, representing a common misconception that the Service name alone suffices for cluster-wide DNS resolution.

Full explanation →

632

MCQhard

You are asked to backup the etcd database on a control plane node. The etcd is running as a static pod. Which command sequence will create a consistent snapshot?

A.kubectl exec -n kube-system etcd-controlplane -- etcdctl snapshot save /backup/etcd-snapshot.db

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

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

D.etcdctl --endpoints=http://localhost:2379 snapshot save /backup/etcd-snapshot.db

AnswerC

This command is the correct approach for backing up an etcd database on a Kubernetes control plane. It explicitly sets `ETCDCTL_API=3` for compatibility with modern etcd versions, specifies the secure HTTPS endpoint `https://127.0.0.1:2379`, and provides all required TLS certificates (`--cacert`, `--cert`, `--key`) for mutual authentication with the etcd server. This ensures a secure and successful connection, allowing `etcdctl` to perform the snapshot operation reliably.

Why this answer

It uses the etcdctl v3 API with the required authentication flags (--cacert, --cert, --key) and the correct endpoint (https://127.0.0.1:2379) to connect to the etcd server running as a static pod. This ensures a consistent snapshot is taken over the secure gRPC connection, which is mandatory when etcd is configured with TLS.

Exam trap

The trap here is that candidates assume 'kubectl exec' into the etcd pod (Option A) is sufficient, but they forget that etcdctl inside the pod still needs explicit TLS flags and endpoint specification, or they mistakenly use an insecure HTTP endpoint (Option D) without realizing that production etcd requires HTTPS.

How to eliminate wrong answers

Option A is wrong because 'kubectl exec' into the etcd container runs etcdctl inside the pod, but it does not automatically provide the necessary TLS certificates or endpoint, and the command lacks the required --cacert, --cert, --key flags, so it will fail to authenticate. Option B is wrong because it runs etcdctl on the host without specifying an endpoint or TLS credentials, so it defaults to the local unix socket or insecure connection, which will not reach the etcd server running as a static pod with TLS enabled. Option D is wrong because it uses an HTTP endpoint (http://localhost:2379) instead of HTTPS, and etcd in a production cluster (including static pods) requires TLS encryption; the connection will be refused or fail authentication.

Full explanation →

633

MCQmedium

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. Which of the following is NOT a common cause?

A.The image tag does not exist

B.The image registry requires authentication

C.The image name is misspelled

D.The node has a taint that tolerates the pod

AnswerD

If a node has a taint and the pod has a matching toleration, the Kubernetes scheduler can successfully assign the pod to that node. This scheduling mechanism has no bearing on the container runtime's ability to pull images. If scheduling succeeds, the pod will not enter ImagePullBackOff unless there is an unrelated image retrieval issue.

Why this answer

NOT a common cause of ImagePullBackOff because taints and tolerations affect pod scheduling, not image pulling. ImagePullBackOff occurs when the kubelet fails to pull the container image from the registry, which is a runtime issue unrelated to node scheduling constraints.

Exam trap

The CKA exam often tests the distinction between scheduling issues (taints/tolerations) and runtime issues (image pulling), so candidates mistakenly associate any pod failure with taints when the pod is actually running but failing to pull its image.

How to eliminate wrong answers

Option A is wrong because a non-existent image tag (e.g., 'myapp:latest' when only 'myapp:v1' exists) causes the registry to return a manifest not found error, triggering ImagePullBackOff. Option B is wrong because missing or invalid registry credentials (e.g., for a private registry like Docker Hub or ECR) result in authentication failures, leading to ImagePullBackOff. Option C is wrong because a misspelled image name (e.g., 'ngnix' instead of 'nginx') causes the registry to return a 404 or name unknown error, which is a common cause of ImagePullBackOff.

Full explanation →

634

MCQmedium

You have a kubeconfig file with multiple contexts. How do you switch to the context named 'prod-cluster'?

A.kubectl config set-cluster prod-cluster

B.kubectl config set-context prod-cluster

C.kubectl config view prod-cluster

D.kubectl config use-context prod-cluster

AnswerD

kubectl config use-context prod-cluster is the correct command because it explicitly writes the name prod-cluster to the current-context field in the kubeconfig file. After this runs, kubectl commands resolve the current context to prod-cluster and load its associated cluster and user credentials. It is the direct counterpart to the question's intent of switching the active context.

Why this answer

`kubectl config use-context` is the command specifically designed to switch the current context in a kubeconfig file. It updates the `current-context` field in the kubeconfig to point to the specified context, which then determines which cluster, user, and namespace are used by default for subsequent `kubectl` commands.

Exam trap

The trap here is that candidates confuse `set-context` (which defines a context) with `use-context` (which activates it), leading them to pick option B instead of D.

How to eliminate wrong answers

Option A is wrong because `kubectl config set-cluster` only modifies or adds a cluster definition (e.g., server URL, certificate authority) in the kubeconfig, it does not change the active context. Option B is wrong because `kubectl config set-context` creates or modifies a context entry (associating a cluster, user, and namespace) but does not switch to it; it only defines the context. Option C is wrong because `kubectl config view` displays the contents of the kubeconfig file (or a merged view) and does not alter the current context.

Full explanation →

635

MCQhard

You are troubleshooting a pod that is in 'CrashLoopBackOff' state. You run 'kubectl logs mypod' and get no output. You then run 'kubectl logs mypod --previous' and see an error: 'Error: failed to start container: context deadline exceeded'. What is the MOST likely cause?

A.The container image is missing the entrypoint

B.The application inside the container is crashing immediately

C.The container command is incorrectly specified

D.The container runtime is unable to start the container due to a timeout

AnswerD

The 'context deadline exceeded' error indicates that the kubelet's or CRI runtime's operation to create or start the container exceeded its deadline before completing successfully. This is typical when the container runtime hangs during image pull, storage setup, runc init, or other pre-start steps, and after repeated failures the kubelet marks the pod as CrashLoopBackOff. It is a runtime-level timeout rather than an application or command issue, so inspecting the container runtime service and underlying node resources is the appropriate debugging path.

Why this answer

The error 'failed to start container: context deadline exceeded' indicates the container runtime (containerd/CRI-O) could not start the container within the allotted timeout, typically due to image pull slowness, runtime hang, or resource pressure. Because kubectl logs with --previous shows this runtime-level error rather than an application stack trace, the root cause is the runtime failing to launch the container, not the app crashing.

Exam trap

CKA often tests the confusion between application-level crashes (which show app logs) and runtime-level start failures (which show CRI errors), leading candidates to blame the app when the container never actually started.

How to eliminate wrong answers

Option A is wrong because a missing entrypoint would produce an 'executable file not found' or 'no such file or directory' error, not a context deadline exceeded. Option B is wrong because an immediately crashing application would produce application logs (stack traces, exit codes) in --previous output, not a runtime start timeout. Option C is wrong because an incorrectly specified command would yield a command-not-found or exec format error, again not a deadline exceeded message.

Full explanation →

636

MCQmedium

A pod is unable to resolve DNS names. You exec into the pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command hangs. What is the MOST likely cause?

A.The CoreDNS service is not running or is misconfigured

B.The pod's /etc/resolv.conf is missing

C.The kubelet is not running on the node

D.The pod's network policy blocks DNS traffic

AnswerA

CoreDNS is the cluster's authoritative DNS service, and its Service IP is what kubelet writes into every pod's /etc/resolv.conf as the nameserver. If the CoreDNS Deployment has no available replicas, the Service has no endpoints, or the Corefile is misconfigured (e.g., invalid forward upstreams), queries will time out or return SERVFAIL. This directly explains why a running pod with a valid resolv.conf still cannot resolve any DNS names.

Why this answer

The CoreDNS service is responsible for DNS resolution within the cluster. If it is not running or misconfigured, DNS queries from pods will hang or fail. The `nslookup` command hanging indicates that the DNS request is not being answered, which is a classic symptom of a non-functional or unreachable DNS service.

Exam trap

The trap here is that candidates may assume a network policy is blocking traffic (option D) because it sounds plausible, but the most common and direct cause of a hanging DNS query in a Kubernetes cluster is a non-functional CoreDNS service, not a network policy.

How to eliminate wrong answers

Option B is wrong because a missing /etc/resolv.conf would cause an immediate 'no such file or directory' error, not a hang. Option C is wrong because if the kubelet were not running, the pod itself would not be running or accessible via exec. Option D is wrong because a network policy blocking DNS traffic would typically result in a timeout or connection refused, but the most common and direct cause of a hang in `nslookup` is the DNS service itself being down or misconfigured.

Full explanation →

637

MCQmedium

You have a Deployment with spec.replicas=3. You update the container image. The rollout gets stuck because the new ReplicaSet cannot create pods due to an image pull error. Which command would you use to roll back to the previous revision?

A.kubectl rollout undo deployment/<name>

B.kubectl rollout undo deployment/<name> --to-revision=1

C.kubectl rollout revert deployment/<name>

D.kubectl rollout rollback deployment/<name>

AnswerA

This is the standard mechanism for reverting a Deployment to the last successful revision. The undo command instructs the Deployment controller to scale the previous ReplicaSet back up and the current one down, effectively applying the prior pod template. It's the safest, most direct way to reverse an unintentional change when you've verified the previous revision is healthy.

Why this answer

`kubectl rollout undo deployment/<name>` reverts the Deployment to the previous revision by default. This command uses the rollout history stored in the Deployment's annotations (specifically `deployment.kubernetes.io/revision`) to restore the prior ReplicaSet's pod template, effectively undoing the failed image update.

Exam trap

The trap here is that candidates confuse the `undo` command with non-existent verbs like `revert` or `rollback`, or incorrectly assume `--to-revision=1` is required to go back one step, when the default behavior already targets the previous revision.

How to eliminate wrong answers

Option B is wrong because `--to-revision=1` would roll back to revision 1, not the immediately previous revision; the question asks to roll back to the previous revision, which is the default behavior of `undo` without `--to-revision`. Option C is wrong because `kubectl rollout revert` is not a valid kubectl command; the correct verb is `undo`. Option D is wrong because `kubectl rollout rollback` is not a valid kubectl command; the correct verb is `undo`.

Full explanation →

638

MCQmedium

An administrator is preparing a StorageClass for a stateful application. The cluster's default StorageClass uses immediate binding, which causes PersistentVolumes to be provisioned before the consuming Pod is scheduled. The administrator wants volumes to be provisioned only after the scheduler has selected a node, so that topology-aware constraints (such as zone-local disks) can be honored. Which change to the StorageClass should the administrator make?

A.Set volumeBindingMode to Immediate and add a nodeSelector to the StorageClass.

B.Add a topologyKey field to the StorageClass and set it to kubernetes.io/hostname.

C.Set volumeBindingMode to WaitForFirstConsumer in the StorageClass specification.

D.Set reclaimPolicy to Retain and set allowVolumeExpansion to true.

AnswerC

WaitForFirstConsumer delays binding and provisioning until a Pod using the PVC is scheduled, allowing the scheduler to consider the Pod's node affinity and topology constraints. This prevents provisioning a volume in the wrong zone. It is the correct field for topology-aware dynamic provisioning and directly addresses the scenario's requirement.

Why this answer

WaitForFirstConsumer is the volumeBindingMode value that defers both binding and dynamic provisioning until a Pod using the PVC is scheduled, letting the scheduler choose a node that satisfies the Pod's topology constraints. Immediate binding provisions too early for zone-local storage. The other options either use unrelated StorageClass fields or fields that do not exist.

Exam trap

The trap here is assuming that adding a topology key directly to the StorageClass controls provisioning location, when topology awareness is actually driven by volumeBindingMode and the CSI driver's topology support.

Full explanation →

639

MCQmedium

A pod is in Pending state. You run 'kubectl describe pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 3 node(s) had taint {node.kubernetes.io/not-ready: }.'. What is the most likely reason?

A.The pod's container image pull failed

B.The cluster is out of CPU capacity

C.The pod's resource requests are too high for any node

D.The pod does not have tolerations for the taints on the available nodes

AnswerD

The scheduler reports that available nodes are tainted and the pod has no matching tolerations, often as '0/3 nodes available: 3 node(s) had taint {key=value:effect}, that the pod didn't tolerate.' Taints are applied to nodes with `kubectl taint nodes ...`, and only pods whose spec contains a toleration matching the taint's key, value, and effect can be scheduled there. Adding an appropriate toleration will let the scheduler place the pod, so this is the correct diagnosis.

Why this answer

The pod is in Pending state because the scheduler cannot find a node that meets all scheduling constraints. The event explicitly states that 1 node has a taint `node-role.kubernetes.io/master` and 3 nodes have a taint `node.kubernetes.io/not-ready`, and the pod does not have corresponding tolerations. Without tolerations, the pod is not allowed to schedule on any of these nodes, leaving no available node.

Exam trap

The trap here is that candidates may confuse taint/toleration issues with resource insufficiency, but the event message explicitly names taints, not resource shortages, making D the only correct answer based on the provided event details.

How to eliminate wrong answers

Option A is wrong because a container image pull failure would result in an ImagePullBackOff or ErrImagePull event, not a Pending state with taint-related scheduling events. Option B is wrong because the cluster being out of CPU capacity would manifest as a different event, such as 'Insufficient cpu' or 'Insufficient memory', not taint-based messages. Option C is wrong because if resource requests were too high, the event would indicate 'Insufficient cpu' or 'Insufficient memory' per node, not a taint-related message.

Full explanation →

640

MCQmedium

An Ingress resource uses 'networking.k8s.io/v1' API. Which field specifies the hostname and path rules for routing traffic?

A.spec.ingress

B.spec.tls

C.spec.rules

D.spec.backend

AnswerC

The spec.rules field is the heart of ingress routing, containing an ordered list of HTTP rules. Each rule can specify an optional host and a set of HTTP paths, each with a pathType (Prefix or Exact) and a backend that points to a Service and port. When incoming traffic matches the host and path criteria, it is forwarded to the specified backend. This is exactly what defines routing rules in an Ingress.

Why this answer

In the 'networking.k8s.io/v1' Ingress API, the 'spec.rules' field is where you define an array of routing rules, each containing a 'host' field for the hostname and an 'http' subfield with 'paths' that specify path-based routing to backend services. This is the primary mechanism for directing traffic based on hostname and path.

Exam trap

A common trap in the CKA exam is confusing 'spec.rules' with 'spec.backend'. While 'spec.backend' defines a default backend, 'spec.rules' is the correct field for hostname and path-based routing rules.

How to eliminate wrong answers

Option A is wrong because 'spec.ingress' is not a valid field in the Ingress spec; the correct top-level field is 'spec.rules'. Option B is wrong because 'spec.tls' is used to configure TLS termination (certificates and hosts) but does not define hostname and path routing rules. Option D is wrong because 'spec.backend' defines a default backend that receives traffic when no rules match, not the hostname and path rules themselves.

Full explanation →

641

Multi-Selectmedium

Which TWO network plugins (CNI) are commonly used in Kubernetes clusters? (Select TWO)

Select 2 answers

A.Calico

B.Flannel

C.CoreDNS

D.kube-proxy

E.Docker

AnswersA, B

Calico is a widely deployed CNI plugin providing pod networking and NetworkPolicy enforcement in Kubernetes clusters. It operates as a CNI implementation, unlike service meshes or ingress controllers, which sit above the CNI layer rather than supplying pod IP address management and connectivity.

Why this answer

Calico (A) is correct because it is a widely deployed CNI plugin that provides pod networking and network policy enforcement using BGP or VXLAN for routing. Flannel (B) is also correct as a common, lightweight CNI plugin that creates an overlay network (typically VXLAN) to give each pod a cluster-wide unique IP. CoreDNS (C) is not a CNI plugin; it is the cluster DNS server that resolves service and pod names. kube-proxy (D) is not a CNI plugin; it implements Service load balancing via iptables/IPVS rules on each node.

Docker (E) is a container runtime, not a Kubernetes CNI plugin.

Exam trap

The trap here is confusing Kubernetes networking components (CoreDNS, kube-proxy) with actual CNI plugins, or mistaking Docker's deprecated networking model for a valid CNI plugin.

Full explanation →

642

MCQhard

A NetworkPolicy allows ingress traffic from pods with label 'app: frontend' in any namespace. Which selector is used?

A.spec.ingress[0].from[0].podSelector: { matchLabels: { app: frontend } }

B.spec.ingress[0].from[0].namespaceSelector: {} and spec.ingress[0].from[0].podSelector: { matchLabels: { app: frontend } }

C.spec.ingress[0].from[0].ipBlock: { cidr: 0.0.0.0/0 }

D.spec.ingress[0].from[0].namespaceSelector: { matchLabels: { app: frontend } }

AnswerB

This is the correct rule because an empty namespaceSelector ({}) explicitly matches all namespaces, and the combined podSelector then narrows those namespaces to only the pods carrying the label app=frontend. In a NetworkPolicyPeer, when both namespaceSelector and podSelector are present, they are ANDed: the source pod must exist in a selected namespace AND carry the matching pod label. This gives cross-namespace, label-based ingress control, which is exactly what the question requires.

Why this answer

To allow ingress traffic from pods with label 'app: frontend' in any namespace, you must combine an empty namespaceSelector (which selects all namespaces) with a podSelector that matches the pod label. This combination tells Kubernetes to allow traffic from any pod matching the label, regardless of which namespace it resides in. Without the namespaceSelector, the podSelector would only apply to pods in the same namespace as the NetworkPolicy.

Exam trap

A common trap is that candidates think a podSelector alone can select pods across namespaces, but without an empty namespaceSelector, the podSelector is scoped to the NetworkPolicy's own namespace.

How to eliminate wrong answers

Option A is wrong because a podSelector alone restricts the rule to pods in the same namespace as the NetworkPolicy, not across all namespaces. Option C is wrong because ipBlock selects traffic based on source IP ranges, not pod labels, and does not consider namespace or pod selectors. Option D is wrong because a namespaceSelector with matchLabels would only select namespaces that have the label 'app: frontend', not pods with that label, and it would not select pods in any namespace unless the namespace itself has that label.

Full explanation →

643

MCQmedium

A company wants to expose a web application running as a Deployment with 3 replicas to external users. They need a stable IP address that does not change and the ability to terminate TLS. Which resource should they use?

A.LoadBalancer Service

B.ClusterIP Service

C.Ingress resource with a TLS certificate

D.NodePort Service

AnswerC

An Ingress resource, coupled with an Ingress controller, provides a robust solution for exposing web applications externally by offering HTTP/S routing, virtual hosting, and crucially, built-in TLS termination. It allows defining rules to route external traffic to specific services based on hostnames or URL paths, and can manage TLS certificates (stored as Kubernetes Secrets) to encrypt traffic from the client to the Ingress controller, ensuring secure communication.

Why this answer

An Ingress resource with a TLS certificate is the correct choice because it provides a stable IP address (via the underlying LoadBalancer or NodePort Service) and terminates TLS at the ingress controller, allowing the web application to serve HTTPS traffic without modifying the Deployment. This meets the requirements of exposing the application externally with a fixed IP and TLS termination.

Exam trap

CNCF often tests the misconception that a LoadBalancer Service alone can terminate TLS, but in Kubernetes, TLS termination is not a built-in feature of Services; it requires an Ingress or a custom proxy, making the Ingress resource the correct choice for this requirement.

How to eliminate wrong answers

Option A is wrong because a LoadBalancer Service exposes the application directly via a cloud load balancer, but it does not terminate TLS natively; TLS termination would require additional configuration (e.g., an external load balancer with TLS support) and the IP may change if the Service is recreated. Option B is wrong because a ClusterIP Service is only accessible within the cluster and cannot expose the application to external users. Option D is wrong because a NodePort Service exposes the application on a static port on each node's IP, but it does not provide a stable IP address (node IPs can change) and does not terminate TLS; TLS termination would require additional components like an Ingress or a reverse proxy.

Full explanation →

644

Multi-Selecthard

Which THREE of the following are valid considerations when using resource requests and limits? (Select 3)

Select 3 answers

A.Limits must be equal to requests for a Pod to be scheduled.

B.Requests are used by the scheduler to decide which node can accommodate the Pod.

C.CPU limits guarantee the Pod will get that amount of CPU.

D.The QoS class is determined based on requests and limits.

E.Memory limits can cause the Pod to be OOMKilled if exceeded.

AnswersB, D, E

During scheduling, kube-scheduler evaluates each candidate node by subtracting the sum of container requests for CPU and memory from the node's allocatable capacity. A node is deemed feasible only if it can satisfy all requested quantities, because requests represent the minimum resource reservation needed to run the Pod. Limits are deliberately ignored in this admission calculation, making requests the primary input for node fit decisions.

Why this answer

The Kubernetes scheduler uses resource requests (CPU and memory) to determine node suitability for a Pod. The scheduler checks if the sum of requests for all Pods on a node, plus the new Pod's requests, is less than or equal to the node's allocatable capacity. Limits are not used for scheduling decisions.

Exam trap

The trap here is that candidates often confuse CPU limits as a guarantee of CPU allocation, when in fact CPU is compressible and limits only throttle usage, while memory limits are hard and can cause OOM kills.

Full explanation →

645

MCQmedium

You run 'kubectl get nodes' and see that a node is 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. The output shows 'Active: inactive (dead)'. What is the most likely cause?

A.The network plugin is misconfigured

B.The node has been cordoned

C.The kubelet service is stopped

D.The container runtime is not installed

AnswerC

The kubelet is the primary agent responsible for registering the node with the Kubernetes API server and continuously reporting its health, resource utilization, and the status of pods running on it. If the kubelet service is stopped or inactive, it ceases to send heartbeats and status updates to the control plane. This complete lack of communication directly causes the API server to mark the node as `NotReady`, as it can no longer ascertain the node's operational state or manage its workloads.

Why this answer

The kubelet is the primary node agent that runs on every node and is responsible for maintaining pod lifecycles. When 'systemctl status kubelet' shows 'Active: inactive (dead)', it means the kubelet systemd service is not running. Since the kubelet must be active for the node to report its status to the control plane, a stopped kubelet directly causes the node to be 'NotReady'.

Exam trap

The trap here is that candidates often confuse a stopped kubelet with a kubelet that is running but unhealthy (e.g., due to container runtime issues), leading them to select option D, but the 'inactive (dead)' status specifically indicates the service is not running at all, not that it is failing to start.

How to eliminate wrong answers

Option A is wrong because a misconfigured network plugin (e.g., CNI) would cause pods to fail networking but the kubelet would still be running and the node would typically show 'Ready' with pod issues, not 'NotReady' due to a dead kubelet. Option B is wrong because cordoning a node (via 'kubectl cordon') marks it as 'SchedulingDisabled' but does not stop the kubelet; the node remains 'Ready' and the kubelet service stays active. Option D is wrong because if the container runtime (e.g., containerd or CRI-O) were not installed, the kubelet would fail to start or would crash-loop, but the service would show 'active (running)' or 'failed', not 'inactive (dead)'.

Full explanation →

646

MCQhard

A ServiceAccount 'monitor-sa' needs to be able to list Pods in namespace 'monitoring'. Which RBAC configuration is appropriate?

A.Create a ClusterRole with 'get' and 'list' verbs on pods, then a ClusterRoleBinding to monitor-sa

B.Add the ServiceAccount to the cluster-admin group

C.Create a Role in default namespace with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa

D.Create a Role in namespace 'monitoring' with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa

AnswerD

A namespaced Role scoped to 'monitoring' grants only the 'get' and 'list' verbs on pods, satisfying least privilege. Binding it with a RoleBinding in the same namespace restricts monitor-sa's permissions to that namespace, which is exactly the constraint the stem requires.

Why this answer

A Role in the 'monitoring' namespace with 'get' and 'list' verbs on pods, combined with a RoleBinding in the same namespace to the 'monitor-sa' ServiceAccount, grants the exact permissions required within the scope of that namespace. This follows the principle of least privilege by scoping permissions to the specific namespace where the pods reside.

Exam trap

The trap here is that candidates often confuse the scope of Roles versus ClusterRoles, mistakenly using a ClusterRole when a namespace-scoped Role is sufficient, or creating a Role in the wrong namespace and assuming a RoleBinding can bridge namespaces.

How to eliminate wrong answers

Option A is wrong because a ClusterRole with 'get' and 'list' verbs on pods, bound via a ClusterRoleBinding, would grant these permissions cluster-wide (across all namespaces), which is excessive for a requirement limited to the 'monitoring' namespace. Option B is wrong because adding the ServiceAccount to the 'cluster-admin' group grants full cluster-wide administrative privileges, violating the principle of least privilege and far exceeding the need to only list pods. Option C is wrong because a Role created in the 'default' namespace cannot grant permissions in the 'monitoring' namespace; RoleBindings only apply within the namespace of the Role, so the binding in 'monitoring' would have no effect.

Full explanation →

647

MCQeasy

Which command would you use to check the status of the kube-apiserver on a control plane node managed by systemd?

A.kubectl get apiservice

B.service kube-apiserver status

C.journalctl -u kubelet

D.systemctl status kube-apiserver

AnswerD

This is the standard systemd command used to query the active state, process ID, and recent log outputs of the kube-apiserver service when it is run as a system daemon. It directly queries the systemd init manager to verify if the process is running, active, or failing. This is crucial for troubleshooting control plane bootstrap issues on master nodes where components are managed as systemd services.

Why this answer

The kube-apiserver is a systemd service on control plane nodes managed by systemd. The `systemctl status kube-apiserver` command queries systemd for the current state, including active status, PID, memory usage, and recent log entries, which is the standard method for checking a systemd-managed service.

Exam trap

The trap here is that candidates confuse Kubernetes API resources (like `apiservice`) with the actual system process, or mistakenly use `kubectl` commands when the API server itself is unresponsive, making node-level systemd commands the only viable option.

How to eliminate wrong answers

Option A is wrong because `kubectl get apiservice` lists API service objects (like metrics-server) registered in the cluster, not the status of the kube-apiserver process itself. Option B is wrong because `service kube-apiserver status` uses the SysV init script interface, which may not be available or accurate on modern systemd-based distributions; systemd does not automatically create SysV compatibility for all services. Option C is wrong because `journalctl -u kubelet` shows logs for the kubelet service, not the kube-apiserver; the correct unit name for the API server is `kube-apiserver`.

Full explanation →

648

MCQmedium

You have a Deployment that should have a rolling update with no downtime. You set maxSurge to 25% and maxUnavailable to 0%. With 4 replicas, how many pods will be created above the desired count during the update?

A.2

B.1

C.4

D.0

AnswerB

With a desired replica count of 4 and a maxSurge set to 25%, Kubernetes calculates the maximum number of extra pods allowed during an update as 25% of 4, which equals exactly 1. Even if the percentage calculation yielded a fractional value, Kubernetes always rounds up to the nearest integer to ensure at least one extra pod can be created. Thus, 1 is the correct maximum surge capacity.

Why this answer

With maxSurge=25% and maxUnavailable=0%, the Deployment controller ensures that during a rolling update, the number of pods above the desired count is limited to 25% of the desired replicas, rounded up. For 4 replicas, 25% is 1, so at most 1 extra pod is created above the desired count, ensuring zero downtime by keeping all 4 original pods running until the new pod is ready.

Exam trap

The trap here is that candidates often forget that maxSurge is calculated as a percentage of the desired replicas and rounded up, leading them to incorrectly calculate 25% of 4 as 0 (if they round down) or 2 (if they double the percentage).

How to eliminate wrong answers

Option A is wrong because 2 pods would require maxSurge=50%, not 25%. Option C is wrong because 4 pods would require maxSurge=100%, which is not configured. Option D is wrong because maxSurge=25% with 4 replicas results in 1 extra pod, not 0; setting maxSurge=0% would prevent any extra pods but could cause downtime.

Full explanation →

649

MCQmedium

A DaemonSet named 'fluentd' is configured to run on all nodes. After adding a new node to the cluster, you notice that the DaemonSet pod is not running on the new node. What could be the cause?

A.The new node has a taint that the DaemonSet pod does not tolerate

B.The new node does not have enough resources to run the DaemonSet pod

C.The DaemonSet has a nodeSelector that does not match the new node's labels

D.The DaemonSet's update strategy is set to OnDelete

AnswerA

A DaemonSet controller is designed to ensure a pod runs on every eligible node. If a new node joins the cluster and has a taint, but the DaemonSet's pod template does not include a corresponding toleration, the Kubernetes scheduler will prevent the DaemonSet pod from being placed on that specific node. This is a common scenario for specialized nodes, such as master nodes, which often have `node-role.kubernetes.io/master:NoSchedule` taints by default, requiring explicit tolerations for DaemonSets like `kube-proxy` or `fluentd` to run on them.

Why this answer

A DaemonSet ensures that a copy of a pod runs on all (or a subset of) nodes. When a new node is added, the DaemonSet controller automatically schedules a pod on it unless the node has a taint that the pod does not tolerate. By default, the new node may have a taint (e.g., `node.kubernetes.io/unschedulable` or a custom taint) that prevents the DaemonSet pod from being scheduled unless the pod's spec includes a matching toleration.

Exam trap

The trap here is that candidates often confuse taints/tolerations with nodeSelector or resource constraints, assuming a new node would automatically accept all DaemonSet pods, when in fact taints are a common reason for scheduling failures on new nodes.

How to eliminate wrong answers

Option B is wrong because insufficient resources would cause the pod to remain in a Pending state (not fail to be scheduled entirely), and the DaemonSet controller would still attempt to schedule it; the question states the pod is 'not running,' which could be due to scheduling failure, but resource insufficiency is a less common cause for a new node unless it's explicitly resource-starved. Option C is wrong because a nodeSelector mismatch would prevent scheduling on any node that doesn't match the labels, but the question specifies the DaemonSet is 'configured to run on all nodes,' implying no nodeSelector is set, or if it were, it would affect all nodes equally, not just the new one. Option D is wrong because the update strategy (OnDelete) controls how pods are updated when the DaemonSet template changes, not whether pods are scheduled on new nodes; scheduling is independent of the update strategy.

Full explanation →

650

MCQeasy

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

A.kubectl get nodes

B.kubectl describe node <node-name>

C.kubectl logs <node-name>

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

AnswerB

`kubectl describe node <node-name>` is the correct first command because it displays the node's Conditions section, where the kubelet reports DiskPressure with a True/False status, the last heartbeat time, and a message explaining the eviction signal. It also aggregates related events, capacity, allocatable resources, and configured kubelet pressure thresholds. This directly and authoritatively reveals whether the node is under disk pressure and gives actionable diagnostic context.

Why this answer

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

Exam trap

CNCF often tests the distinction between high-level status commands (`kubectl get nodes`) and detailed diagnostic commands (`kubectl describe node`), trapping candidates who think a simple status list is sufficient to investigate a specific condition like DiskPressure.

Why the other options are wrong

This only lists nodes and high-level status, not detailed conditions.

Logs are for pods, not nodes.

Events may show node issues but the describe command is more comprehensive for conditions.

Full explanation →

651

Multi-Selecthard

Which two scheduling constraints can be used to ensure a pod runs on a node that has a specific label?

Select 2 answers

A.topologySpreadConstraints

B.requiredDuringSchedulingIgnoredDuringExecution in nodeAffinity

C.tolerations

D.nodeSelector

E.preferredDuringSchedulingIgnoredDuringExecution

AnswersB, D

The `requiredDuringSchedulingIgnoredDuringExecution` nodeAffinity rule enforces a hard constraint: the scheduler only places the pod on nodes matching the specified label selector, and the pod stays pending otherwise. This satisfies the stem's demand for a scheduling constraint guaranteeing placement on a labelled node, unlike preferred rules which merely bias scoring.

Why this answer

Option B (requiredDuringSchedulingIgnoredDuringExecution in nodeAffinity) is correct because it is a hard node affinity rule that forces the scheduler to place the pod only on nodes matching the specified label selector (e.g., matchExpressions or matchFields), so the pod will not be scheduled unless a node with that label exists. Option D (nodeSelector) is correct because it is the simplest scheduling constraint: the pod spec's nodeSelector field is a map of key-value pairs that must all match the node's labels for the pod to be scheduled there. Option A (topologySpreadConstraints) is not correct here because it controls how pods are distributed across topology domains (such as zones or hostnames) rather than requiring a specific node label.

Option C (tolerations) is not correct because tolerations only allow a pod to be scheduled onto nodes with matching taints; they do not select nodes by label. Option E (preferredDuringSchedulingIgnoredDuringExecution) is not correct because it is a soft affinity preference that the scheduler tries to honor but can ignore, so it cannot ensure the pod runs on a specifically labeled node.

Exam trap

The CKA exam often tests the distinction between hard constraints (`nodeSelector` and `requiredDuringSchedulingIgnoredDuringExecution` in `nodeAffinity`) and soft preferences (`preferredDuringSchedulingIgnoredDuringExecution`). It also tests the difference between node affinity (which matches node labels) and tolerations (which match node taints).

Full explanation →

652

MCQhard

You have a Deployment with livenessProbe configured. The pod restarts every few minutes. 'kubectl describe pod' shows the liveness probe is failing with 'HTTP probe failed with statuscode: 503'. The application's /healthz endpoint returns 200 from within the pod using 'kubectl exec'. What could be the issue?

A.The readinessProbe is interfering with the livenessProbe

B.The application has a memory leak

C.The kubelet on the node is misconfigured

D.The livenessProbe is configured with the wrong port

AnswerD

The livenessProbe is explicitly configured to send an HTTP request to a specific containerPort, so if that port does not match the port the application is actually listening on, kubelet will receive a connection refused error (or non-2xx response). Kubernetes treats any non-2xx response or connection error as a probe failure; after the failureThreshold is reached, kubelet kills and restarts the container. This produces exactly the observed symptom: the container starts, becomes ready for a moment, then repeatedly restarts while the application itself is healthy on its real port.

Why this answer

The liveness probe is failing externally but the endpoint works internally. This suggests the probe is hitting the wrong port or the network path is different. The most likely cause is that the livenessProbe is configured with a wrong port number.

Full explanation →

653

MCQmedium

You run: kubectl expose deployment web --port=80 --target-port=8080 --type=LoadBalancer --name=web-svc. What is the effect of this command?

A.Creates a Service of type ClusterIP which is later changed to LoadBalancer

B.Creates a Service that selects pods with label 'app=web' and maps port 80 to 8080

C.Creates a Service that selects all pods in the namespace regardless of labels

D.Creates a Service that exposes port 8080 on the node

AnswerB

When `kubectl expose` is used with a Deployment, the resulting Service automatically inherits the Deployment's label selector. For a Deployment named 'web', this selector is typically `app=web`, ensuring the Service routes traffic exclusively to the pods managed by that specific Deployment. The command specifies the Service will listen on `port 80`, and the context implies the Deployment's containers are listening on `target-port 8080`, establishing the mapping from Service port 80 to pod port 8080.

Why this answer

The `kubectl expose deployment web --port=80 --target-port=8080 --type=LoadBalancer --name=web-svc` command creates a Service named 'web-svc' that automatically inherits the label selector from the 'web' deployment (typically `app=web`). It maps the Service's port 80 to the pods' container port 8080, and the `--type=LoadBalancer` sets the Service type to LoadBalancer, which provisions an external load balancer (if supported by the cluster) and also creates a NodePort and ClusterIP automatically.

Exam trap

The trap here is that candidates often think `kubectl expose deployment` selects all pods in the namespace or requires an explicit label selector, when in fact it automatically uses the deployment's pod template labels, and the `--type=LoadBalancer` immediately creates a LoadBalancer Service, not a ClusterIP that is later upgraded.

How to eliminate wrong answers

Option A is wrong because the `--type=LoadBalancer` flag directly creates a Service of type LoadBalancer; it does not create a ClusterIP that is later changed — the type is set at creation. Option C is wrong because `kubectl expose deployment` derives the label selector from the deployment's pod template labels (e.g., `app=web`), not all pods in the namespace; it does not select all pods. Option D is wrong because the Service exposes port 80 (the Service port), not port 8080 on the node; port 8080 is the target port on the pods, and the NodePort (if any) is dynamically assigned, not explicitly set to 8080.

Full explanation →

654

MCQhard

Refer to the exhibit. A pod is defined with an emptyDir volume using memory medium. The pod is scheduled on a node with 4 GB of RAM. The container writes 3 GB of data to /cache. What will happen?

A.The container will be throttled by the kernel's memory management.

B.The pod will be evicted because emptyDir with memory is not allowed to use more than 1 GB.

C.The pod will be OOMKilled because the emptyDir memory usage exceeds the default limit.

D.The pod will run normally because there is no memory limit and the node has sufficient RAM.

AnswerD

When an emptyDir volume is configured with medium: Memory, Kubernetes mounts a tmpfs filesystem that consumes the host node's RAM. Because the pod has no defined memory limits and the 3 GB of written data fits within the node's 4 GB of physical RAM, the operation completes successfully. The pod will continue to run normally without triggering eviction or OOM termination.

Why this answer

An emptyDir volume with `medium: Memory` creates a tmpfs filesystem that uses the node's RAM, but it does not impose any inherent limit on how much memory the container can consume via that volume. Since the pod has no memory limit set (no `resources.limits.memory`), the container can write up to the node's available memory (4 GB) without being throttled or killed, as long as the node has sufficient free RAM.

Exam trap

The trap here is that candidates assume emptyDir with `medium: Memory` has a default limit or triggers OOMKill, when in fact it only uses node memory and is constrained only by explicit `sizeLimit` or node capacity.

How to eliminate wrong answers

Option A is wrong because kernel memory throttling only applies when a cgroup memory limit is configured; without a limit, the container can use memory freely until the node runs out. Option B is wrong because there is no default 1 GB limit for emptyDir with memory; the size is bounded only by the node's memory capacity unless explicitly restricted via `sizeLimit`. Option C is wrong because OOMKilling occurs when a container exceeds its memory limit (set via `resources.limits.memory`) or when the node is under memory pressure; here, no limit is set and the node has sufficient RAM, so no OOMKill will occur.

Full explanation →

655

Multi-Selectmedium

Which TWO statements about EndpointSlices are true? (Choose 2)

Select 2 answers

A.EndpointSlices are only used for Services of type ClusterIP

B.EndpointSlices are automatically created and managed by the EndpointSlice controller

C.EndpointSlices replace Endpoints in all Kubernetes versions

D.EndpointSlices support dual-stack networking

E.EndpointSlices can contain up to 100 endpoints each

AnswersB, D

EndpointSlices are the primary endpoint discovery API and are reconciled by the EndpointSlice controller running inside kube-controller-manager. This controller watches Service and Pod events, generating and updating EndpointSlice objects to reflect the current set of backing Pod IPs and ports, and also handles not-ready addresses and topology hints. When a Service is deleted, the corresponding EndpointSlices are automatically cleaned up, which is why operators do not manage EndpointSlices directly in normal operations.

Why this answer

Option B is correct because the EndpointSlice controller in the Kubernetes control plane (kube-controller-manager) automatically creates and manages EndpointSlice objects for Services that have selectors, keeping them in sync with the matching Pods. Option D is correct because EndpointSlices natively support dual-stack networking by including an addressType field (IPv4, IPv6, or FQDN) and can represent endpoints of both IP families for a Service. Option A is wrong because EndpointSlices back Services of any type that use selectors, including ClusterIP, NodePort, and LoadBalancer, not just ClusterIP.

Option C is wrong because EndpointSlices were introduced as an alpha feature in Kubernetes 1.16 and became GA in 1.21; older versions still rely solely on Endpoints, so they do not replace Endpoints in all versions. Option E is wrong because the default maximum is 100 endpoints per EndpointSlice, but this is a configurable limit (via --max-endpoints-per-slice on the controller manager), so stating a fixed cap of 100 as an absolute truth is inaccurate.

Exam trap

The trap here is that candidates often assume EndpointSlices have a hard-coded limit of 100 endpoints, but the CKA exam expects you to know that this value is configurable and not an immutable constraint.

Full explanation →

656

MCQmedium

A developer creates a PVC with storageClassName: "" (empty string). What does this mean?

A.The PVC will remain pending indefinitely

B.The PVC will use the default StorageClass

C.The PVC will be dynamically provisioned using the cluster's default StorageClass

D.The PVC will only bind to PVs that also have storageClassName: ""

AnswerD

Setting storageClassName: "" on a PVC restricts binding exclusively to PersistentVolumes that also have their storageClassName set to an empty string or omitted. This behavior ensures that the PVC bypasses dynamic provisioning entirely. It allows the PVC to bind only to statically created PVs that represent pre-existing physical storage assets.

Why this answer

When a PVC has `storageClassName: ""` (empty string), it explicitly disables dynamic provisioning and static binding to a PV that also has `storageClassName: ""`. This means the PVC will only bind to a pre-existing PV that has its `storageClassName` set to an empty string, bypassing any default StorageClass. It does not remain pending indefinitely, nor does it use or trigger the default StorageClass.

Exam trap

The trap here is that candidates often confuse an empty string `""` with omitting the field entirely, assuming it will fall back to the default StorageClass, but Kubernetes treats them as distinct: omitted means 'use default', while empty string means 'disable default and require exact match'.

How to eliminate wrong answers

Option A is wrong because the PVC will not remain pending indefinitely; it will bind to a PV with `storageClassName: ""` if one exists, or remain pending only until such a PV is created. Option B is wrong because setting `storageClassName: ""` explicitly overrides the default StorageClass; the PVC will not use it. Option C is wrong because dynamic provisioning is disabled when `storageClassName` is set to an empty string; the PVC will not be dynamically provisioned by any StorageClass, including the default.

Full explanation →

657

MCQmedium

A pod with a resource request of 500m CPU and a limit of 1 CPU is scheduled. The node has a CPU capacity of 2 cores. What does the '500m' represent?

A.500 millicores (0.5 CPU core)

B.500 megabytes of memory

C.50% of the node's CPU capacity

D.A limit of 500,000 CPU seconds per day

AnswerA

In Kubernetes, CPU resources are specified in millicores, where 'm' is the unit suffix. A value of 500m precisely denotes 500 millicores, which is equivalent to 0.5 of a full CPU core. This is the standard, absolute measure for CPU requests and limits, ensuring consistent resource allocation across nodes.

Why this answer

In Kubernetes, CPU resources are measured in millicores, where 1000m equals 1 full CPU core (vCPU or hyperthread). The '500m' in a resource request means the pod is guaranteed at least 500 millicores, or 0.5 CPU core, from the node's 2-core capacity. This is a standard unit used by the kubelet for CPU scheduling and the Completely Fair Scheduler (CFS) quota enforcement.

Exam trap

The trap here is that candidates confuse the 'm' suffix with megabytes or a percentage, when in Kubernetes it specifically denotes millicores (1/1000th of a CPU core).

How to eliminate wrong answers

Option B is wrong because '500m' is a CPU unit, not a memory unit; memory is expressed in bytes (e.g., Mi, Gi). Option C is wrong because 500m represents 0.5 cores, not 50% of the node's total capacity (which would be 1 core on a 2-core node). Option D is wrong because CPU limits in Kubernetes are not measured in seconds per day; they are enforced as a maximum usage rate (e.g., via CFS quota) over short intervals, not a daily cap.

Full explanation →

658

MCQeasy

Which command can you use to view the logs of a container that has crashed and been restarted?

A.kubectl describe pod pod-name

B.kubectl logs pod-name --previous

C.kubectl exec pod-name -- cat /var/log/crash.log

D.kubectl logs pod-name

AnswerB

The --previous flag tells kubectl to fetch logs from the last terminated instance of a container in the pod, which is exactly what you need when the current container has already crashed and restarted. Since a container that has exited no longer has accessible live logs, this flag retrieves the previously captured log output from the terminated container, allowing you to diagnose the cause of the crash. This is the standard approach for debugging CrashLoopBackOff or a one-time termination before the current container starts. Without the flag, you would only get logs from the current, possibly already-restarted container, missing the crash evidence.

Why this answer

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

Full explanation →

659

Multi-Selectmedium

Which of the following can be used to expose a set of pods externally to the internet in a Kubernetes cluster? (Select THREE.)

Select 3 answers

A.Ingress resource

B.Service of type NodePort

C.Service of type LoadBalancer

D.Service of type Headless

E.Service of type ClusterIP

AnswersA, B, C

Ingress is not a Service type but a separate Kubernetes API object that exposes HTTP and HTTPS routes from outside the cluster to Services. It operates at Layer 7, allowing hostname- and path-based routing, TLS termination, and virtual hosting, and it requires an Ingress controller (e.g., NGINX, Traefik) to interpret and implement the rules.

Why this answer

An Ingress resource (A) exposes HTTP/HTTPS routes from outside the cluster to Services inside the cluster, acting as a layer-7 entry point with rules and TLS termination, so it can publish a set of pods to the internet. A Service of type NodePort (B) exposes the Service on each node's IP at a static port (default range 30000-32767), making the pods reachable externally via any node IP and that port. A Service of type LoadBalancer (C) provisions an external load balancer (e.g., via a cloud provider) that routes internet traffic to the Service's endpoints, directly exposing the pods externally.

A headless Service (D) sets clusterIP: None and returns pod IPs directly via DNS for direct pod addressing, but it does not provide an external entry point. A Service of type ClusterIP (E) only assigns a virtual IP reachable within the cluster, so it is not externally accessible without additional components like Ingress or NodePort.

Exam trap

A common mistake is thinking that a Headless service can be used for external exposure because it still has a DNS name, but it lacks any IP or port mapping for external traffic. Headless services are intended for internal service discovery, not external exposure.

Full explanation →

660

Multi-Selectmedium

Which three are valid pod phases?

Select 3 answers

A.Pending

B.Terminating

C.Succeeded

D.CrashLoopBackOff

E.Running

AnswersA, C, E

Pending is a valid pod phase defined in the Kubernetes API (PodStatus.phase). A pod enters Pending as soon as the API server records it, but it has not yet been fully accepted by a kubelet: this phase covers scheduling onto a node, pulling container images, and waiting for containers to start. If scheduling fails, the pod can stay Pending indefinitely, and the condition PodScheduled=False typically explains why.

Why this answer

Option A (Pending) is a valid pod phase: it means the pod has been accepted by the Kubernetes API server but one or more containers are not yet running, typically because images are still being pulled or scheduling is incomplete. Option C (Succeeded) is valid: it indicates all containers in the pod terminated successfully with exit code 0 and the pod will not be restarted. Option E (Running) is valid: it means the pod has been bound to a node and all containers have been created, with at least one container still running or starting/restarting.

The unmarked options do not belong because Terminating is not a pod phase (it is a deletion state reflected in metadata.deletionTimestamp), and CrashLoopBackOff is a container waiting reason, not a pod phase.

Exam trap

The CKA exam often tests the distinction between pod phases and container states, so the trap here is confusing container-level statuses like CrashLoopBackOff or Terminating with the higher-level pod phase.

Full explanation →

661

MCQhard

You have a StatefulSet with 5 pods, each requiring a unique stable network identity. The StatefulSet is scaled down from 5 to 3. Which pods will be terminated?

A.Random pods

B.Pods with the highest ordinals (4 and 3)

C.Pods with the lowest ordinals (0 and 1)

D.Pods with the highest resource usage

AnswerB

Correct. The StatefulSet controller honors the ordinal ordering by deleting pods with the highest index numbers first. For a 5-pod StatefulSet (ordinals 0 through 4) scaling from 5 to 3 replicas, pods 4 and 3 are removed because they are the highest ordinals. This preserves the sequential identity of the remaining pods (0, 1, 2) and their associated storage, which is the core behavior of StatefulSet lifecycle management.

Why this answer

When a StatefulSet is scaled down, Kubernetes terminates pods in reverse order of their ordinal indices, starting from the highest. For a StatefulSet with 5 pods (ordinals 0-4) scaled to 3, pods with ordinals 4 and 3 are terminated first, ensuring that the remaining pods (0, 1, 2) maintain their stable network identities and storage.

Exam trap

The trap here is that candidates may assume pods are terminated randomly or based on resource usage, but the CKA exam tests the specific deterministic behavior of StatefulSet scaling, which always removes pods with the highest ordinals first.

How to eliminate wrong answers

Option A is wrong because StatefulSet does not terminate pods randomly; it follows a deterministic ordinal-based termination order. Option C is wrong because pods with the lowest ordinals (0 and 1) are the last to be terminated, not the first, as the scaling-down process removes pods from the highest ordinal downward. Option D is wrong because StatefulSet termination is based on ordinal index, not resource usage; resource-aware termination is not a feature of StatefulSet scaling.

Full explanation →

662

Multi-Selectmedium

Which two statements about HorizontalPodAutoscaler (HPA) are correct?

Select 2 answers

A.HPA is a namespaced resource

B.HPA can scale based on custom metrics

C.HPA can only target Deployments

D.HPA requires the metrics-server to be installed

E.HPA can scale down to zero replicas

AnswersA, B

The HorizontalPodAutoscaler (HPA) is indeed a namespaced resource in Kubernetes. It lives in a specific namespace, and its name must be unique within that namespace but can be reused across different namespaces. When you create an HPA, it can only target workloads (such as Deployments or StatefulSets) that exist in the same namespace, and it reads the scale subresource of that target through the namespaced API path.

Why this answer

HorizontalPodAutoscaler (HPA) is a namespaced resource in Kubernetes, meaning it exists within a specific namespace and can only target resources (like Deployments or StatefulSets) in that same namespace. This is defined in the Kubernetes API under the `autoscaling/v2` group, where HPA objects are scoped to a namespace, not cluster-wide.

Exam trap

The trap here is that candidates often assume HPA requires the metrics-server for all metric types, but the CKA exam tests the understanding that HPA can use custom and external metrics without the metrics-server, and that scaling to zero is not a native HPA feature.

Full explanation →

663

MCQmedium

A DevOps team is deploying a stateful application that requires persistent storage with ReadWriteMany access mode across multiple pods running on different nodes in a Kubernetes cluster. Which storage solution should they choose to meet this requirement?

A.Use an emptyDir volume and share it among pods via a service

B.Create a local PersistentVolume on each node and use nodeSelector to pin pods

C.Use a hostPath volume mounted in each pod with the same path on each node

D.Configure a PersistentVolume backed by NFS and a PersistentVolumeClaim with accessModes: ReadWriteMany

AnswerD

Network File System (NFS) is a network-attached storage solution that natively supports the ReadWriteMany (RWX) access mode in Kubernetes. This configuration allows multiple Pods distributed across different nodes in the cluster to simultaneously read from and write to the same persistent volume.

Why this answer

NFS supports ReadWriteMany (RWX) access mode, allowing multiple pods across different nodes to read and write to the same persistent storage simultaneously. A PersistentVolume backed by NFS, combined with a PersistentVolumeClaim specifying accessModes: ReadWriteMany, meets the requirement for a stateful application needing shared storage across nodes.

Exam trap

The trap here is that candidates often confuse hostPath or local volumes as viable for multi-node sharing, not realizing that only network-based storage solutions like NFS, GlusterFS, or cloud-native RWX volumes (e.g., Azure Files, EFS) can provide ReadWriteMany access across nodes.

How to eliminate wrong answers

Option A is wrong because emptyDir volumes are ephemeral and tied to a single pod's lifecycle; they cannot be shared across pods on different nodes. Option B is wrong because local PersistentVolumes are node-specific and only support ReadWriteOnce (RWO), not ReadWriteMany, and using nodeSelector to pin pods defeats the purpose of multi-node access. Option C is wrong because hostPath volumes mount a directory from the node's filesystem, which is node-specific and does not provide shared access across different nodes; pods on different nodes would see different storage.

Full explanation →

664

MCQmedium

A developer created a ClusterRole named 'pod-reader' with rules to get and list pods. They created a ClusterRoleBinding 'read-pods-global' binding this ClusterRole to a service account 'sa-pod-reader' in the 'default' namespace. Which of the following is true about the permissions of this service account?

A.The service account can only read pods in the 'default' namespace

B.The service account can read pods in all namespaces

C.The service account can only list pods, not get them

D.The service account cannot read pods in any namespace

AnswerB

This is correct because a ClusterRoleBinding grants the permissions defined in the ClusterRole to the specified subject (the service account) cluster-wide. The pod-reader ClusterRole includes the 'get' and 'list' verbs on 'pods', and those permissions apply to pods in all namespaces. Therefore, the service account can read pod objects from any namespace, including metadata, specs, and statuses.

Why this answer

ClusterRoleBindings are cluster-scoped, meaning they grant permissions across all namespaces. Since the ClusterRoleBinding 'read-pods-global' binds the 'pod-reader' ClusterRole to the service account 'sa-pod-reader', the service account can get and list pods in every namespace, not just the 'default' namespace.

Exam trap

The trap here is that candidates often confuse ClusterRoleBindings with RoleBindings, mistakenly thinking the service account's permissions are limited to the namespace where the binding or the service account is defined.

How to eliminate wrong answers

Option A is wrong because a ClusterRoleBinding grants permissions cluster-wide, not limited to the namespace of the service account or the binding. Option C is wrong because the ClusterRole 'pod-reader' includes both 'get' and 'list' verbs, so the service account can perform both operations. Option D is wrong because the binding successfully grants the permissions defined in the ClusterRole, so the service account can read pods in all namespaces.

Full explanation →

665

MCQhard

A node is NotReady. You ssh into the node and run 'systemctl status kubelet'. It shows 'Active: inactive (dead)'. What is the most appropriate next step?

A.journalctl -u kubelet

B.systemctl start kubelet

C.kubectl delete node <node-name>

D.systemctl restart docker

AnswerB

systemctl start kubelet directly addresses the most common cause of a NotReady node: the kubelet service being stopped or inactive. When started, the kubelet initializes, connects to the API server, and begins sending its Node status heartbeat, which the node controller uses to mark the node Ready once all conditions (such as memory, disk, and runtime) are satisfied. This is the immediate, targeted remediation for a node stuck in NotReady due to a down kubelet, and it is the correct first step after confirming the service is not running.

Why this answer

Starting the kubelet service with systemctl start kubelet is the correct action. Investigating logs may be needed if it fails to start.

Full explanation →

666

MCQeasy

Which control plane component stores the entire cluster state?

A.kube-controller-manager

B.kube-scheduler

C.kube-apiserver

D.etcd

AnswerD

etcd is a strongly consistent, highly available, distributed key-value store used as Kubernetes' secure registry for all cluster data. Every single object, configuration, and status detail in the cluster is persisted within etcd. It serves as the single source of truth, ensuring that the cluster state can be reliably recovered in the event of a control plane failure.

Why this answer

Etcd because it is the distributed key-value store that serves as the single source of truth for the entire cluster state, including all objects, configurations, and secrets. The kube-apiserver is the only component that directly interacts with etcd, but it does not store the state itself—it reads from and writes to etcd on behalf of other components.

Exam trap

The trap here is that candidates often confuse the kube-apiserver as the storage layer because it is the only component that interacts with etcd, but the apiserver is merely a gateway and does not persist data itself.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager is a control loop that watches the shared state through the kube-apiserver and makes changes to move the current state toward the desired state, but it does not store the cluster state. Option B is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, and it reads node and pod information from the kube-apiserver but does not persist any state. Option C is wrong because kube-apiserver is the front-end for the Kubernetes control plane that validates and processes RESTful API requests, but it is stateless and relies on etcd for persistent storage of the cluster state.

Full explanation →

667

MCQmedium

After upgrading the control plane using kubeadm, you need to update the kubelet configuration on the node. Which command should you run on the node?

A.kubeadm upgrade apply

B.kubectl upgrade node

C.kubeadm upgrade node

D.kubeadm upgrade plan

AnswerC

Once the primary control plane node is upgraded, you must run this command on all other control plane nodes and worker nodes to upgrade their local configurations. This command fetches the cluster configuration from the API server and updates the local kubelet configuration files and certificates accordingly.

Why this answer

`kubeadm upgrade node` is the command used on worker nodes (or secondary control-plane nodes) after the primary control plane has been upgraded. It upgrades the kubelet configuration and other node-specific components to match the new cluster version, ensuring the node can rejoin the upgraded cluster.

Exam trap

The trap here is that candidates confuse `kubeadm upgrade apply` (for the first control-plane node) with `kubeadm upgrade node` (for worker nodes), or they invent a non-existent `kubectl upgrade node` command because they expect kubectl to manage node upgrades.

How to eliminate wrong answers

Option A is wrong because `kubeadm upgrade apply` is run on the first control-plane node to initiate the cluster upgrade, not on a worker node to update its kubelet configuration. Option B is wrong because `kubectl upgrade node` is not a valid kubectl command; kubectl does not have an 'upgrade' subcommand for nodes. Option D is wrong because `kubeadm upgrade plan` is used to check available versions and plan the upgrade, not to perform the actual upgrade or update kubelet configuration on a node.

Full explanation →

668

Multi-Selectmedium

Which TWO of the following are valid ways to inject a ConfigMap into a pod as environment variables? (Select 2)

Select 2 answers

A.Using volumeMounts with configMapKeyRef

B.Using env with configMapRef

C.Using env with valueFrom.configMapKeyRef

D.Using envFrom with configMapRef

E.Using volumes with configMap

AnswersC, D

This is the precise way to inject a single key from a ConfigMap into a single environment variable. The env entry defines the environment variable's name, and valueFrom.configMapKeyRef specifies the ConfigMap name and the exact key to pull the value from. It gives you fine-grained control over which keys get exposed and what they are called in the environment, unlike envFrom which blindly imports all keys. You can also add an optional 'optional' field to make the resource not fail if the key is missing.

Why this answer

Option C is correct because the env.valueFrom.configMapKeyRef field lets you map a single specific key from a ConfigMap to one environment variable in the container spec. Option D is correct because envFrom.configMapRef imports all key/value pairs from a referenced ConfigMap as environment variables in the container, which is the bulk-injection mechanism. Option A is incorrect because volumeMounts mounts volumes into the filesystem and does not use configMapKeyRef, which is an env-source field, not a volume field.

Option B is incorrect because the env list does not support a configMapRef field; the correct env-level reference is valueFrom.configMapKeyRef, while configMapRef belongs under envFrom. Option E is incorrect because volumes with configMap project ConfigMap data as files in a mounted volume, not as environment variables.

Exam trap

The trap here is that candidates often confuse `configMapRef` (used with `envFrom`) with `configMapKeyRef` (used with `valueFrom`), or incorrectly assume that volume mounts can inject environment variables, leading them to select options A or B.

Full explanation →

669

MCQmedium

You run 'kubectl get nodes' and see that one node is in the 'NotReady' state. Which command would you use FIRST to investigate the kubelet status on that node?

A.ssh to the node and run 'docker ps'

B.kubectl describe node <node-name>

C.kubectl logs kubelet -n kube-system

D.systemctl status kubelet

AnswerD

The 'kubelet' runs as a 'systemd' service on each Kubernetes node, responsible for registering the node with the cluster and managing pods. To diagnose issues where a node is not ready, checking the 'kubelet' service status directly on the node using 'systemctl status kubelet' is the most effective first step. This command provides real-time information about whether the service is active, stopped, or failed, along with recent log entries that often pinpoint the root cause of any operational problems.

Why this answer

The kubelet is the primary node agent that registers the node with the cluster and reports its status via periodic heartbeats. When a node is NotReady, the first step is to check if the kubelet service is running on that node using `systemctl status kubelet` (or `journalctl -u kubelet`), because a stopped or unhealthy kubelet will directly cause the node to lose connectivity with the control plane. This command is the most direct way to verify the kubelet's process state and recent logs on the node itself.

Exam trap

The trap here is that candidates assume `kubectl describe node` is the first troubleshooting step for a NotReady node, but it only shows the symptom from the control plane's view, not the root cause on the node, which requires direct node access to check the kubelet service.

How to eliminate wrong answers

Option A is wrong because `docker ps` only lists running containers managed by Docker, not the kubelet service itself, and the kubelet may be running as a systemd unit or binary, not a container. Option B is wrong because `kubectl describe node` shows the node's status and conditions from the control plane's perspective, but if the kubelet is down, the API server may have stale data and cannot reveal the actual kubelet process state on the node. Option C is wrong because `kubectl logs kubelet -n kube-system` assumes the kubelet runs as a pod in the cluster, which is not the case—kubelet is a system-level daemon managed by systemd, not a Kubernetes workload, so its logs are accessed via `journalctl` or `systemctl`, not `kubectl logs`.

Full explanation →

670

MCQeasy

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

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

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

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

D.kubectl create secret generic app-config --from-file=config.properties

AnswerB

This command correctly generates a ConfigMap named app-config by reading the contents of the specified local file. By using the --from-file flag, Kubernetes automatically uses the filename config.properties as the key and maps the entire file content as its corresponding value. This is the standard declarative approach for importing file-based configuration into a cluster.

Why this answer

`kubectl create configmap app-config --from-file=config.properties` directly reads the file `config.properties` and creates a ConfigMap named `app-config` with a key equal to the filename (i.e., `config.properties`) and the value set to the file's content. The `--from-file` flag without a key specification uses the filename as the key. Option A is incorrect because the syntax `--from-file=key=config.properties` creates a ConfigMap with the key "key", not the filename.

Option C is incorrect because `--from-literal` is for literal key-value pairs, not files. Option D is incorrect because `kubectl create secret generic` creates a Secret, not a ConfigMap.

Exam trap

The trap here is that candidates confuse `--from-file` with `--from-literal` or `--from-env-file`, or mistakenly think that `--from-file` requires an explicit key assignment, leading them to choose option A or C, while also forgetting that `kubectl create secret generic` is for Secrets, not ConfigMaps, as in option D.

How to eliminate wrong answers

Option A is wrong because `--from-file=key=config.properties` specifies a custom key (`key`) but the syntax is incorrect; the correct syntax for a custom key is `--from-file=<key>=<file-path>`, but here it would create a ConfigMap with a single entry named `key` rather than using the file's content appropriately, and the question asks for a command that creates a ConfigMap from the file without specifying a custom key. Option C is wrong because `--from-literal` is used to pass key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to read from a file; using `--from-literal=config.properties` would treat the string `config.properties` as a literal value, not as a file path. Option D is wrong because it uses `kubectl create secret generic` instead of `kubectl create configmap`, which creates a Secret, not a ConfigMap; additionally, the `--from-file` flag with a Secret would store the file content as a Secret, which is not the intended resource type.

Full explanation →

671

MCQhard

A Kubernetes cluster has a node pool with GPU nodes labeled 'accelerator=nvidia-tesla'. A Pod requires a GPU. Which configuration is necessary?

A.Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution for the GPU label.

B.Set resources.limits for 'nvidia.com/gpu' only.

C.Set nodeSelector to 'accelerator=nvidia-tesla' and request 'nvidia.com/gpu' in resources.

D.Add a toleration for GPU node taints.

AnswerC

This is the correct and comprehensive approach because it addresses both the placement of the Pod and the allocation of the specialized hardware resource. The `nodeSelector` ensures the Pod is scheduled exclusively onto nodes labeled `accelerator=nvidia-tesla`, which are the GPU-equipped nodes in this scenario. Simultaneously, requesting `nvidia.com/gpu` in the Pod's `resources` section (either `requests` or `limits`) informs the Kubernetes device plugin for NVIDIA GPUs to allocate a specific GPU device to the container, making it available inside the Pod. Both mechanisms are crucial for successful GPU workload deployment.

Why this answer

A Pod that requires a GPU must both be scheduled onto a node with the appropriate GPU label and explicitly request the GPU resource. The `nodeSelector` ensures the Pod lands on a node labeled `accelerator=nvidia-tesla`, and requesting `nvidia.com/gpu` in `resources.requests` or `resources.limits` (typically limits) tells the kubelet to allocate a GPU device to the container. Without the resource request, the scheduler has no way to account for GPU capacity, and without the nodeSelector, the Pod might be scheduled on a non-GPU node.

Exam trap

The trap here is that candidates often think either node selection (nodeSelector/affinity) or resource requests alone is sufficient, but the CKA exam requires both to be present for a GPU workload to function correctly.

How to eliminate wrong answers

Option A is wrong because `nodeAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` is a valid way to select GPU nodes, but it is not sufficient on its own — the Pod must also request the `nvidia.com/gpu` resource to actually get a GPU assigned. Option B is wrong because setting `resources.limits` for `nvidia.com/gpu` alone does not guarantee the Pod lands on a GPU node; without a nodeSelector or affinity, the scheduler may place the Pod on a non-GPU node where the resource is unavailable. Option D is wrong because GPU nodes do not inherently have taints; while administrators may add taints to GPU nodes, a toleration is only needed if a taint is present, and it is not a required configuration for GPU access.

Full explanation →

672

MCQmedium

An administrator runs 'kubectl get pods' and sees a pod in 'Pending' state. The output of 'kubectl describe pod pod-name' shows '0/1 nodes are available: 1 node(s) had taint that the pod didn't tolerate'. What is the most likely cause?

A.The pod's container image is not found

B.The node has a taint that repels the pod, and the pod lacks the corresponding toleration

C.The pod has a resource request that exceeds available resources

D.The pod's namespace does not exist

AnswerB

When a node is configured with a taint using the NoSchedule or NoExecute effect, the Kubernetes scheduler will actively reject any pods that do not possess a matching toleration. Consequently, if no other eligible nodes are available, the pod remains stuck in the Pending state with a scheduling failure event logged in its description.

Why this answer

The pod is in 'Pending' state because the scheduler cannot find a node that satisfies the pod's scheduling constraints. The 'kubectl describe pod' output explicitly states '0/1 nodes are available: 1 node(s) had taint that the pod didn't tolerate', which means the node has a taint (e.g., a key-value pair with an effect like NoSchedule) and the pod does not have a matching toleration in its spec. This prevents the pod from being scheduled onto that node, leaving it stuck in Pending.

Exam trap

CNCF often tests the distinction between taints/tolerations and node affinity/anti-affinity — candidates may confuse the 'taint that the pod didn't tolerate' message with a resource shortage or node selector issue, but the exact phrase in 'kubectl describe' is the key diagnostic clue.

How to eliminate wrong answers

Option A is wrong because a missing container image would cause the pod to enter 'ImagePullBackOff' or 'ErrImagePull' state, not 'Pending' — the pod would be scheduled first, then fail at the container runtime level. Option C is wrong because insufficient resources (e.g., CPU/memory requests exceeding node capacity) would produce a different scheduler message like '0/1 nodes are available: 1 Insufficient cpu' or 'Insufficient memory', not a taint-related message. Option D is wrong because a non-existent namespace would cause the pod creation to fail immediately with an error like 'namespaces "x" not found' when running 'kubectl run' or 'kubectl apply', not a 'Pending' state after the pod object exists.

Full explanation →

673

Multi-Selectmedium

Which TWO statements about Kubernetes resource requests and limits are correct? (Select 2)

Select 2 answers

A.Limits can be set independently for CPU and memory.

B.Memory requests and limits are both compressible.

C.If a container exceeds its memory limit, it is throttled.

D.CPU requests are used for scheduling decisions.

E.If no limits are specified, the pod can use unlimited resources.

AnswersA, D

Kubernetes allows fine-grained resource configuration, meaning you can define a CPU limit without specifying a memory limit, or vice versa. This independence allows operators to tailor resource constraints to the specific workload profile, such as CPU-bound or memory-bound applications.

Why this answer

Option A is correct because Kubernetes allows CPU and memory limits to be configured separately per container via resources.limits.cpu and resources.limits.memory, so you can cap one resource without capping the other. Option D is correct because the kube-scheduler uses the sum of container CPU requests (resources.requests.cpu) when filtering and scoring nodes, ensuring a node has enough allocatable CPU to satisfy the pod's guaranteed share. Option B is wrong because memory is incompressible: exceeding a memory limit triggers OOMKill rather than throttling, whereas CPU is the compressible resource.

Option C is wrong because exceeding a memory limit causes the container to be terminated with an OOMKilled status, not throttled; CPU limit overuse is what gets throttled via CFS quota. Option E is wrong because a pod without explicit limits is not truly unlimited: it can burst up to node allocatable capacity, but it is still constrained by the node's resources and may be evicted under pressure, and in namespaces with a LimitRange, default limits may be applied automatically.

Exam trap

The trap here is confusing compressible (CPU) and incompressible (memory) resources — candidates often think memory can be throttled like CPU, but exceeding memory limits always results in termination, not throttling.

Full explanation →

674

MCQhard

A pod has tolerations for a taint with key 'dedicated', value 'gpu', and effect 'NoSchedule'. The pod's nodeSelector is {disktype: ssd}. Which node(s) can this pod be scheduled on? (Assume node1 has taint dedicated=gpu:NoSchedule and label disktype=ssd; node2 has taint dedicated=gpu:NoSchedule and label disktype=hdd; node3 has no taint and label disktype=ssd)

A.node1 only

B.node2 and node3

C.node1, node2, and node3

D.node1 and node3

AnswerD

Node1 qualifies because it satisfies the nodeSelector and has a toleration that matches the dedicated taint, so the taint is effectively ignored. Node3 qualifies because it has no taint, meaning no toleration is needed, and it also satisfies the nodeSelector. Node2 is excluded because it fails the nodeSelector label requirement. Thus the correct schedulable set is node1 and node3.

Why this answer

The pod has a toleration for the taint dedicated=gpu:NoSchedule, so it can tolerate that taint on any node. However, the pod also has a nodeSelector requiring disktype=ssd. Node1 has both the tolerated taint and the required label, so it qualifies.

Node3 has no taint and the required label, so it also qualifies. Node2 has the tolerated taint but its label is disktype=hdd, which does not match the nodeSelector, so it is excluded. Therefore, only node1 and node3 can schedule the pod.

Exam trap

The trap here is that candidates often think tolerations are required to match taints on all nodes, forgetting that a node without the taint is also eligible, and they may overlook that nodeSelector is a separate, mandatory constraint that can exclude nodes even if they are tolerated.

How to eliminate wrong answers

Option A is wrong because it ignores node3, which has no taint and the required label disktype=ssd, so the pod can schedule there as well. Option B is wrong because node2 has label disktype=hdd, which does not match the pod's nodeSelector, so it cannot schedule on node2; node3 is correct, but node2 is not. Option C is wrong because node2 is excluded due to its label not matching the nodeSelector, so not all three nodes are valid.

Full explanation →

675

MCQmedium

A Deployment named 'app' has 3 replicas. The rolling update strategy is set with maxSurge=1 and maxUnavailable=1. During an update, a new ReplicaSet is created. How many pods will be in terminating state at the moment when the new ReplicaSet has 2 pods ready?

A.3

B.0

C.1

D.2

AnswerC

When one old pod is terminating and two new pods are ready, the deployment maintains a balanced state. There would be two old pods still running, plus the two new ready pods, totaling four active pods. This adheres to the `maxSurge=1` rule (4 <= 3 + 1). Crucially, only one pod is unavailable (the terminating old pod), which perfectly satisfies the `maxUnavailable=1` policy, ensuring minimal service disruption during the update.

Why this answer

With maxSurge=1 and maxUnavailable=1, the Deployment controller ensures that during a rolling update, the total number of pods across old and new ReplicaSets does not exceed desiredReplicas + maxSurge (3+1=4). When the new ReplicaSet has 2 pods ready, the controller will begin terminating old pods to bring the total down. At that exact moment, exactly 1 old pod will be in Terminating state, as the controller scales down the old ReplicaSet by 1 to maintain the surge limit.

Exam trap

The trap here is that candidates often confuse the number of ready pods with the number of terminating pods, or incorrectly assume that the controller terminates all old pods at once, ignoring the maxSurge and maxUnavailable constraints that limit the scale-down to 1 pod at a time.

How to eliminate wrong answers

Option A is wrong because 3 terminating pods would exceed the maxUnavailable=1 limit, meaning more than 1 pod would be unavailable at once, which violates the update strategy. Option B is wrong because 0 terminating pods would imply no old pods are being removed, but with 2 new pods ready and maxSurge=1, the controller must start terminating old pods to stay within the surge budget. Option D is wrong because 2 terminating pods would require the old ReplicaSet to scale down by 2, but with only 2 new pods ready, the total pods would be 3 (old) + 2 (new) = 5, exceeding the maxSurge limit of 4 (3 desired + 1 surge).

Full explanation →

Certified Kubernetes Administrator CKA (CKA) — Questions 601–675