Certified Kubernetes Administrator CKA CKA Questions 751–825 | Page 11/14

751

MCQmedium

A pod cannot resolve a Service name 'my-svc' in the same namespace. The DNS pod is running. What is a likely cause?

A.The kube-proxy is not running

B.The Service type is ExternalName

C.The Service 'my-svc' does not exist

D.The pod is in a different namespace

AnswerC

If the Service doesn't exist, DNS will return NXDOMAIN.

Why this answer

The most common cause is that the Service does not exist or has no endpoints. If the Service exists and has endpoints, DNS should resolve. Another possibility is a misconfigured CoreDNS, but the question says DNS pod is running.

Full explanation →

752

MCQmedium

An administrator runs 'kubectl run test-pod --image=nginx' and the pod is created but stays in 'Pending' state. Which command would BEST help diagnose why the pod is not running?

A.kubectl logs test-pod

B.kubectl describe pod test-pod

C.kubectl exec -it test-pod -- /bin/bash

D.kubectl get events

AnswerB

The describe command shows events and conditions that explain why the pod is pending.

Why this answer

Option B is correct because `kubectl describe pod test-pod` provides a detailed summary of the pod's current state, including events, conditions, and status messages that reveal why the pod is stuck in 'Pending'. The 'Pending' state typically indicates that the pod has not been scheduled to a node, often due to resource constraints (CPU/memory), persistent volume claims not being bound, or node selector mismatches. The 'Conditions' and 'Events' sections in the output directly expose these issues, making it the most effective diagnostic command.

Exam trap

The trap here is that candidates often assume `kubectl logs` or `kubectl exec` can diagnose startup issues, but these commands only work on running containers, so they fail silently or with errors when the pod is still pending, wasting time and misdirecting troubleshooting.

How to eliminate wrong answers

Option A is wrong because `kubectl logs test-pod` retrieves container logs, but the pod is in 'Pending' state and has not started any containers, so there are no logs to fetch; this command would fail with an error like 'container is waiting to start'. Option C is wrong because `kubectl exec -it test-pod -- /bin/bash` attempts to execute a command inside a running container, but since the pod is not running (Pending), there is no container to attach to, and the command will fail. Option D is wrong because `kubectl get events` shows cluster-wide events, which may include relevant information but is less targeted than `kubectl describe pod`; it requires filtering through many events and may not show pod-specific details like scheduler failure reasons or volume binding errors as clearly.

Full explanation →

753

MCQmedium

The controller-manager logs show repeated errors: 'Failed to list *v1.Pod: connection refused'. What is the most likely cause?

A.The API server is down or not reachable

B.The kube-controller-manager is not running

C.The kubelet on the controller node is down

D.The scheduler is overloading the API server

AnswerA

The controller-manager cannot connect to the API server.

Why this answer

The controller-manager communicates with the API server. 'connection refused' indicates the API server is not reachable or not running.

Full explanation →

754

Multi-Selectmedium

A pod is stuck in Pending state. Which TWO of the following could be causes? (Select 2)

Select 2 answers

A.The pod's container image is invalid

B.The kube-apiserver is down

C.The pod has a taint that no node tolerates

D.The pod requires a PersistentVolumeClaim that is not bound

E.The cluster has no nodes with enough CPU or memory to schedule the pod

AnswersD, E

If a PVC is not bound, the pod cannot start.

Why this answer

Pending pods often lack resources or have unscheduled taints. PVC binding is also a common cause.

Full explanation →

755

MCQhard

You have an Ingress resource with TLS configured. You verify that the TLS secret exists in the same namespace. However, accessing the service via HTTPS returns a certificate error. What is the most likely cause?

A.The TLS secret name in the Ingress spec does not match the actual secret name.

B.The TLS secret's certificate does not match the hostname used in the Ingress rule.

C.The Ingress controller must be configured with the --default-ssl-certificate flag.

D.The certificate in the TLS secret is self-signed, not signed by a trusted CA.

AnswerD

Self-signed certificates cause browser warnings. The certificate should be from a trusted CA.

Why this answer

Option C is correct. The Ingress controller's default certificate is often self-signed. The TLS secret must contain a certificate signed by a trusted CA for browsers to trust.

Option A is false: if the secret doesn't exist, the Ingress controller would report an error or use its default. Option B is not required. Option D is about the certificate's CN/SAN, not the CA.

Full explanation →

756

MCQeasy

You run 'kubectl get events --sort-by='.lastTimestamp'' and see repeated events: 'Failed to pull image "myimage:v2": rpc error: code = Unknown desc = Error response from daemon: manifest for myimage:v2 not found'. What is the issue?

A.The pod has insufficient privileges to pull the image.

B.The image registry is down.

C.The container runtime is not running.

D.The image tag 'myimage:v2' does not exist in the registry.

AnswerD

The error clearly states the manifest is not found for that tag.

Why this answer

The error 'manifest not found' means the image tag does not exist in the registry. The pod is in ImagePullBackOff because the image is missing.

Full explanation →

757

MCQeasy

Which command shows resource usage for pods and nodes in the cluster?

A.kubectl top pods and kubectl top nodes

B.kubectl cluster-info

C.kubectl get --sort-by=.status.capacity

D.kubectl describe pods and kubectl describe nodes

AnswerA

These are the correct commands for resource usage.

Why this answer

The metrics server must be installed. 'kubectl top pods' shows pod CPU/memory usage, and 'kubectl top nodes' shows node usage.

Full explanation →

758

Drag & Dropmedium

Drag and drop the steps to back up and restore etcd data for a Kubernetes cluster into the correct order.

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

Steps

Order

Why this order

First snapshot, verify, stop etcd, restore, then start and check health.

Full explanation →

759

MCQeasy

Which kubectl command is used to mark a node as unschedulable so that no new pods are scheduled onto it?

A.kubectl taint <node>

B.kubectl uncordon <node>

C.kubectl drain <node>

D.kubectl cordon <node>

AnswerD

Cordon marks the node as unschedulable, preventing new pods from being scheduled.

Why this answer

The `kubectl cordon <node>` command marks a node as unschedulable by setting the `node.Spec.Unschedulable` field to `true`. This prevents the Kubernetes scheduler from placing any new pods onto that node, while existing pods continue to run unaffected. This is the correct command for the described task.

Exam trap

The trap here is confusing `cordon` with `drain`—candidates often pick `drain` because they think it makes the node unschedulable, but `drain` additionally evicts all pods, which is not what the question asks for.

How to eliminate wrong answers

Option A is wrong because `kubectl taint <node>` adds a taint to a node, which repels pods that do not have a matching toleration, but it does not directly make the node unschedulable for all new pods—pods with appropriate tolerations can still be scheduled. Option B is wrong because `kubectl uncordon <node>` does the opposite: it marks a node as schedulable by setting `node.Spec.Unschedulable` to `false`, allowing new pods to be scheduled. Option C is wrong because `kubectl drain <node>` evicts all pods from the node and then cordons it, but the primary action is pod eviction, not merely marking the node unschedulable; it is a more destructive operation that also terminates running workloads.

Full explanation →

760

MCQmedium

A cluster was installed using kubeadm. You need to upgrade the cluster from v1.28 to v1.29. Which of the following is the correct order of operations?

A.Drain each node, upgrade control plane, then upgrade worker nodes

B.Drain control plane node, upgrade kubeadm and kubelet on control plane, uncordon, then repeat for worker nodes

C.Upgrade worker nodes first, then control plane nodes

D.Upgrade all nodes simultaneously

AnswerB

Correct sequence: drain control plane, upgrade, uncordon, then similarly for workers.

Why this answer

Option B is correct because the kubeadm upgrade process requires the control plane node to be upgraded first, as it hosts the core cluster components (API server, scheduler, controller-manager). Draining the node ensures workloads are evicted, then kubeadm and kubelet are upgraded on the control plane, followed by uncordoning. Worker nodes are upgraded afterward to maintain cluster stability and compatibility.

Exam trap

The trap here is that candidates often assume all nodes can be upgraded in any order or simultaneously, but the CKA requires strict sequential upgrade of control plane first, then workers, with drain/uncordon steps.

How to eliminate wrong answers

Option A is wrong because it suggests draining all nodes before upgrading, but the control plane must be upgraded first, not simultaneously with workers. Option C is wrong because upgrading worker nodes before the control plane would break cluster coordination, as the API server version must be higher or equal to kubelet versions. Option D is wrong because upgrading all nodes simultaneously is not supported with kubeadm; it would cause version mismatches and potential cluster downtime.

Full explanation →

761

MCQmedium

A developer wants to create a ServiceAccount named 'app-sa' and mount its token into a pod. Which YAML snippet correctly configures the pod to use this ServiceAccount?

A.spec: serviceAccountName: app-sa automountServiceAccountToken: false

B.spec: serviceAccountName: app-sa automountServiceAccountToken: "true"

C.spec: serviceAccountName: app-sa automountServiceAccountToken: true

D.spec: serviceAccount: app-sa

AnswerC

Correct: serviceAccountName and automountServiceAccountToken true (default).

Why this answer

Option C is correct because it uses the `serviceAccountName` field to assign the 'app-sa' ServiceAccount to the pod and sets `automountServiceAccountToken: true` to explicitly mount the token. By default, Kubernetes mounts the token if `automountServiceAccountToken` is not set, but setting it to `true` ensures the token is mounted even if the ServiceAccount itself has `automountServiceAccountToken: false`.

Exam trap

The trap here is that candidates confuse the deprecated `serviceAccount` field with the correct `serviceAccountName` field, or incorrectly use a string value for `automountServiceAccountToken` instead of a boolean, leading to silent failures or unexpected behavior.

How to eliminate wrong answers

Option A is wrong because `automountServiceAccountToken: false` explicitly disables token mounting, which contradicts the requirement to mount the token. Option B is wrong because `automountServiceAccountToken: "true"` uses a string value instead of the required boolean; Kubernetes expects a boolean, and a string may be ignored or cause an error. Option D is wrong because it uses the deprecated `serviceAccount` field instead of `serviceAccountName`; while it might work in older versions, it is not the correct modern syntax and does not include the `automountServiceAccountToken` field.

Full explanation →

762

MCQmedium

You have a Deployment with 3 replicas. After updating the container image, the new pods are in 'ImagePullBackOff' state. You run 'kubectl describe pod <pod-name>' and see the event: 'Failed to pull image "myregistry/myapp:latest": rpc error: code = Unknown desc = Error response from daemon: manifest for myregistry/myapp:latest not found: manifest unknown: manifest unknown'. What is the MOST likely cause?

A.The registry is unreachable from the nodes

B.The image tag 'latest' does not exist in the registry

C.The registry requires authentication and the pod does not have an imagePullSecret

D.The container runtime is out of disk space

AnswerB

The error message 'manifest for myregistry/myapp:latest not found' indicates that the tag does not exist. The image may not have been pushed with that tag.

Why this answer

Option A is correct. The error message explicitly states the manifest for the tag ':latest' is not found. This typically happens when the tag does not exist in the registry.

Option B would result in a different error (authentication failure). Option C would show a different error (connection timeout or refused). Option D would result in a different error (network timeout).

Full explanation →

763

MCQeasy

Which command can be used to view resource usage of nodes in a cluster?

A.kubectl describe nodes

B.kubectl top pods

C.kubectl get pods --show-resources

D.kubectl top nodes

AnswerD

This command displays resource usage (CPU and memory) for all nodes in the cluster.

Why this answer

Option A is correct. 'kubectl top nodes' shows CPU and memory usage of nodes, provided the metrics server is installed. Option B shows pod resource usage. Option C is a non-existent command.

Option D shows only pods, not nodes.

Full explanation →

764

MCQmedium

You run 'kubectl get pods -n default' and see a pod named 'backend' in ImagePullBackOff state. What is the most likely cause?

A.The image name or tag is incorrect

B.The node is out of disk space

C.The container's memory limit is too low

D.The pod's service account lacks permissions

AnswerA

A typo in the image name or an invalid tag causes pull failure.

Why this answer

ImagePullBackOff indicates Kubernetes cannot pull the container image, often due to a tag typo or non-existent image.

Full explanation →

765

MCQeasy

Which command would you use to view all events in the cluster sorted by timestamp?

A.kubectl top events

B.kubectl logs --events

C.kubectl describe events

D.kubectl get events

AnswerD

Shows all events in the cluster sorted by last timestamp.

Why this answer

Option D is correct because `kubectl get events` retrieves all cluster events, which are Kubernetes API objects that record state changes and errors. By default, events are sorted by their `lastTimestamp` field, making this the direct command to view events ordered by timestamp.

Exam trap

The trap here is that candidates confuse `kubectl get events` with `kubectl describe events` or assume `kubectl top` or `kubectl logs` can retrieve events, but only `kubectl get events` provides a sorted list of all cluster events by timestamp.

How to eliminate wrong answers

Option A is wrong because `kubectl top events` is not a valid kubectl command; `kubectl top` is used for resource usage metrics (e.g., `kubectl top node`), not events. Option B is wrong because `kubectl logs --events` is invalid; `kubectl logs` retrieves container logs, not cluster events, and the `--events` flag does not exist for this command. Option C is wrong because `kubectl describe events` is not a valid subcommand; `kubectl describe` works on resource types like `events` (e.g., `kubectl describe events`), but it shows details of a specific event or a filtered set, not a sorted list of all events.

Full explanation →

766

MCQmedium

A ClusterRole named 'pod-reader' grants get, list, watch on pods. You want to bind it to a user 'john' cluster-wide. Which resource should you create?

A.Role

B.ClusterRoleBinding

C.RoleBinding in default namespace

D.ClusterRole

AnswerB

Correct for cluster-wide binding.

Why this answer

A ClusterRoleBinding is the correct resource because it grants cluster-wide permissions to a user. While a ClusterRole defines the permissions (get, list, watch on pods), a ClusterRoleBinding binds that ClusterRole to a subject (user 'john') across all namespaces. This is the only way to achieve cluster-scoped authorization in Kubernetes RBAC.

Exam trap

The trap here is that candidates often confuse ClusterRole (which defines permissions) with ClusterRoleBinding (which binds them to a user), or mistakenly think a RoleBinding can grant cluster-wide access if used with a ClusterRole.

How to eliminate wrong answers

Option A is wrong because a Role is a namespaced resource that grants permissions only within a specific namespace, not cluster-wide. Option C is wrong because a RoleBinding in the default namespace would only grant the permissions within that namespace, not across the entire cluster. Option D is wrong because a ClusterRole only defines the permissions (rules) but does not bind them to a user; a binding resource (ClusterRoleBinding) is required to associate the ClusterRole with a subject.

Full explanation →

767

MCQeasy

An administrator creates a NetworkPolicy in namespace 'app' with the following YAML. Which statement is true about the policy? apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress

A.The policy denies all ingress traffic to no pods because no podSelector is specified.

B.The policy denies all egress traffic from all pods in the 'app' namespace.

C.The policy denies all ingress traffic to all pods in the 'app' namespace.

D.The policy allows all ingress traffic to all pods in the 'app' namespace.

AnswerC

An empty podSelector selects all pods, and with no ingress rules, all ingress is denied.

Why this answer

A NetworkPolicy with an empty podSelector selects all pods in the namespace. When policyTypes includes Ingress and no ingress rules are specified, it defaults to denying all ingress traffic to selected pods. Option A is correct.

Option B is wrong because an empty podSelector selects all pods. Option C is wrong because egress is not specified. Option D is wrong because the policy does not allow traffic.

Full explanation →

768

MCQeasy

A developer wants to deploy a pod that will run only once to initialize a database schema. Which Kubernetes resource should they use?

A.DaemonSet

B.Job

C.Deployment

D.CronJob

AnswerB

Job runs a pod to successful completion.

Why this answer

A Job is the correct Kubernetes resource for a one-time task that runs to completion, such as initializing a database schema. Unlike controllers that maintain a desired number of replicas, a Job creates one or more Pods and ensures they successfully terminate, making it ideal for batch or initialization workloads.

Exam trap

The trap here is that candidates often confuse a Job with a CronJob, thinking they need scheduling, or with a Deployment, assuming all workloads must be continuously running, when the key differentiator is the 'run to completion' lifecycle.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, which is designed for continuous daemon processes like logging or monitoring, not a one-time initialization task. Option C is wrong because a Deployment manages a set of Pods to maintain a desired state with rolling updates and self-healing, intended for long-running stateless applications, not a single run-to-completion job. Option D is wrong because a CronJob is used for scheduling Jobs to run at specific times or intervals, which is overkill and incorrect for a task that should run only once immediately.

Full explanation →

769

MCQmedium

A Pod in a Deployment is CrashLoopBackOff. 'kubectl logs' shows the application exits with code 1 after printing one line. The Pod has a liveness probe that checks an HTTP endpoint. What should be checked first?

A.Check the application logs and configuration that causes the exit code 1.

B.Check if the liveness probe's initialDelaySeconds is too short.

C.Check if the liveness probe endpoint is correctly configured.

D.Check if the container has insufficient memory limits.

AnswerA

The application is crashing due to its own logic; logs should indicate the error.

Why this answer

The application exits with code 1 after printing one line, which indicates a runtime error in the application itself. The liveness probe only restarts the container after the application has already failed; it does not prevent the initial crash. Therefore, the first step is to examine the application logs and configuration to understand why the process exits with code 1, as this is the root cause of the CrashLoopBackOff.

Exam trap

The trap here is that candidates often focus on the liveness probe configuration (options B and C) because the question mentions it, but the immediate cause is the application crash itself, which must be diagnosed first via logs.

How to eliminate wrong answers

Option B is wrong because adjusting initialDelaySeconds would only delay the start of liveness checks; it does not address the application exiting with code 1. Option C is wrong because the liveness probe endpoint configuration is irrelevant when the application crashes before the probe can even be evaluated. Option D is wrong because insufficient memory limits typically cause OOMKilled (exit code 137) or resource pressure, not a clean exit code 1 after printing one line.

Full explanation →

770

MCQeasy

Which command is used to take a snapshot of etcd data for backup?

A.etcdctl export

B.etcdctl backup

C.etcdctl dump

D.etcdctl snapshot save

AnswerD

This command creates a snapshot file of the etcd data store.

Why this answer

The correct command to take a snapshot of etcd data for backup is `etcdctl snapshot save`. This command creates a point-in-time snapshot of the etcd key-value store, which can be used to restore the cluster state. The `snapshot save` subcommand is the official method for backing up etcd data in Kubernetes environments.

Exam trap

The trap here is that candidates may confuse `etcdctl backup` (a legacy v2 command) or `etcdctl dump` (a non-existent command) with the correct `etcdctl snapshot save`, especially since the word 'backup' is intuitive but not the actual command in etcd v3.

How to eliminate wrong answers

Option A is wrong because `etcdctl export` is not a valid subcommand; the correct subcommand for exporting data is `etcdctl get` with a prefix, but that does not create a consistent snapshot. Option B is wrong because `etcdctl backup` is not a valid subcommand; the legacy `etcdctl backup` was used in older etcd v2 but is deprecated and not available in etcd v3, which is the standard for Kubernetes. Option C is wrong because `etcdctl dump` is not a valid subcommand; there is no `dump` command in etcdctl, and it likely confuses with database dump tools.

Full explanation →

771

MCQeasy

Which component is responsible for maintaining network rules on worker nodes?

A.kube-proxy

B.kube-scheduler

C.kubelet

D.kube-controller-manager

AnswerA

kube-proxy maintains network rules.

Why this answer

kube-proxy is the component responsible for maintaining network rules on worker nodes. It watches the Kubernetes API server for changes to Services and EndpointSlices, then updates iptables, IPVS, or userspace rules on the node to route traffic to the correct Pods. This ensures that network traffic directed at a Service's ClusterIP or NodePort is properly forwarded to the backend Pods.

Exam trap

The trap here is that candidates often confuse kubelet with kube-proxy because both run on worker nodes, but kubelet manages containers while kube-proxy manages network rules.

How to eliminate wrong answers

Option B (kube-scheduler) is wrong because it is responsible for assigning Pods to nodes based on resource availability and scheduling policies, not for maintaining network rules. Option C (kubelet) is wrong because it is the primary node agent that manages Pod lifecycle, container health, and mounts volumes, but it does not handle network rule enforcement. Option D (kube-controller-manager) is wrong because it runs controller processes such as the Node Controller, Replication Controller, and Endpoint Controller, but it does not implement per-node network rules.

Full explanation →

772

MCQhard

You need to update a Deployment's image from nginx:1.20 to nginx:1.21 using a rolling update strategy, but you want to ensure that during the update, at most 2 pods above the desired replicas (10) are running, and at least 8 pods are available at all times. Which strategy configuration should you apply?

A.maxSurge: 3, maxUnavailable: 2

B.maxSurge: 3, maxUnavailable: 3

C.maxSurge: 2, maxUnavailable: 2

D.maxSurge: '20%', maxUnavailable: '20%'

AnswerC

maxSurge=2 allows at most 12 pods (10+2). maxUnavailable=2 ensures at least 8 pods are available (10-2).

Why this answer

Option C is correct because it sets maxSurge=2 and maxUnavailable=2, which ensures that during the rolling update, at most 2 extra pods can be created above the desired 10 (so maximum 12 pods running), and at least 8 pods (desired 10 minus maxUnavailable 2) are always available. This satisfies the requirement of at most 2 pods above desired replicas and at least 8 available at all times.

Exam trap

The trap here is that candidates often confuse maxSurge and maxUnavailable with the total number of pods allowed to be unavailable or created, leading them to pick options that either allow too many extra pods (A, B) or too few available pods (B), or they incorrectly assume percentage-based values (D) are always safer without checking the exact integer equivalent.

How to eliminate wrong answers

Option A is wrong because maxSurge=3 allows up to 3 extra pods above the desired 10, violating the 'at most 2 pods above desired replicas' constraint. Option B is wrong because maxSurge=3 again exceeds the limit of 2 extra pods, and maxUnavailable=3 would allow only 7 pods available, violating the 'at least 8 pods available' requirement. Option D is wrong because 20% of 10 is 2, so maxSurge=20% and maxUnavailable=20% would behave identically to Option C in this case, but the question asks for a specific configuration and the percentage values are not explicitly calculated; however, the correct answer is Option C as the direct integer values match the requirements exactly, and Option D could be misinterpreted if the percentage calculation is not understood, but it is technically equivalent; the trap is that candidates might choose D thinking percentages are safer, but the question expects the explicit integer configuration.

Full explanation →

773

MCQmedium

You run 'kubectl top nodes' and get an error: 'error: metrics not available yet'. What is the most likely cause?

A.The nodes do not have enough resources to run the metrics collection

B.You do not have permission to view node metrics

C.The kubelet is not running on the nodes

D.The metrics-server is not installed or not running

AnswerD

The metrics server provides the data for kubectl top.

Why this answer

The metrics server is not deployed or not ready; kubectl top requires the metrics server to collect resource usage data.

Full explanation →

774

MCQmedium

A Pod is stuck in CrashLoopBackOff. You run `kubectl logs <pod-name>` but see no output. What is the most likely cause?

A.The pod has no container defined.

B.The container crashes before writing to stdout/stderr.

C.The kubelet is not forwarding logs.

D.The pod is in a different namespace.

AnswerB

Why this answer

When a container crashes before it can write any output to stdout or stderr, `kubectl logs` returns no output because there is no log data to retrieve. This is a common symptom of a container that fails during initialization or immediately upon entry point execution, before any logging occurs.

Exam trap

The trap here is that candidates may assume empty logs indicate a logging infrastructure issue (like kubelet failure) rather than recognizing that the container simply never produced any output before crashing.

Why the other options are wrong

A pod must have at least one container; if not, it wouldn't be scheduled.

The kubelet forwards logs from the container runtime; if logs exist, they should appear.

kubectl logs defaults to the default namespace; if the pod is in another namespace, you'd get an error, not empty output.

Full explanation →

775

MCQhard

You are debugging a CrashLoopBackOff. The pod YAML includes the following container spec: ```yaml containers: - name: app image: myapp:1.0 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 3 periodSeconds: 3 ``` The application starts successfully but crashes after about 10 seconds. What is the most likely cause?

A.The container image myapp:1.0 does not exist

B.The application's health endpoint /healthz is not responding with HTTP 200

C.The liveness probe is too aggressive, causing the container to be killed before it fully initializes

D.The pod is running out of memory

AnswerB

If the health endpoint does not return a success status, the liveness probe fails and kills the container, causing a restart.

Why this answer

Option B is correct. The liveness probe is failing, causing the container to be killed and restarted. The app starts but then the probe fails after a few seconds.

Options A, C, and D are inconsistent with the scenario.

Full explanation →

776

MCQeasy

You need to check the logs of a kubelet on a node. Which command should you run on the node?

A.journalctl -u docker

B.dmesg

C.tail -f /var/log/apache2/access.log

D.journalctl -u kubelet

AnswerD

This command shows logs from the kubelet service.

Why this answer

Option A is correct. 'journalctl -u kubelet' is the standard command to view kubelet logs on systemd-based systems. Option B is for Docker daemon. Option C is for kernel messages.

Option D is for Apache access logs.

Full explanation →

777

MCQmedium

You run 'kubectl get pods' and see some pods in 'ImagePullBackOff' state. Which command would best help identify the root cause?

A.kubectl logs <pod-name>

B.kubectl describe pod <pod-name>

C.kubectl get events --field-selector involvedObject.kind=Pod

D.kubectl exec <pod-name> -- cat /var/log/containers

AnswerB

Why this answer

Option B is correct because `kubectl describe pod <pod-name>` provides detailed information about the pod, including the status of its containers, events, and error messages from the kubelet. For an `ImagePullBackOff` state, the `describe` output will show the exact reason for the image pull failure (e.g., invalid image name, registry authentication failure, or network issues) in the `Status` and `Events` sections, making it the most direct troubleshooting command.

Exam trap

CNCF often tests the misconception that `kubectl logs` can retrieve startup errors, but in `ImagePullBackOff`, the container never runs, so logs are unavailable and `describe pod` is the correct tool to inspect the kubelet's event stream and container status.

Why the other options are wrong

The pod has not started, so there are no logs.

This would show events but not as detailed as describe pod; still acceptable but less direct.

Pod is not running; exec fails.

Full explanation →

778

MCQeasy

Which command is used to mark a node as unschedulable and evict its pods?

A.kubectl delete node node-name

B.kubectl cordon node-name

C.kubectl drain node-name --ignore-daemonsets

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

AnswerC

Drain cordons and evicts all pods (except DaemonSets with flag).

Why this answer

Option C is correct because `kubectl drain` marks a node as unschedulable (similar to `cordon`) and then evicts all pods from the node, respecting PodDisruptionBudgets. The `--ignore-daemonsets` flag is required because DaemonSet pods cannot be evicted via drain (they are managed by the DaemonSet controller and would be immediately rescheduled on the same node), so the command would fail without this flag.

Exam trap

CNCF often tests the distinction between `cordon` (only prevents scheduling) and `drain` (prevents scheduling AND evicts pods), and candidates frequently pick `cordon` because they forget that eviction is required for the node to be truly empty for maintenance.

How to eliminate wrong answers

Option A is wrong because `kubectl delete node` removes the node object from the cluster entirely, which does not evict pods gracefully and is not the intended way to perform maintenance. Option B is wrong because `kubectl cordon` only marks the node as unschedulable (prevents new pods from being scheduled) but does not evict existing pods. Option D is wrong because `kubectl taint` with `NoSchedule` prevents new pods from being scheduled on the node but does not evict existing pods; it also does not mark the node as unschedulable in the same way as `cordon` or `drain`.

Full explanation →

779

MCQmedium

A cluster administrator has configured a PodSecurityPolicy (PSP) that requires all pods to run with read-only root filesystem. However, a newly deployed pod is failing to start with the error 'container has runAsNonRoot and image will run as root'. The PSP is designed to prevent running as root. What is the most likely cause?

A.The PodSecurityPolicy admission controller is not enabled.

B.The PSP is not set to enforce read-only root filesystem.

C.The container image is configured to run as root user.

D.The PSP is not being applied to the pod's service account.

AnswerC

The PSP requires runAsNonRoot, but the image runs as root.

Why this answer

The error message 'container has runAsNonRoot and image will run as root' indicates that the PodSecurityPolicy (PSP) is configured with `runAsNonRoot: true`, but the container image itself is built to run as the root user (UID 0). The PSP enforces that the container must not run as root, but the image's default user is root, causing the admission controller to reject the pod. Option C correctly identifies this mismatch as the most likely cause.

Exam trap

The trap here is that candidates confuse the 'read-only root filesystem' constraint with the 'runAsNonRoot' constraint, or assume the error is about PSP not being applied, when in fact the error message directly points to the image running as root despite the PSP requiring non-root execution.

How to eliminate wrong answers

Option A is wrong because if the PodSecurityPolicy admission controller were not enabled, the PSP would not be enforced at all, and the pod would start without the error (the error specifically comes from PSP enforcement). Option B is wrong because the error message is about runAsNonRoot, not read-only root filesystem; the read-only root filesystem setting is a separate PSP constraint that would produce a different error (e.g., 'read-only root filesystem' violation). Option D is wrong because PSPs are applied based on the pod's service account only when the PSP has a `spec.runAsUser.rule` or similar that references the service account; the error here is a direct conflict between the image's user and the `runAsNonRoot` setting, not a missing binding.

Full explanation →

780

MCQhard

You need to allow a pod to use a specific device from the host node (e.g., /dev/sdb) as a raw block device. Which volume mode should you set in the PVC?

A.Device

B.Raw

C.Block

D.Filesystem

AnswerC

Block mode presents the volume as a raw block device.

Why this answer

To use a raw block device, the volume mode must be 'Block'. The default is 'Filesystem'.

Full explanation →

781

Multi-Selectmedium

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

Select 2 answers

A.The pod's liveness probe is failing

B.The container image is invalid

C.A PersistentVolumeClaim used by the pod is not bound

D.Insufficient CPU or memory resources on nodes

E.The pod's readiness probe is failing

AnswersC, D

If PVC is not bound, pod remains Pending.

Why this answer

Pending means pod cannot be scheduled. Resource constraints and PVC not bound are common causes.

Full explanation →

782

MCQhard

You want to check the current resource usage (CPU and memory) of pods in the 'default' namespace. Which kubectl command should you use?

A.kubectl get pods -o wide

B.kubectl top pods

C.kubectl logs pods

D.kubectl describe pods

AnswerB

'kubectl top pods' displays CPU and memory usage of pods, provided the metrics server is deployed.

Why this answer

'kubectl top pods' requires the metrics server to be installed and shows current resource usage.

Full explanation →

783

MCQmedium

You create a Deployment with replicas=3 and a Service of type ClusterIP. You notice that traffic to the Service is not evenly distributed. What is the most likely cause?

A.kube-proxy is running in iptables mode

B.kube-proxy is running in ipvs mode

C.The Service has sessionAffinity set to ClientIP

D.The pods have different resource limits

AnswerA

iptables mode uses random selection, which can cause uneven distribution.

Why this answer

kube-proxy by default uses iptables mode, which uses random selection (not round-robin). This can lead to uneven distribution, especially with low traffic. ipvs mode supports more scheduling algorithms like round-robin.

Full explanation →

784

MCQeasy

You are setting up a new Kubernetes cluster using kubeadm. After running 'kubeadm init', you want to start using the cluster with kubectl. Which of the following commands should you run to configure kubectl for the admin user?

A.mkdir -p $HOME/.kube && sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config && sudo chown $(id -u):$(id -g) $HOME/.kube/config

B.sudo kubeadm reset --force

C.sudo cp /etc/kubernetes/admin.conf /root/.kube/config

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

AnswerA

This copies the admin kubeconfig to the user's kubeconfig directory and sets appropriate ownership.

Why this answer

Option A is correct because after running 'kubeadm init', the admin kubeconfig file is generated at /etc/kubernetes/admin.conf. To use kubectl as a regular (non-root) user, you must copy this file to the user's $HOME/.kube/config directory and then change its ownership to the current user. This ensures kubectl can authenticate to the cluster using the admin certificate and key embedded in the config file.

Exam trap

The trap here is that candidates might mistakenly copy the admin.conf to /root/.kube/config (option C) thinking it works for any user, or confuse the admin.conf location with the pki directory (option D), while the correct approach requires copying to the current user's home directory and fixing ownership.

How to eliminate wrong answers

Option B is wrong because 'kubeadm reset --force' is used to tear down a cluster or reinitialize it, not to configure kubectl; running it would destroy the cluster state. Option C is wrong because it copies the admin.conf to /root/.kube/config, which only configures kubectl for the root user, not for the current admin user; the CKA environment typically expects non-root usage. Option D is wrong because it references /etc/kubernetes/pki/admin.conf, which does not exist — the admin kubeconfig is located at /etc/kubernetes/admin.conf, not in the pki directory.

Full explanation →

785

MCQhard

You have three pods selected by a service. One pod is in 'CrashLoopBackOff' state. How does the service's endpoints behave?

A.The service removes all endpoints to avoid partial connectivity

B.The service endpoints include only the two healthy pods

C.The service endpoints include the unhealthy pod but traffic is not routed to it

D.The service includes all three pods in its endpoints

AnswerB

Endpoints contain only ready pods.

Why this answer

Services use endpoints that include only ready pods. A pod in CrashLoopBackOff is not ready (readiness probe fails), so it is removed from endpoints. Option C is correct.

Option A is wrong because the endpoint is updated. Option B is wrong because not all pods are removed. Option D is wrong because endpoints do not include unhealthy pods.

Full explanation →

786

MCQeasy

Which component is responsible for assigning pods to nodes?

A.kube-scheduler

B.kubelet

C.kube-apiserver

D.kube-controller-manager

AnswerA

The scheduler selects a node for each pod based on resource availability and policies.

Why this answer

The kube-scheduler is responsible for assigning pods to nodes based on resource requirements, constraints, and policies. It watches for newly created pods that have no node assignment and selects an optimal node for each pod to run on.

Exam trap

The trap here is that candidates often confuse the kubelet's role of running pods with the scheduler's role of assigning pods to nodes, or think the API server handles scheduling because it processes pod creation requests.

How to eliminate wrong answers

Option B is wrong because kubelet is the agent that runs on each node and ensures containers are running in a pod, but it does not decide which node a pod should be scheduled on. Option C is wrong because kube-apiserver is the front-end for the Kubernetes control plane and handles API requests, but it does not perform scheduling decisions. Option D is wrong because kube-controller-manager runs controller processes like replication controller and node controller, but pod-to-node assignment is the scheduler's responsibility.

Full explanation →

787

Multi-Selectmedium

Which TWO are true about taints and tolerations? (Select 2)

Select 2 answers

A.Taints prevent all pods from scheduling on a node

B.A node can have multiple taints

C.Taints are applied to pods

D.Tolerations are set on nodes

E.Tolerations allow pods to schedule on tainted nodes

AnswersB, E

Yes.

Why this answer

Option B is correct because a node can indeed have multiple taints applied to it, each with different effects (NoSchedule, PreferNoSchedule, or NoExecute). This allows fine-grained control over pod placement, such as dedicating nodes for specific workloads or isolating sensitive pods. Option E is correct because tolerations are applied to pods and allow them to be scheduled on nodes that have matching taints, effectively overriding the taint's restriction.

Exam trap

The trap here is that candidates often confuse which object (node vs. pod) receives taints versus tolerations, leading them to incorrectly select options C or D.

Full explanation →

788

MCQeasy

Which command retrieves logs from a container that has crashed and restarted?

A.kubectl describe pod pod-name

B.kubectl logs pod-name --previous

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

D.kubectl logs pod-name --tail=100

AnswerB

Why this answer

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

Full explanation →

789

MCQmedium

A cluster administrator creates a StorageClass with the following YAML: apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast provisioner: kubernetes.io/aws-ebs parameters: type: gp2 reclaimPolicy: Delete volumeBindingMode: Immediate A developer creates a PVC using this StorageClass. The PVC is created and remains in Pending state. What is the most likely cause?

A.The volumeBindingMode is Immediate, which requires a different access mode.

B.The cluster is not running on AWS or the AWS cloud provider is not configured.

C.The PVC does not specify an access mode.

D.The reclaim policy is Delete, which prevents binding.

AnswerB

The kubernetes.io/aws-ebs provisioner only works on AWS clusters with proper cloud provider setup. Without AWS, provisioning fails and PVC remains Pending.

Why this answer

The StorageClass uses 'kubernetes.io/aws-ebs' provisioner, which requires AWS cloud provider configuration. If the cluster is not running on AWS or the AWS cloud provider is not properly configured, the dynamic provisioning will fail, leaving the PVC in Pending state. Other options are less likely: the PVC might have matching access modes, and volumeBindingMode Immediate means it should provision immediately.

Full explanation →

790

Multi-Selecthard

A pod is in 'CrashLoopBackOff' state. Which THREE of the following are possible causes?

Select 3 answers

A.The container's startup command has invalid arguments

B.The container image does not exist

C.The application tries to bind to a port that is already in use

D.The PersistentVolumeClaim is not bound

E.A required environment variable is not set

AnswersA, C, E

Invalid arguments cause the container to exit with non-zero code and restart.

Why this answer

Missing environment variables, invalid command arguments, and failure to bind to a port are common causes of container crashes. Option D (PVC not bound) causes Pending, not CrashLoopBackOff. Option E (image pull error) causes ImagePullBackOff.

Full explanation →

791

MCQhard

After applying this NetworkPolicy, a pod in the default namespace tries to curl an external website (e.g., google.com) and fails. What is the reason?

A.The Egress rule is defined but has no allow rules, so all egress is denied.

B.The Ingress rule blocks all incoming traffic, preventing DNS responses.

C.The policy is applied to all namespaces, causing a conflict.

D.The policy only applies to pods with specific labels.

AnswerA

With policyTypes including Egress and no egress rules, all egress is denied.

Why this answer

Option A is correct because the NetworkPolicy defines an Egress rule with an empty `rules` array, which means no egress traffic is explicitly allowed. In Kubernetes, when a NetworkPolicy selects a pod, it defaults to denying all traffic of the specified direction unless explicitly allowed. Since the Egress rule has no allow rules, all outbound traffic from the selected pods, including HTTP/HTTPS requests to external websites like google.com, is blocked by the policy.

Exam trap

The trap here is that candidates often assume an empty Egress rule means 'allow all egress' or that the policy only restricts ingress, but Kubernetes NetworkPolicy defaults to deny for the specified direction when any rule of that type is present.

How to eliminate wrong answers

Option B is wrong because the Ingress rule blocks incoming traffic, but the pod's failure to curl an external website is an egress issue, not an ingress issue; DNS responses are UDP-based and would be blocked only if the Egress rule also denies DNS traffic, but the core problem is the missing egress allow rules. Option C is wrong because NetworkPolicies are namespace-scoped resources, not cluster-scoped; they apply only to pods in the namespace where they are created, and there is no conflict unless multiple policies with contradictory rules exist in the same namespace. Option D is wrong because the question states the policy is applied to a pod in the default namespace, and the policy's podSelector likely matches that pod; if it didn't, the pod would not be affected at all, and the curl would succeed, not fail.

Full explanation →

792

MCQmedium

A Deployment has replicas=3 and uses RollingUpdate with maxSurge=1 and maxUnavailable=1. During an update, one new Pod is created, and one old Pod is terminated. What is the total number of Pods during the update?

A.Between 2 and 3

B.Exactly 4

C.Between 2 and 4

D.Always 3

AnswerC

Correct range due to surge and unavailable.

Why this answer

During a RollingUpdate, the total number of Pods can vary between the desired replicas (3) and the desired replicas plus maxSurge (1), i.e., up to 4. With maxUnavailable=1, at least 2 Pods must be available. The update creates one new Pod before terminating one old Pod, so the total Pod count can be 3 (if the old Pod is terminated before the new one is ready) or 4 (if the new Pod is created before the old one is terminated).

Thus, the range is between 2 and 4.

Exam trap

The trap here is that candidates often assume the total Pod count remains constant at the desired replicas, ignoring that maxSurge allows temporary overshoot, leading them to pick 'Always 3' or 'Exactly 4' instead of the correct range.

How to eliminate wrong answers

Option A is wrong because the total number of Pods can be 4, not just between 2 and 3. Option B is wrong because the total number of Pods is not always exactly 4; it can be 3 or 4 depending on the order of creation and termination. Option D is wrong because the total number of Pods is not always 3; it can temporarily be 4 due to maxSurge=1.

Full explanation →

793

MCQmedium

A developer wants to run a one-time batch job that processes data and then exits. Which Kubernetes resource should be used?

A.DaemonSet

B.CronJob

C.Deployment

D.Job

AnswerD

Jobs run a pod until successful completion.

Why this answer

A Job is the correct Kubernetes resource for a one-time batch task that runs to completion and then exits. It ensures a specified number of Pods terminate successfully, making it ideal for processing data and exiting without requiring continuous availability.

Exam trap

The trap here is that candidates often confuse a CronJob with a Job, assuming any batch-like task requires scheduling, but the question explicitly says 'one-time,' which eliminates the need for a schedule.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on all (or a subset of) nodes, providing continuous background services like logging or monitoring, not a one-time batch job. Option B is wrong because a CronJob is used for scheduling recurring tasks at specified times (e.g., every hour), not for a single execution. Option C is wrong because a Deployment manages a set of replica Pods intended to run indefinitely, maintaining a desired state with rolling updates, not a finite task that exits.

Full explanation →

794

MCQmedium

You want to dynamically provision storage for a PVC using a StorageClass named 'fast-ssd'. Which field in the PVC YAML specifies the StorageClass?

A.class

B.storageClass

C.className

D.storageClassName

AnswerD

Correct field name.

Why this answer

The field 'storageClassName' under the PVC spec specifies which StorageClass to use for dynamic provisioning.

Full explanation →

795

MCQmedium

You have a Deployment that runs a batch job. The job should run on a node that has a specific custom resource (e.g., a license dongle). Which approach should you use?

A.Use node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule

B.Define a nodeSelector in the pod spec

C.Assign the pod a high priority so it gets scheduled on any node

D.Use pod anti-affinity to avoid nodes without the resource

AnswerA

This guarantees the pod is scheduled only on nodes matching the label.

Why this answer

Node affinity with a `requiredDuringSchedulingIgnoredDuringExecution` rule is the correct approach because it allows you to schedule the pod exclusively on nodes that have a specific custom resource (e.g., a license dongle) by matching node labels. This rule is a hard constraint that must be satisfied during scheduling, ensuring the pod only runs on nodes with the required resource. Unlike `nodeSelector`, node affinity supports more expressive matching (e.g., `In`, `NotIn`, `Exists`) and can be combined with other scheduling constraints.

Exam trap

The trap here is that candidates often confuse `nodeSelector` with node affinity, thinking both are equally capable for custom resource matching, but `nodeSelector` cannot handle existence-based checks (e.g., label presence without a value) which is common for custom resources like license dongles.

How to eliminate wrong answers

Option B is wrong because `nodeSelector` is a simpler, less expressive mechanism that only supports exact label matching (e.g., `key=value`), and it cannot handle complex conditions like checking for the existence of a label without a specific value, which is often needed for custom resources. Option C is wrong because assigning a high priority only affects the pod's scheduling order and preemption behavior, but it does not constrain the pod to nodes with the specific resource; the pod could still be scheduled on any node that meets other requirements. Option D is wrong because pod anti-affinity is used to prevent pods from being scheduled on the same node (or topology) as other pods, not to enforce placement on nodes with a specific resource; it addresses co-location constraints, not node-level resource availability.

Full explanation →

796

MCQeasy

Which component is responsible for running containers on a node and reporting their status to the control plane?

A.kubelet

B.container runtime (e.g., containerd)

C.kube-proxy

D.kube-scheduler

AnswerA

kubelet is the primary node agent that manages pods and reports node and container status.

Why this answer

The kubelet is the primary node agent that runs on every node in a Kubernetes cluster. It is responsible for ensuring that containers are running in a Pod as expected, by interacting with the container runtime (e.g., containerd) to start, stop, and monitor containers. The kubelet then reports the status of the node and its Pods back to the control plane via the Kubernetes API server, using heartbeats (NodeStatus updates) and Pod status updates.

Exam trap

The trap here is that candidates often confuse the container runtime with the kubelet, because both are involved in running containers, but the kubelet is the agent that reports status to the control plane, while the runtime only executes containers locally.

How to eliminate wrong answers

Option B (container runtime) is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for actually pulling images and managing container lifecycle, but it does not report status to the control plane; the kubelet communicates with the runtime via the CRI (Container Runtime Interface) and then reports to the API server. Option C (kube-proxy) is wrong because kube-proxy is a network proxy that runs on each node, handling network rules for Services (e.g., iptables/IPVS), but it does not manage containers or report their status to the control plane. Option D (kube-scheduler) is wrong because the kube-scheduler runs on the control plane (or master node) and is responsible for assigning Pods to nodes based on resource availability and constraints; it does not run on worker nodes and does not report container status.

Full explanation →

797

Multi-Selecthard

Which THREE statements about CSI (Container Storage Interface) are correct?

Select 3 answers

A.CSI supports both block and file volumes.

B.CSI allows storage vendors to develop custom drivers without modifying Kubernetes core.

C.CSI supports additional features like volume snapshots and resize.

D.CSI only works with dynamic provisioning.

E.CSI drivers must be compiled into the Kubernetes binary.

AnswersA, B, C

CSI can manage both types of volumes.

Why this answer

Option A is correct because the CSI specification defines support for both block and file volumes, enabling storage plugins to provision raw block devices or filesystems. This flexibility allows workloads like databases to use block storage for performance, while applications requiring shared access can use file volumes.

Exam trap

The trap here is that candidates assume CSI is limited to dynamic provisioning only, forgetting that static provisioning with pre-existing volumes is fully supported, or that CSI drivers must be compiled into Kubernetes, when in fact they run as external plugins.

Full explanation →

798

MCQeasy

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

A.kubectl get events --watch

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

C.kubectl logs --events

D.kubectl describe events

AnswerB

Why this answer

The --sort-by flag orders events by creation timestamp, showing recent events first.

Full explanation →

799

MCQeasy

A developer wants to mount a ConfigMap as a volume in a pod. However, the pod should only see specific keys from the ConfigMap, not all keys. What is the best approach?

A.Use the ConfigMap to set environment variables instead of a volume mount.

B.Use the 'items' field in the ConfigMap volume definition to specify which keys to include.

C.Mount the entire ConfigMap and use a startup script to remove unwanted files.

D.Create a new ConfigMap with only the needed keys.

AnswerB

The 'items' field allows selective mounting of keys.

Why this answer

Option B is correct because the `items` field in a ConfigMap volume definition allows you to selectively project only specific keys from the ConfigMap into the pod's filesystem. This is the native Kubernetes mechanism for controlling which keys appear as files, avoiding the need to mount the entire ConfigMap or create a separate ConfigMap.

Exam trap

The trap here is that candidates often confuse the `items` field with the `optional` field or assume that mounting a ConfigMap always exposes all keys, leading them to choose the wasteful approach of creating a new ConfigMap (Option D) instead of using the built-in selective projection mechanism.

How to eliminate wrong answers

Option A is wrong because using environment variables is a different mechanism that does not address the requirement to mount a ConfigMap as a volume; it also exposes all keys as environment variables unless you manually specify each key, which is not the best approach for selective file projection. Option C is wrong because mounting the entire ConfigMap and then using a startup script to remove unwanted files is an anti-pattern that wastes resources, adds complexity, and violates the principle of declarative configuration. Option D is wrong because creating a new ConfigMap with only the needed keys duplicates data and increases management overhead, whereas the `items` field achieves the same goal without creating additional objects.

Full explanation →

800

MCQmedium

An administrator creates a ServiceAccount named 'monitor' in the 'default' namespace. They want any pod using this ServiceAccount to be able to list pods cluster-wide. Which RBAC resource should be created and bound to this ServiceAccount?

A.ClusterRole and RoleBinding in the default namespace

B.ClusterRole and RoleBinding in kube-system

C.ClusterRole and ClusterRoleBinding

D.Role and RoleBinding in the default namespace

AnswerC

ClusterRoleBinding grants permissions cluster-wide regardless of namespace.

Why this answer

A ClusterRole is required because listing pods cluster-wide is a cluster-scoped operation, not limited to a single namespace. A ClusterRoleBinding is needed to bind the ClusterRole to the ServiceAccount 'monitor' at the cluster level, granting permissions across all namespaces. RoleBindings can only grant permissions within a single namespace, so they cannot achieve cluster-wide access.

Exam trap

The trap here is that candidates often confuse namespace-scoped RoleBindings with cluster-scoped ClusterRoleBindings, assuming a RoleBinding can grant cluster-wide permissions if the Role is a ClusterRole, but the binding type determines the scope of the grant.

How to eliminate wrong answers

Option A is wrong because a RoleBinding can only grant permissions within the namespace where it is created, so it cannot provide cluster-wide pod listing. Option B is wrong because a RoleBinding in kube-system would only grant permissions within the kube-system namespace, not cluster-wide. Option D is wrong because both a Role and a RoleBinding are namespace-scoped, limiting the ServiceAccount to only the default namespace.

Full explanation →

801

Multi-Selecteasy

Which TWO access modes are valid for PersistentVolumes?

Select 2 answers

A.WriteMany

B.ReadWriteOnce

C.ReadWriteMany

D.ReadOnlyOnce

E.ReadWriteOncePod

AnswersB, C

RWO allows a single node to mount the volume as read-write.

Why this answer

ReadWriteOnce (RWO) and ReadWriteMany (RWX) are standard access modes. ReadOnlyMany (ROX) is also valid but not listed here. Option C is a PVC access mode (ReadWriteOncePod) added in newer versions, but it's not a PV access mode.

Option D (ReadWriteOncePod) is actually a PVC access mode, so it's not a PV access mode? Actually, as of v1.29, ReadWriteOncePod is a valid access mode for both PVs and PVCs. However, the question says 'valid for PersistentVolumes', and ReadWriteOncePod is indeed valid for PVs. But let's check typical CKA: The standard ones are RWO, ROX, RWX.

RWOP is also valid but less common. To avoid confusion, I'll stick with the classic two. However, the instruction says to use accurate v1.29+ terminology, so RWOP is valid.

I'll include it as a distractor. Actually, I need exactly 2 correct among options. Let's design options so that A and B are correct (RWO and RWX), and C (ROX) is also correct? That would be 3.

I need 2 correct. So I'll make A and B correct, and C and D wrong. But ROX is a valid access mode.

I'll make one of the options 'ReadOnlyOnce' which is not valid. Let me adjust.

Full explanation →

802

MCQmedium

You define a Pod with resource requests: cpu: 250m, memory: 256Mi. The node has 2 CPUs and 4 Gi of memory. How many of these Pods can fit on the node based on CPU requests alone?

A.10

B.16

C.8

D.4

AnswerC

250m * 8 = 2000m, exactly the node's CPU capacity.

Why this answer

Option B is correct. 2 CPUs = 2000m. 2000m / 250m = 8 pods. Option A (4) would be if each pod requested 500m. Option C (16) would be if each pod requested 125m.

Option D (10) is a distractor.

Full explanation →

803

MCQmedium

A pod is failing with 'CrashLoopBackOff'. You run 'kubectl logs mypod' and see no output. What is the first troubleshooting step?

A.kubectl logs mypod --previous

B.kubectl exec -it mypod -- sh

C.kubectl delete pod mypod && kubectl create -f mypod.yaml

D.kubectl describe pod mypod

AnswerA

Why this answer

The correct first step is to use `kubectl logs mypod --previous` because the pod is in `CrashLoopBackOff`, meaning the current container has crashed and restarted. Since `kubectl logs mypod` shows no output, the current container may have exited before writing logs, or logs were written to stderr. The `--previous` flag retrieves logs from the last terminated container instance, which often contains the crash error message.

Exam trap

The trap here is that candidates assume `kubectl logs` shows all available logs, forgetting that a crashed container's output is only accessible via the `--previous` flag, leading them to choose `kubectl describe pod` or exec instead.

How to eliminate wrong answers

Option B is wrong because `kubectl exec -it mypod -- sh` attempts to start an interactive shell in a running container, but the pod is in `CrashLoopBackOff` and the container is not running, so exec will fail with an error like 'cannot exec into a container in a crashed state'. Option C is wrong because deleting and recreating the pod will lose the previous container's logs and crash history, making debugging harder; it is a reactive restart, not a diagnostic step. Option D is wrong because `kubectl describe pod mypod` shows pod events and status but does not provide the application-level error output from the crashed container; it is useful for infrastructure issues but not for application crash logs.

Full explanation →

804

MCQhard

You need to create a ServiceAccount named 'deployer' and grant it permission to create Deployments in namespace 'app'. Which YAML snippet correctly creates the necessary RBAC resources?

A.apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: Role name: deployer apiGroup: rbac.authorization.k8s.io

B.kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: ClusterRole name: deployer apiGroup: rbac.authorization.k8s.io

C.apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: ClusterRole name: deployer apiGroup: rbac.authorization.k8s.io

D.apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: default rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: Role name: deployer apiGroup: rbac.authorization.k8s.io

AnswerA

This correctly creates a namespace-scoped Role and RoleBinding in the 'app' namespace.

Why this answer

Option A is correct because it creates a ServiceAccount named 'deployer' in the 'app' namespace, a Role in the same namespace with rules allowing 'create' on 'deployments' (which belong to the 'apps' API group), and a RoleBinding that binds the ServiceAccount to that Role. This grants the ServiceAccount permission to create Deployments only within the 'app' namespace, which is the required scope.

Exam trap

CNCF often tests the distinction between Role and ClusterRole scoping, and the trap here is that candidates may incorrectly use a ClusterRole when a namespaced Role is sufficient, or misplace the Role in the wrong namespace, thinking the RoleBinding can reference it across namespaces.

How to eliminate wrong answers

Option B is wrong because it uses a ClusterRole and ClusterRoleBinding, which grant permissions cluster-wide (across all namespaces), not just in the 'app' namespace as required. Option C is wrong because it uses a ClusterRole with a RoleBinding; while a RoleBinding can reference a ClusterRole, the binding itself is namespaced, but the ClusterRole's scope is still cluster-wide, which is unnecessarily broad and not the minimal required RBAC for a single namespace. Option D is wrong because the Role is defined in the 'default' namespace, not in the 'app' namespace, so the RoleBinding in 'app' cannot reference a Role from a different namespace; Role and RoleBinding must be in the same namespace.

Full explanation →

805

MCQhard

You have a PriorityClass 'high-priority' with value 1000 and 'low-priority' with value 100. A pod A with 'high-priority' is pending because the node has no resources. A pod B with 'low-priority' is running on that node. What will happen if preemption is enabled?

A.Pod A will be scheduled only after pod B completes its work

B.Pod A will remain pending because preemption is not enabled by default

C.The cluster administrator must manually delete pod B to allow pod A to schedule

D.Pod B will be preempted (evicted) to allow pod A to be scheduled on the node

AnswerD

Higher priority pods can preempt lower priority pods to get resources.

Why this answer

When preemption is enabled, the Kubernetes scheduler can evict lower-priority pods to free resources for pending higher-priority pods. In this scenario, Pod A (priority 1000) is pending due to insufficient resources, while Pod B (priority 100) is running on the node. The scheduler will preempt (evict) Pod B to allow Pod A to be scheduled, as the priority difference is significant and preemption is enabled by default in Kubernetes (via the 'PrioritySort' and 'Preemption' plugins).

Exam trap

The trap here is that candidates often assume preemption requires manual configuration or is disabled by default, but Kubernetes enables preemption by default in the scheduler, and the scheduler automatically handles eviction without administrator intervention.

How to eliminate wrong answers

Option A is wrong because preemption does not wait for the lower-priority pod to complete; it actively evicts it to schedule the higher-priority pod. Option B is wrong because preemption is enabled by default in Kubernetes (the 'Preemption' plugin is active in the default scheduler configuration), so Pod A will not remain pending if a lower-priority pod can be evicted. Option C is wrong because the scheduler automatically handles preemption without manual intervention from the cluster administrator.

Full explanation →

806

Multi-Selectmedium

Which TWO of the following are required fields in a PersistentVolumeClaim spec? (Select TWO)

Select 2 answers

A.storageClassName

B.selector

C.accessModes

D.volumeMode

E.resources.requests.storage

AnswersC, E

accessModes is required to specify how the volume can be accessed.

Why this answer

A PVC spec requires at least 'accessModes' and 'resources.requests.storage'. 'storageClassName' is optional (if omitted, the default StorageClass is used). 'volumeMode' defaults to Filesystem if not specified. 'selector' is optional for matching PVs.

Full explanation →

807

MCQhard

A pod remains in Pending state. You run 'kubectl describe pod mypod' and see the following event: '0/3 nodes are available: 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 1 node(s) didn't match pod anti-affinity rules.' What is the best action to schedule the pod?

A.Increase the number of replicas

B.Modify the pod's anti-affinity rules or remove the conflicting pod on the third node

C.Remove the node.kubernetes.io/control-plane taint from the control plane nodes

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

AnswerB

The pod anti-affinity prevents scheduling on the node that matches the rule.

Why this answer

Two nodes have a control-plane taint; the pod likely tolerates it. One node fails anti-affinity. To resolve, you must adjust the pod's anti-affinity or remove the conflicting pod.

Full explanation →

808

Multi-Selectmedium

Which THREE of the following are characteristics of a StatefulSet? (Select 3)

Select 3 answers

A.Pods are started and terminated in a controlled order (sequentially)

B.Each pod can have its own persistent volume claim (PVC)

C.Pods are automatically distributed across all nodes in the cluster

D.StatefulSets require a ClusterIP service for stable network identities

E.Each pod has a unique, stable network identity (e.g., web-0, web-1)

AnswersA, B, E

The default pod management policy is OrderedReady, which ensures ordered operations.

Why this answer

Options A, B, and C are correct. StatefulSets provide stable network identities (ordinal hostnames), ordered pod management (sequential start/stop), and persistent storage per pod (PVC templates). Option D is incorrect because DaemonSets run pods on every node, not StatefulSets.

Option E is incorrect because StatefulSets use a headless service for stable network identities, not a ClusterIP service.

Full explanation →

809

MCQmedium

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

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

B.Delete the namespace and redeploy all workloads

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

D.Increase the CPU request for the container

AnswerA

Directly addresses the OOMKilled cause.

Why this answer

The pod is in a CrashLoopBackOff state with an 'OOMKilled' message, which indicates that the container's memory usage exceeded its configured memory limit, causing the kernel's Out-Of-Memory (OOM) killer to terminate the process. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause of the crash loop.

Exam trap

CNCF often tests the misconception that restarting or recreating the pod will resolve a CrashLoopBackOff caused by resource limits, but the trap here is that the OOMKilled error is a resource constraint issue, not a transient failure, so only adjusting the memory limit or removing the limit will stop the crash loop.

How to eliminate wrong answers

Option B is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not fix the underlying memory limit issue and would cause unnecessary downtime for all workloads in the namespace. Option C is wrong because deleting and recreating the pod will only restart the container with the same memory limit, resulting in the same OOMKilled crash and continued CrashLoopBackOff. Option D is wrong because increasing the CPU request does not affect memory constraints; the OOMKilled error is caused by exceeding the memory limit, not CPU resources.

Full explanation →

810

MCQmedium

A pod is stuck in Pending state. Running 'kubectl describe pod mypod' reveals the event '0/4 nodes are available: 3 Insufficient memory, 1 node(s) had taints that the pod didn't tolerate'. What is the most likely cause?

A.The pod requests more memory than available on any node and does not tolerate a node taint

B.The kubelet on all nodes is not running

C.The pod's container image is not pullable

D.The pod is using a hostPort that conflicts with an existing pod

AnswerA

The event explicitly states insufficient memory and an untolerated taint.

Why this answer

The pod is pending because no node can satisfy its resource requirements or tolerate the node taints. The event indicates insufficient memory and a taint issue. The correct answer is that the pod requests more memory than any node can allocate and also does not tolerate a node taint.

Full explanation →

811

MCQeasy

Which component on a worker node is responsible for maintaining network rules and enabling service abstraction?

A.kube-scheduler

B.kube-proxy

C.container runtime

D.kubelet

AnswerB

Correct: kube-proxy maintains network rules.

Why this answer

kube-proxy is the component on each worker node that maintains network rules (e.g., iptables, IPVS) and enables service abstraction by proxying traffic to the correct Pods. It watches the Kubernetes API server for Service and EndpointSlice changes, then updates the node's packet filtering rules to route cluster IP traffic to healthy backend Pods.

Exam trap

CNCF often tests the distinction between kubelet (Pod lifecycle) and kube-proxy (network rules), so the trap here is that candidates confuse kubelet's role in managing containers with the network abstraction provided by kube-proxy.

How to eliminate wrong answers

Option A is wrong because kube-scheduler runs on the control plane, not worker nodes, and is responsible for assigning Pods to nodes based on resource requirements, not for maintaining network rules or service abstraction. Option C is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for pulling images and running containers, not for implementing network policies or proxying service traffic. Option D is wrong because kubelet is the primary node agent that manages Pod lifecycle (e.g., ensuring containers are running) and reports node status, but it does not handle network rule maintenance or service proxying.

Full explanation →

812

MCQhard

A cluster has a NetworkPolicy that denies all ingress traffic by default. An administrator wants to allow TCP traffic on port 8080 from pods with label 'app: web' in the same namespace. Which NetworkPolicy egress rule is needed?

A.An ingress rule with podSelector matching 'app: web' and ports.

B.An ingress rule with namespaceSelector matching the same namespace.

C.An egress rule with namespaceSelector and podSelector.

D.An egress rule with podSelector matching 'app: web' and ports.

AnswerA

To allow incoming traffic from specific pods, you need an ingress rule with the appropriate podSelector.

Why this answer

The question asks about egress? Actually, it says ingress traffic. To allow ingress from pods with label 'app: web', you need an ingress rule with a podSelector. Egress is for outgoing traffic.

The correct answer is the one that specifies ingress rules with podSelector and ports.

Full explanation →

813

Multi-Selectmedium

You are applying the following RBAC manifest: --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: development name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] Which TWO statements are true about this Role? (Choose TWO.)

Select 2 answers

A.It also grants access to secrets in the 'development' namespace

B.It allows reading pod details in the 'development' namespace

C.It grants permissions across all namespaces

D.It grants permissions only within the 'development' namespace

E.It allows creating pods in the 'development' namespace

AnswersB, D

The verbs 'get', 'watch', 'list' are read operations on pods.

Why this answer

Option B is correct because the Role explicitly defines rules for the 'pods' resource with verbs 'get', 'watch', and 'list' in the 'development' namespace. These verbs allow reading pod details such as their specifications, status, and metadata. The Role is scoped to the 'development' namespace, so it only grants these read permissions within that namespace.

Exam trap

The trap here is that candidates often confuse a Role with a ClusterRole, mistakenly thinking a Role can grant permissions across all namespaces, or they assume that granting access to 'pods' implicitly grants access to related resources like secrets or logs.

Full explanation →

814

MCQhard

A pod is stuck in 'Pending' state. The 'kubectl describe pod' output shows the event: '0/4 nodes are available: 3 node(s) had taint {node.kubernetes.io/unreachable: }, and 1 node(s) had taint {node.kubernetes.io/not-ready: }.' What is the most likely reason?

A.The pod has resource requests that exceed available capacity

B.The pod does not have tolerations for the node taints

C.The nodes are cordoned

D.The kube-scheduler is not running

AnswerB

The events explicitly mention taints, indicating missing tolerations.

Why this answer

The pod is stuck in 'Pending' because none of the available nodes can schedule it. The events explicitly show taints: 'node.kubernetes.io/unreachable' on 3 nodes and 'node.kubernetes.io/not-ready' on 1 node. By default, pods do not tolerate these taints, so the scheduler cannot place the pod unless it has matching tolerations.

Option B correctly identifies that the pod lacks the required tolerations.

Exam trap

The trap here is that candidates often confuse taint-based scheduling failures with resource insufficiency or node cordoning, but the specific taint names in the event message directly point to node health issues rather than capacity or manual unschedulability.

How to eliminate wrong answers

Option A is wrong because resource requests exceeding capacity would produce events like 'Insufficient cpu' or 'Insufficient memory', not taint-based messages. Option C is wrong because cordoned nodes show 'node.kubernetes.io/unschedulable:NoSchedule' taint, not 'unreachable' or 'not-ready'. Option D is wrong because if the kube-scheduler were not running, the pod would remain in 'Pending' with no scheduling events at all, not specific taint-related messages.

Full explanation →

815

MCQmedium

A pod is in CrashLoopBackOff. You check the logs with 'kubectl logs my-pod --previous' and see 'Error: cannot connect to database at 10.0.0.1:3306'. The database service is named 'mysql' and runs on port 3306. What is the most likely cause?

A.The application is configured with an incorrect database hostname

B.The pod does not have network access to the mysql service

C.The mysql service is not exposed on port 3306

D.The database pod is not running

AnswerA

Using a hardcoded IP that may change; should use the service name.

Why this answer

The application is likely using the wrong hostname or IP for the database. It should use the service name 'mysql' instead of a hardcoded IP.

Full explanation →

816

MCQeasy

A user creates a Deployment with replicas=3. Two Pods are running, but the third is stuck in ContainerCreating. 'kubectl describe pod' shows 'Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create containerd task: OCI runtime create failed: container_linux.go:349: starting container process caused: exec: "/app": stat /app: no such file or directory'. What is the most likely cause?

A.The container image is not pulled due to authentication failure.

B.The container exceeds its memory limit and is killed.

C.The node is not schedulable due to taints.

D.The container image does not have the /app executable at the specified path.

AnswerD

The error clearly states the executable /app is not found, indicating a misconfigured command or missing binary.

Why this answer

The error message 'exec: "/app": stat /app: no such file or directory' indicates that the container runtime (containerd) successfully created the sandbox and started the container process, but the command specified in the container's entrypoint or command tried to execute '/app', which does not exist inside the container image. This is a classic misconfiguration where the image lacks the expected binary or script at the given path, causing the container to fail immediately after creation.

Exam trap

The trap here is that candidates may confuse a 'ContainerCreating' status with image pull issues or resource limits, but the specific OCI runtime exec error points directly to a missing executable in the container image, not to infrastructure or scheduling problems.

How to eliminate wrong answers

Option A is wrong because an authentication failure would produce an 'ImagePullBackOff' or 'ErrImagePull' status, not a 'ContainerCreating' state with an OCI runtime exec error. Option B is wrong because exceeding the memory limit results in an OOMKilled container (status 'OOMKilled'), not a failure to start the container process with a 'no such file or directory' error. Option C is wrong because taints cause the pod to remain in 'Pending' state (not 'ContainerCreating'), and the error message is about container runtime execution, not scheduling.

Full explanation →

817

MCQhard

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate'. What is the most likely cause?

A.The pod is missing resource requests.

B.The pod does not tolerate the node's taint.

C.The node is cordoned.

D.The kubelet is not running on the node.

AnswerB

The taint is preventing scheduling unless the pod has a toleration.

Why this answer

The pod is stuck in 'Pending' because the scheduler cannot find a node that satisfies its scheduling constraints. The 'kubectl describe pod' output explicitly states that 1 node has a taint (node-role.kubernetes.io/master) that the pod does not tolerate. By default, pods do not tolerate the master taint, so they are not scheduled onto master nodes unless a toleration is added.

This is the direct cause of the pending state.

Exam trap

The trap here is that candidates may confuse taints with node cordoning or resource constraints, but the specific error message about 'taint that the pod didn't tolerate' directly points to a toleration mismatch, not a resource or node readiness issue.

How to eliminate wrong answers

Option A is wrong because missing resource requests would cause the scheduler to fail with a different error message, such as 'Insufficient cpu' or 'Insufficient memory', not a taint-related message. Option C is wrong because a cordoned node would show 'node(s) were cordoned' or 'node(s) had taint node.kubernetes.io/unschedulable' in the describe output, not a taint about node-role.kubernetes.io/master. Option D is wrong because if the kubelet were not running, the node would show as 'NotReady' and the scheduler would report '0/1 nodes are available: 1 node(s) were not ready', not a taint-related message.

Full explanation →

818

MCQhard

You are troubleshooting a DNS issue in the cluster. You exec into a pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command returns 'server can't find kubernetes.default.svc.cluster.local: NXDOMAIN'. What is the MOST likely cause?

A.The kube-dns service does not exist

B.The pod's /etc/resolv.conf points to an external DNS server instead of the cluster DNS

C.The CoreDNS pod(s) are not running or are misconfigured

D.The pod's network policy blocks DNS traffic

AnswerC

If CoreDNS is down, DNS resolution fails with NXDOMAIN because there is no server to answer.

Why this answer

Option C is correct. NXDOMAIN indicates that the DNS server does not have a record for that name. The most common cause is that the CoreDNS pod(s) are not running or are misconfigured.

Option A would cause a timeout not NXDOMAIN. Option B would cause a different error (connection refused). Option D might cause partial resolution but not NXDOMAIN for the entire service name.

Full explanation →

819

MCQeasy

To view the logs of a specific container in a multi-container pod named 'web-pod', which command is correct?

A.kubectl logs web-pod --all-containers

B.kubectl logs web-pod --container app-container

C.kubectl logs app-container -p web-pod

D.kubectl logs -c web-pod app-container

AnswerB

The --container (or -c) flag is used to specify the container name.

Why this answer

The correct command is 'kubectl logs web-pod -c app-container'. The -c flag specifies the container name.

Full explanation →

820

MCQeasy

Which of the following is a core component of the Gateway API?

A.VirtualService

B.GatewayClass

C.IngressController

D.ServiceEntry

AnswerB

GatewayClass defines a class of Gateways, similar to IngressClass.

Full explanation →

821

MCQmedium

A cluster administrator wants to provide storage for an application that requires reading and writing by multiple pods simultaneously. The storage backend is an NFS server that supports multiple writers. Which access mode should be specified in the PersistentVolume?

A.ReadOnlyMany

B.ReadWriteOnce

C.ReadWriteOncePod

D.ReadWriteMany

AnswerD

RWX allows many pods to read and write, which matches the requirement.

Why this answer

ReadWriteMany (RWX) allows multiple pods to read and write to the volume simultaneously. ReadWriteOnce (RWO) only allows a single pod, and ReadOnlyMany (ROX) is read-only. ReadWriteOncePod (RWOP) is a newer mode that restricts to a single pod even within a node.

Full explanation →

822

MCQeasy

Which component is responsible for running containers on a Kubernetes node?

A.kube-proxy

B.kube-scheduler

C.kubelet

D.kube-controller-manager

AnswerC

Why this answer

The kubelet is the primary node agent that runs on each Kubernetes node. It is responsible for ensuring that containers are running in a Pod as expected by interacting with the container runtime (e.g., Docker, containerd, CRI-O) via the Container Runtime Interface (CRI). It receives Pod specifications from the API server and manages the lifecycle of the containers accordingly.

Exam trap

The trap here is that candidates often confuse the kubelet with the kube-scheduler or kube-controller-manager, thinking that scheduling or managing controllers is equivalent to running containers, but the kubelet is the only component that directly interacts with the container runtime to execute containers on a node.

How to eliminate wrong answers

Option A is wrong because kube-proxy is a network proxy that runs on each node, handling network rules and forwarding traffic to Pods (e.g., via iptables or IPVS), not running containers. Option B is wrong because kube-scheduler is a control plane component that assigns Pods to nodes based on resource availability and constraints, but it does not execute or manage containers on any node. Option D is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that regulate cluster state, but it does not directly run containers on nodes.

Full explanation →

823

MCQmedium

You need to ensure that a Pod only runs on nodes that are in a specific availability zone labeled 'zone=us-east-1a'. Which scheduling constraint should you use?

A.nodeName set to a specific node in that zone

B.podAntiAffinity

C.nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution

D.nodeSelector with zone: us-east-1a

AnswerD

nodeSelector directly matches labels.

Why this answer

Option A is correct. nodeSelector is the simplest way to constrain a pod to nodes with specific labels. Affinity/anti-affinity (Options B and C) can also be used but are more complex. Option D (nodeName) bypasses scheduling and assigns directly, which is not flexible.

Full explanation →

824

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

Shows pod resource usage across all namespaces.

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 →

825

Multi-Selectmedium

Which TWO of the following are valid reasons for a pod to be in 'CrashLoopBackOff' state? (Choose two.)

Select 2 answers

A.The pod is requesting more CPU than any node can provide

B.The application inside the container exits with a non-zero exit code immediately after starting

C.The liveness probe is failing, causing the container to be restarted repeatedly

D.The pod's persistent volume claim is not bound

E.The container image does not exist in the registry

AnswersB, C

If the application crashes immediately, the container exits with a non-zero code, and Kubernetes restarts it. This repeated failure leads to CrashLoopBackOff.

Why this answer

Options B and C are correct. A crash loop occurs when the container starts and then crashes repeatedly. The backoff delay increases with each restart.

Option B: If the application exits with a non-zero exit code, it will be restarted, leading to a crash loop if it keeps failing. Option C: A failing liveness probe causes the container to be restarted, leading to a crash loop. Option A (insufficient CPU) causes the pod to be in Pending state, not CrashLoopBackOff.

Option D (image not found) causes ImagePullBackOff. Option E (PVC not bound) causes Pending state.

Full explanation →

Certified Kubernetes Administrator CKA (CKA) — Questions 751–825