Courseiva

Certified Kubernetes Administrator CKA (CKA) — Questions 1–75

726 questions total · 10pages · All types, answers revealed

Take a mock examExam hub

Page 1 of 10

Page 2
1
MCQeasy

You are managing a Kubernetes cluster with three worker nodes. A deployment named 'frontend' is configured with 3 replicas. After a node failure, you notice that only 2 pods are running, and the third pod is stuck in 'Pending' state. The remaining nodes have sufficient CPU and memory. You check the deployment events and find no errors. You also verify that the PersistentVolumeClaims (PVCs) used by the deployment are bound. What is the most likely reason the third pod is not scheduled?

A.The ReplicaSet controller is not creating a new pod because the deployment's progressDeadlineSeconds has expired.
B.The PersistentVolumeClaims are using 'WaitForFirstConsumer' binding mode and the pod is pending because the volume is not yet bound.
C.The kube-scheduler is down or misconfigured.
D.The pod has a nodeSelector that only matches the failed node.
AnswerD

When a pod specifies a nodeSelector that targets a unique label only present on the failed worker node, the kube-scheduler cannot find any other eligible nodes that satisfy this constraint. Consequently, the pod remains unschedulable and stuck in a Pending state, even though other healthy worker nodes are available in the cluster.

Why this answer

A nodeSelector that exclusively matches the failed node would prevent the scheduler from placing the pod on any other node, even if those nodes have sufficient resources. Since the failed node is unavailable, the pod remains in 'Pending' state indefinitely, as no other node satisfies the constraint.

Exam trap

The trap here is that candidates assume resource constraints or scheduler failures are the default cause for pending pods, overlooking that a nodeSelector or affinity rule can silently prevent scheduling even when resources are abundant.

How to eliminate wrong answers

Option A is wrong because progressDeadlineSeconds only triggers a deployment rollout failure (marking the deployment as progressing false) but does not prevent the ReplicaSet from creating or scheduling pods; it is a rollout health check, not a scheduling blocker. Option B is wrong because the PVCs are already bound (as stated), so 'WaitForFirstConsumer' would cause the volume to bind only after scheduling, but the pod would still be pending due to volume binding, not because the volume is unbound—the scenario says PVCs are bound, eliminating this. Option C is wrong because if the kube-scheduler were down or misconfigured, all pods would be stuck in 'Pending', not just one; the fact that two pods are running indicates the scheduler is functional.

Full explanation →
2
MCQeasy

You need to create a Service that exposes port 80 on each node's IP at a static port (30080). Which Service type should you use?

A.NodePort
B.LoadBalancer
C.ClusterIP
D.ExternalName
AnswerA

NodePort allocates a static port from the default range (30000–32767) on every node's IP, satisfying the requirement for port 30080. kube-proxy programs iptables or IPVS rules forwarding that node port to the Service's cluster IP, then to backing pods.

Why this answer

A NodePort Service exposes the application on a static port (30080) across every node's IP address in the cluster. This is the only Service type that allows you to specify a fixed port on the node's IP, making it the correct choice for this requirement.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking a load balancer is required for external access, but NodePort directly satisfies the requirement of exposing a static port on each node's IP without any cloud dependency.

How to eliminate wrong answers

Option B (LoadBalancer) is wrong because it relies on an external cloud provider to provision a load balancer and does not directly expose a static port on each node's IP; it typically creates a NodePort underneath but adds an external IP. Option C (ClusterIP) is wrong because it only exposes the Service on a cluster-internal IP, not on the node's IP or a static port accessible from outside the cluster. Option D (ExternalName) is wrong because it maps a Service to an external DNS name via CNAME records and does not expose any port on the nodes.

Full explanation →
3
MCQeasy

Which command should you use to view the logs of a container that has previously crashed in a Pod?

A.kubectl logs <pod-name>
B.kubectl describe pod <pod-name>
C.kubectl logs <pod-name> -c <container-name>
D.kubectl logs <pod-name> --previous
AnswerD

`--previous` retrieves logs from the container's prior terminated instance, not the current one. This directly satisfies the stem's constraint of a container that has already crashed and restarted, since the default `kubectl logs` reads only the running instance's output.

Why this answer

`kubectl logs <pod-name> --previous` retrieves the logs from the previous instance of a container in a Pod, which is exactly what you need when a container has crashed and restarted. The `--previous` flag accesses the logs of the terminated (crashed) container, not the current running one, allowing you to see the error that caused the crash.

Exam trap

The trap here is that candidates often assume `kubectl logs <pod-name>` alone will show crash logs, but it only shows the current container's logs, so they miss the `--previous` flag required for accessing logs from a terminated container.

How to eliminate wrong answers

Option A is wrong because `kubectl logs <pod-name>` only shows logs from the currently running container; if the container has crashed and restarted, the logs from the crash are lost from the current instance. Option B is wrong because `kubectl describe pod <pod-name>` shows the Pod's metadata, status, and events (including crash loop backoff details), but it does not display the container's log output. Option C is wrong because `kubectl logs <pod-name> -c <container-name>` is used to specify a container name when a Pod has multiple containers, but it still only shows logs from the current (running) container, not the previous crashed one.

Full explanation →
4
MCQmedium

You create a ClusterIP service named 'my-svc' in the 'default' namespace. A pod in the same namespace tries to reach the service using the DNS name 'my-svc'. Which fully qualified domain name (FQDN) should the pod use to resolve the service?

A.my-svc.default.svc.cluster
B.my-svc.default.svc.cluster.local
C.my-svc.default.cluster.local
D.my-svc.svc.cluster.local
AnswerB

This is the canonical fully qualified domain name for a ClusterIP Service in the default namespace. Kubernetes DNS constructs it as <service-name>.<namespace>.svc.cluster.local, where 'svc' identifies the service record type and cluster.local is the cluster domain. When you create a Service named my-svc in the default namespace, this exact FQDN resolves to the Service's ClusterIP address, enabling stable in-cluster service discovery.

Why this answer

The standard FQDN for a Kubernetes service in the default namespace is `<service-name>.<namespace>.svc.cluster.local`. This is the DNS record created by CoreDNS (or kube-dns) for ClusterIP services, allowing pods to resolve the service by its fully qualified domain name. The pod can also use the shorter form `my-svc` because the DNS search path includes the service's namespace and the `svc.cluster.local` suffix, but the FQDN ensures unambiguous resolution.

Exam trap

The trap here is that candidates often forget the `svc` subdomain in the FQDN or omit the namespace, leading them to choose options like `my-svc.svc.cluster.local` (missing namespace) or `my-svc.default.cluster.local` (missing `svc`), while the correct format is `<service>.<namespace>.svc.cluster.local`.

How to eliminate wrong answers

Option A is wrong because it uses `cluster` instead of `cluster.local`; Kubernetes DNS domain is `cluster.local` by default, not `cluster`. Option C is wrong because it omits `svc` from the FQDN; the correct hierarchy is `<service>.<namespace>.svc.cluster.local`, not `<service>.<namespace>.cluster.local`. Option D is wrong because it omits the namespace `default`; the FQDN must include the namespace to uniquely identify the service, as services are namespaced resources.

Full explanation →
5
Multi-Selectmedium

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

Select 3 answers
A.Pods are created and terminated in a predictable order (ordinal index)
B.Each pod gets its own PersistentVolumeClaim (PVC) that persists across rescheduling
C.Pods are created in random order
D.Each pod gets a unique, stable network identity (hostname)
E.All pods in the StatefulSet are interchangeable
AnswersA, B, D

This is a key characteristic of StatefulSets. They assign ordinal indices (0,1,2,...) and create/scale/terminate pods in order, ensuring that each pod is fully ready before the next is started. For example, when scaling up, pod-0 starts and becomes ready, then pod-1, etc. During termination, it's reverse order. This ordered behavior is critical for applications requiring leader election or primary/secondary roles, as the first pod often becomes the leader.

Why this answer

Option A is correct because a StatefulSet assigns each pod a stable ordinal index (0, 1, 2, ...) and creates, scales, and terminates pods in that strict ordered sequence, unlike a Deployment. Option B is correct because StatefulSets use volumeClaimTemplates to give each pod its own dedicated PersistentVolumeClaim, which is retained and reattached to the same ordinal pod even after rescheduling. Option D is correct because each StatefulSet pod receives a stable, unique network identity in the form of a predictable hostname (pod-name.service-name) backed by a headless Service, so DNS names remain consistent across restarts.

Option C is incorrect because StatefulSet pods are never created in random order; ordering is deterministic by ordinal. Option E is incorrect because StatefulSet pods are deliberately not interchangeable — each has its own identity, hostname, and storage, which is the opposite of the interchangeable replicas in a Deployment.

Exam trap

The trap here is that candidates often confuse StatefulSet behavior with Deployment behavior, assuming pods are interchangeable or created in random order, but StatefulSets enforce ordered creation/termination and unique identities for stateful workloads.

Full explanation →
6
MCQeasy

A cluster administrator wants to ensure that no pods are scheduled on the master node(s). Which approach is the best practice?

A.Add a taint to the master node
B.Delete the master node from the cluster
C.Use a resource quota on the master namespace
D.Set nodeSelector on the master node
AnswerA

Applying a NoSchedule or NoExecute taint to the master (control plane) node ensures that the Kubernetes scheduler will not place any pods on it unless they have a matching toleration. While modern Kubernetes clusters apply this taint by default to protect control plane resources, manually adding or verifying this taint is the standard declarative method to enforce this scheduling restriction.

Why this answer

Adding a taint to the master node(s) with the `node-role.kubernetes.io/master:NoSchedule` effect is the best practice because it prevents the Kubernetes scheduler from placing any pods on that node unless a pod explicitly tolerates the taint. This ensures that only critical system pods (which include the toleration) can run on the master, keeping it dedicated to cluster control plane operations.

Exam trap

The trap here is that candidates often confuse `nodeSelector` (a pod scheduling constraint) with node-level restrictions, or think that deleting a node or using resource quotas can control scheduling to a specific node, when only taints (or node affinity with requiredDuringSchedulingIgnoredDuringExecution) provide that node-level control.

How to eliminate wrong answers

Option B is wrong because deleting the master node from the cluster would remove the control plane, making the cluster non-functional; the goal is to prevent pod scheduling, not to remove the node entirely. Option C is wrong because a resource quota on a namespace (e.g., 'master' namespace) limits resource consumption but does not prevent pods from being scheduled onto a specific node; pods could still be placed on the master node from any namespace. Option D is wrong because `nodeSelector` is used to constrain which nodes a pod can be scheduled on, but it is a pod-level attribute, not a node-level restriction; setting it on the master node itself is not a valid operation and does not prevent other pods from being scheduled there.

Full explanation →
7
MCQeasy

A pod is running with the default DNS policy. The cluster DNS service is at 10.96.0.10. The node's /etc/resolv.conf has nameserver 8.8.8.8. When the pod tries to resolve an external hostname like 'example.com', which DNS server will it query first?

A.The node's DNS server (8.8.8.8)
B.There is no DNS resolution; the pod cannot resolve external names by default
C.The cluster DNS service (10.96.0.10)
D.The pod's own /etc/resolv.conf which contains the node's DNS
AnswerC

With the default `ClusterFirst` DNS policy, the `kubelet` configures the pod's `/etc/resolv.conf` to list the cluster DNS service IP (e.g., 10.96.0.10, which is the default `kube-dns` or `CoreDNS` service IP in many clusters) as the primary nameserver. All DNS queries originating from the pod are initially sent to this cluster DNS service. The service then resolves internal cluster names directly and forwards external name queries to upstream DNS servers.

Why this answer

With the default DNS policy (ClusterFirst), pods are configured to use the cluster DNS service (10.96.0.10) as the first nameserver in their /etc/resolv.conf. This is achieved by kubelet injecting the cluster DNS IP and a search domain into the pod's resolv.conf. Therefore, the pod will query the cluster DNS service first for any hostname resolution, including external names like 'example.com'.

Exam trap

The trap here is that candidates confuse the default DNS policy ('ClusterFirst') with the 'Default' policy, mistakenly thinking the pod inherits the node's /etc/resolv.conf directly, when in fact 'ClusterFirst' forces the pod to use the cluster DNS service as the primary resolver.

How to eliminate wrong answers

Option A is wrong because the pod's /etc/resolv.conf lists the cluster DNS service (10.96.0.10) as the first nameserver, not the node's 8.8.8.8; the node's resolv.conf is only used when the pod's DNS policy is set to 'Default' (which inherits the node's DNS), but the question states the default policy is 'ClusterFirst'. Option B is wrong because the default DNS policy does allow external name resolution; the cluster DNS forwards unresolved queries (e.g., for external names) to upstream DNS servers configured in its CoreDNS configuration. Option D is wrong because the pod's /etc/resolv.conf does not contain the node's DNS server (8.8.8.8) by default; it contains the cluster DNS IP and search domains, not the node's nameserver.

Full explanation →
8
MCQeasy

What is the purpose of the kube-proxy component?

A.It proxies API requests to the kube-apiserver
B.It manages network rules for Services and endpoints
C.It stores cluster state
D.It schedules pods to nodes
AnswerB

kube-proxy implements the Service abstraction by writing network rules — typically iptables or IPVS — that distribute traffic destined for a Service's clusterIP among its backing Pod endpoints. It watches the API for Services and EndpointSlices, then updates these rules so that connections are load-balanced and reachable from within the cluster. This is the core purpose of the component.

Why this answer

B is correct because kube-proxy is the component responsible for implementing the network rules that enable Kubernetes Services to function. It runs on each node and maintains iptables or IPVS rules to route traffic to the correct backend Pods based on the Service's endpoints, handling load balancing and service discovery at the network layer.

Exam trap

The trap here is that candidates confuse kube-proxy with an API proxy or ingress controller, but kube-proxy specifically handles Service-level network rules at the node level, not application-layer routing or API request proxying.

How to eliminate wrong answers

Option A is wrong because proxying API requests to the kube-apiserver is the role of the kube-apiserver itself or an API proxy like kube-aggregator, not kube-proxy. Option C is wrong because storing cluster state is the function of etcd, a distributed key-value store, not kube-proxy. Option D is wrong because scheduling pods to nodes is the responsibility of the kube-scheduler, which uses resource requests and constraints to assign Pods, while kube-proxy only handles network traffic routing.

Full explanation →
9
MCQmedium

A CronJob is configured to run every hour. You notice that the job did not run at the scheduled time. What is the most likely reason?

A.The concurrency policy is set to 'Forbid' and a previous job was still running
B.The concurrency policy is set to 'Allow'
C.The previous job run succeeded and the CronJob is configured to not rerun after success
D.The concurrency policy is set to 'Replace'
AnswerA

When a CronJob's `concurrencyPolicy` is set to `Forbid`, the CronJob controller ensures that only one instance of the job runs at any given time. If the scheduled time for a new job arrives, but a previous job created by the same CronJob is still active (running or pending), the controller will simply skip the new scheduled run. This prevents resource contention or duplicate processing by ensuring strict sequential execution, directly explaining why a job might not run as scheduled.

Why this answer

When a CronJob's concurrency policy is set to 'Forbid', it prevents a new job from starting if the previous job is still running. If the previous job took longer than the scheduled interval (e.g., more than one hour), the next scheduled run will be skipped, causing the job not to run at the expected time. This is a common scenario where a long-running job overlaps with the next scheduled time, and the 'Forbid' policy enforces that only one job instance runs at a time.

Exam trap

The trap here is that candidates often assume a CronJob always runs at its scheduled time, overlooking how the 'Forbid' concurrency policy can skip runs when a previous job is still active, especially when the job duration exceeds the schedule interval.

How to eliminate wrong answers

Option B is wrong because 'Allow' is the default concurrency policy that permits multiple jobs to run concurrently, so it would not prevent the job from running at the scheduled time. Option C is wrong because CronJobs do not have a 'not rerun after success' configuration; they run based on the schedule regardless of previous job success or failure, unless the 'startingDeadlineSeconds' is exceeded. Option D is wrong because 'Replace' terminates the currently running job and starts a new one at the scheduled time, so the job would still run (the old one is replaced), not skipped.

Full explanation →
10
MCQmedium

A node named 'worker-1' is unhealthy. You want to mark it as unschedulable and move workloads to other nodes. Which command sequence is correct?

A.kubectl uncordon worker-1; kubectl drain worker-1
B.kubectl cordon worker-1; kubectl drain worker-1
C.kubectl delete node worker-1; kubectl cordon worker-1
D.kubectl drain worker-1; kubectl cordon worker-1
AnswerB

This is the correct sequence because `kubectl cordon` immediately taints the node as unschedulable, ensuring no new workloads are assigned to it. Following this with `kubectl drain` safely evicts existing pods, forcing controllers to recreate them on healthy nodes. This orderly transition prevents race conditions where evicted pods are immediately rescheduled back onto the same failing node.

Why this answer

`kubectl cordon worker-1` marks the node as unschedulable, preventing new pods from being scheduled onto it, and `kubectl drain worker-1` safely evicts all existing pods from the node, respecting PodDisruptionBudgets and terminating pods gracefully. This sequence ensures workloads are moved to other nodes without disrupting running services.

Exam trap

The trap here is that candidates often confuse the order of `cordon` and `drain`, mistakenly thinking draining first is safe, but the CKA exam tests the understanding that cordoning must precede draining to prevent new pods from being scheduled onto the node during the eviction process.

How to eliminate wrong answers

Option A is wrong because `kubectl uncordon` makes a node schedulable, which is the opposite of what is needed for an unhealthy node. Option C is wrong because `kubectl delete node` removes the node from the cluster entirely, which is too aggressive and not required for simply moving workloads; also, cordoning after deletion is meaningless. Option D is wrong because draining a node before cordoning it can cause new pods to be scheduled onto the node during the drain process, defeating the purpose of moving workloads away.

Full explanation →
11
MCQeasy

A system administrator needs to install a Kubernetes cluster using kubeadm. The control plane node must be initialized with a specific Pod network CIDR of 10.244.0.0/16 for Flannel. Which command should be used?

A.kubeadm init --service-cidr 10.244.0.0/16
B.kubeadm init --pod-network-cidr 10.244.0.0/16
C.kubeadm init --network-cidr 10.244.0.0/16
D.kubeadm init --apiserver-advertise-address 10.244.0.0
AnswerB

The --pod-network-cidr flag is the correct kubeadm parameter for specifying the CIDR range from which pod IP addresses are allocated. It passes 10.244.0.0/16 to the API server and controller-manager, and CNI plugins like Flannel expect this exact range for their default configuration. This option directly enables pod networking, making it the right choice.

Why this answer

`kubeadm init` uses the `--pod-network-cidr` flag to specify the CIDR range for Pod IP addresses, which is required by Flannel and other CNI plugins to allocate subnets to nodes. The 10.244.0.0/16 range is the default Pod network CIDR for Flannel, ensuring proper network configuration without conflicts.

Exam trap

The trap here is that candidates confuse `--pod-network-cidr` with `--service-cidr` or invent non-existent flags like `--network-cidr`, because kubeadm has multiple CIDR-related options and the exam tests precise flag recall.

How to eliminate wrong answers

Option A is wrong because `--service-cidr` sets the IP range for Kubernetes services (default 10.96.0.0/12), not the Pod network; using it for Pod CIDR would misconfigure service networking. Option C is wrong because `--network-cidr` is not a valid `kubeadm init` flag; the correct flag is `--pod-network-cidr`. Option D is wrong because `--apiserver-advertise-address` specifies the IP address on which the API server advertises itself (e.g., the control plane node's IP), not a CIDR range for Pods.

Full explanation →
12
MCQhard

A user reports that their application cannot resolve DNS names for services in the cluster. The application runs in a pod with dnsPolicy: ClusterFirst. What is the most likely cause?

A.The CoreDNS deployment has 0 ready replicas.
B.The pod's dnsPolicy is set to Default instead of ClusterFirst.
C.The node's network plugin is misconfigured, blocking UDP port 53.
D.The pod's /etc/resolv.conf contains incorrect nameserver entries.
AnswerA

CoreDNS is the default cluster DNS provider in Kubernetes, responsible for resolving internal service names and external domains. If the CoreDNS deployment has zero ready replicas, there are no active pods to handle DNS queries sent to the kube-dns service IP. Consequently, any pod attempting to resolve a DNS name will experience a timeout or resolution failure.

Why this answer

When dnsPolicy is ClusterFirst, the pod's DNS queries are forwarded to the cluster's DNS service (CoreDNS by default). If the CoreDNS deployment has 0 ready replicas, the DNS service has no backend endpoints to handle queries, causing all DNS resolutions to fail. This is the most direct and common cause of complete DNS failure in a cluster.

Exam trap

The trap here is that candidates may overthink network-level issues (like UDP port blocking) or misread the dnsPolicy, when the simplest and most common cause is that the DNS service itself (CoreDNS) is not running.

How to eliminate wrong answers

Option B is wrong because the pod's dnsPolicy is already set to ClusterFirst (as stated in the question), so suggesting it is set to Default is factually incorrect and would not explain the failure. Option C is wrong because while a misconfigured network plugin blocking UDP port 53 could cause DNS issues, it is less likely than CoreDNS being down, and the question asks for the 'most likely' cause; also, CoreDNS itself listens on port 53, so if it has 0 replicas, the port is irrelevant. Option D is wrong because with dnsPolicy: ClusterFirst, the pod's /etc/resolv.conf is automatically generated by kubelet to point to the cluster DNS service IP (e.g., 10.96.0.10), and incorrect entries would only occur if the policy were Default or if the kubelet configuration is broken, which is less common than CoreDNS being unavailable.

Full explanation →
13
MCQeasy

You need to see the startup logs of the kubelet service. Which command should you use?

A.kubectl get events --all-namespaces
B.systemctl status kubelet
C.journalctl -u kubelet
D.kubectl logs kubelet -n kube-system
AnswerC

Because the kubelet runs as a native systemd service on the control plane and worker nodes, its standard output and error streams are captured by systemd-journald. Using this command queries the journal daemon specifically for the `kubelet` unit, outputting its complete, chronological startup and runtime log history.

Why this answer

`journalctl -u kubelet` retrieves the systemd journal logs for the kubelet service unit. Since kubelet runs as a systemd service on the node, its startup logs (including failures, configuration errors, or TLS bootstrap issues) are captured by journald and can be viewed with this command. This is the standard way to inspect kubelet's early boot-time behavior, which is not accessible via kubectl or systemctl status alone.

Exam trap

The trap here is that candidates confuse the kubelet with a Kubernetes pod and try to use `kubectl logs`, forgetting that kubelet is a node-level systemd service, not a container managed by the API server.

How to eliminate wrong answers

Option A is wrong because `kubectl get events --all-namespaces` shows Kubernetes API server events (e.g., pod scheduling, node conditions), not the kubelet service's own startup logs. Option B is wrong because `systemctl status kubelet` shows only the current status and the last few log lines of the kubelet service, not the full startup log history. Option D is wrong because `kubectl logs kubelet -n kube-system` attempts to fetch container logs from a pod named 'kubelet' in kube-system, but kubelet is not a Kubernetes pod; it runs as a systemd service on the node, so this command will fail with an error like 'Error from server: pods "kubelet" not found'.

Full explanation →
14
MCQhard

You are debugging a Pod that is in 'Pending' state. The output of 'kubectl describe pod' shows: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 2m default-scheduler 0/3 nodes are available: 1 Insufficient cpu, 2 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate. What does this indicate?

A.The pod requires more memory than any node can provide
B.The pod cannot be scheduled due to a combination of insufficient CPU and untolerated taints on different nodes
C.All nodes have taints that the pod does not tolerate
D.All nodes have insufficient CPU resources for the pod
AnswerB

Kubernetes scheduler attempts to place a pod on any node, and each node may fail for a different reason. The event messages show one node lacks enough allocatable CPU, while two other nodes have taints the pod does not tolerate. Because no node passes all filters, the pod remains Pending, and the correct overall diagnosis is the union of these two distinct scheduling blockers.

Why this answer

The event message explicitly states that 0/3 nodes are available due to two distinct issues: one node has insufficient CPU, and two nodes have a taint (node-role.kubernetes.io/master) that the pod does not tolerate. This means no single node satisfies all scheduling requirements, so the pod remains Pending. Option B correctly identifies that the scheduling failure is caused by a combination of resource insufficiency and untolerated taints across different nodes, not a single global problem.

Exam trap

The trap here is that candidates often assume all nodes share the same problem (e.g., all tainted or all out of CPU) and fail to read the event message carefully, which lists separate counts for each issue across different nodes.

How to eliminate wrong answers

Option A is wrong because the event message mentions insufficient CPU, not memory; the pod's resource request is for CPU, and no node is reported as lacking memory. Option C is wrong because only two of the three nodes have the master taint; one node has insufficient CPU instead, so not all nodes are tainted. Option D is wrong because only one node has insufficient CPU; the other two nodes have sufficient CPU but are blocked by the untolerated taint.

Full explanation →
15
MCQmedium

During a cluster upgrade, what is the correct order of operations for upgrading a node?

A.Upgrade kubelet, drain the node, then uncordon
B.Drain the node, uncordon, then upgrade kubelet
C.Drain the node, upgrade kubelet and kube-proxy, then uncordon
D.Uncordon the node, drain, then upgrade
AnswerC

This sequence represents the official Kubernetes standard operating procedure for node upgrades to ensure zero-downtime. Draining safely evicts running pods to other nodes, upgrading the kubelet and kube-proxy updates the node's control plane components while idle, and uncordoning finally marks the upgraded node as schedulable again. This minimizes service disruption and maintains cluster stability.

Why this answer

During a node upgrade, the node must first be drained to safely evict all pods and ensure workloads are rescheduled. Then, the kubelet and kube-proxy (which run as system services) are upgraded to match the control plane version. Finally, the node is uncordoned to make it schedulable again, allowing new pods to be placed on it.

Exam trap

The trap here is that candidates may think uncordoning can be done before upgrading (options B and D) or that upgrading can precede draining (option A), but the CKA requires strict adherence to the drain-upgrade-uncordon sequence to maintain workload availability and version compatibility.

How to eliminate wrong answers

Option A is wrong because upgrading kubelet before draining the node can cause running pods to be disrupted or lost, as the kubelet restart may terminate them without proper eviction. Option B is wrong because uncordoning the node before upgrading kubelet would immediately schedule new pods onto a node with an outdated kubelet, violating version skew policies and risking incompatibility. Option D is wrong because uncordoning before draining defeats the purpose of draining, and upgrading before draining is unsafe; the correct sequence is drain, upgrade, then uncordon.

Full explanation →
16
MCQmedium

A node in the cluster is reporting NotReady. You run 'journalctl -u kubelet' and see repeated errors: 'failed to get system container stats for "/system.slice/kubelet.service": failed to get cgroup stats'. What is the most likely cause?

A.Disk pressure on the node
B.The node is out of memory
C.Cgroup driver mismatch between kubelet and container runtime
D.The kubelet service is not running
AnswerC

This error occurs when the kubelet is configured to use one cgroup driver (such as systemd) while the container runtime (like containerd) is configured to use another (such as cgroupfs). Because both systems must agree on how to manage cgroup hierarchies, this mismatch prevents the kubelet from registering the node and managing container resources properly, leading to a NotReady status. Aligning both configurations to use the same driver, preferably systemd on modern Linux distributions, resolves the issue.

Why this answer

The error 'failed to get cgroup stats' indicates that the kubelet cannot read container cgroup statistics, which typically occurs when the cgroup driver used by kubelet (e.g., cgroupfs) does not match the driver used by the container runtime (e.g., systemd). This mismatch prevents the kubelet from properly monitoring container resource usage, causing the node to report NotReady.

Exam trap

The trap here is that candidates may misinterpret the cgroup stats error as a resource pressure issue (disk or memory) because 'stats' sounds like resource monitoring, but the actual root cause is a configuration mismatch between kubelet and the container runtime.

How to eliminate wrong answers

Option A is wrong because disk pressure would manifest as 'NodeHasDiskPressure' condition or 'eviction manager' warnings in kubelet logs, not a cgroup stats failure. Option B is wrong because out-of-memory conditions typically cause OOM kills or 'NodeHasMemoryPressure' condition, not a cgroup stats retrieval error. Option D is wrong because if the kubelet service were not running, 'journalctl -u kubelet' would show no logs or a 'unit not found' error, not repeated cgroup stats failures.

Full explanation →
17
MCQeasy

Which of the following creates a ConfigMap named 'my-config' from a file 'app.properties'?

A.kubectl create configmap my-config --from-literal=app.properties
B.kubectl create configmap my-config --from-file=app.properties
C.kubectl create configmap my-config --from-file=app.properties --from-env-file=app.properties
D.kubectl create configmap my-config --from-env-file=app.properties
AnswerB

This is the correct command because the `--from-file` flag instructs kubectl to read the entire contents of the specified file. It automatically creates a single key in the ConfigMap named `app.properties` with the file's complete text content as its value.

Why this answer

`kubectl create configmap my-config --from-file=app.properties` reads the file `app.properties` and creates a ConfigMap with a single key-value pair, where the key is the filename (app.properties) and the value is the entire file content. This is the standard way to create a ConfigMap from a file in Kubernetes.

Exam trap

The trap here is that candidates confuse `--from-file` (which imports a file as a single key-value pair) with `--from-env-file` (which imports a file as multiple key-value pairs, one per line), leading them to choose option D when the file is not in env-file format.

How to eliminate wrong answers

Option A is wrong because `--from-literal` expects a key=value pair (e.g., `--from-literal=key=value`), not a filename; using `--from-literal=app.properties` would create a ConfigMap with a key named 'app.properties' and an empty value, not the file content. Option C is wrong because combining `--from-file` and `--from-env-file` with the same file would cause a conflict or duplicate key error, as both flags attempt to read the same file in different formats (key-value vs. env-file parsing), and the command would fail or produce unexpected results. Option D is wrong because `--from-env-file` parses the file as a list of key=value lines (one per line) and creates separate keys for each line; if `app.properties` is not in that format (e.g., contains JSON or plain text), it will either fail or produce incorrect keys.

Full explanation →
18
Multi-Selecthard

You suspect a DNS issue within the cluster. Which TWO commands can you run from within a pod to test DNS resolution?

Select 2 answers
A.ping kubernetes.default.svc.cluster.local
B.kubectl exec -it pod-name -- /bin/sh
C.dig kubernetes.default.svc.cluster.local
D.curl http://kubernetes.default.svc.cluster.local
E.nslookup kubernetes.default.svc.cluster.local
AnswersC, E

dig is a dedicated DNS lookup utility that sends explicit DNS queries to the configured resolver and prints the full DNS response, including the resolved A/AAAA record and the answer section. When invoked from inside a pod, it directly interrogates the cluster DNS service (usually CoreDNS) for kubernetes.default.svc.cluster.local, so a successful answer proves that DNS resolution works end-to-end. It also distinguishes error types such as NXDOMAIN versus SERVFAIL, which makes it highly effective for isolating DNS-specific misconfigurations.

Why this answer

Options C and E are correct because both dig and nslookup are dedicated DNS query tools that directly resolve the name kubernetes.default.svc.cluster.local against the cluster DNS service (CoreDNS/kube-dns), letting you verify the returned A/AAAA records and diagnose resolution failures from inside the pod. dig queries the configured resolver and shows the ANSWER SECTION, while nslookup performs an equivalent name-resolution lookup, so either one specifically tests DNS rather than general connectivity. Option A (ping) is not a DNS test per se; it only triggers resolution as a side effect and may fail due to ICMP being blocked even when DNS works. Option B (kubectl exec -it pod-name -- /bin/sh) merely opens a shell in the pod and does not itself test DNS resolution.

Option D (curl http://kubernetes.default.svc.cluster.local) tests HTTP connectivity to the API server, not DNS, and can fail for reasons unrelated to name resolution.

Full explanation →
19
MCQeasy

You want to run a batch job that processes a queue and then terminates. The job should be run only once. Which Kubernetes resource should you use?

A.CronJob
B.DaemonSet
C.Job
D.Deployment
AnswerC

A Kubernetes Job is the correct resource for running a task to completion. It manages the creation of one or more pods and ensures that a specified number of them successfully terminate. If a pod fails, the Job controller can restart it according to its `restartPolicy`, guaranteeing that the batch processing task finishes its work on the queue and then gracefully exits, without being restarted unnecessarily.

Why this answer

A Kubernetes Job is designed to run a specified number of pods to completion, making it the correct choice for a batch process that runs once and then terminates. Unlike controllers that maintain a desired state (like Deployments or DaemonSets), a Job tracks pod completion and will not restart the pod once it succeeds, perfectly matching the requirement of a single execution.

Exam trap

The trap here is that candidates often confuse a Job with a CronJob, thinking that any batch processing requires a schedule, but the key distinction is that a CronJob adds a time-based trigger, while a plain Job is for one-off execution.

How to eliminate wrong answers

Option A is wrong because a CronJob is used for scheduling jobs to run at specific times or intervals (e.g., every hour), not for a one-time execution. Option B is wrong because a DaemonSet ensures that a copy of a pod runs on every node in the cluster, which is intended for long-running services (like log collectors or monitoring agents), not for a batch job that terminates. Option D is wrong because a Deployment manages a set of identical pods to maintain a desired number of replicas, ensuring they are always running; it is designed for stateless, long-lived applications, not for a job that runs to completion.

Full explanation →
20
Multi-Selectmedium

Which two of the following are valid methods for service discovery in Kubernetes?

Select 2 answers
A.Ingress controller
B.Consul agent running on each node
C.kubectl proxy
D.Environment variables injected into pods
E.DNS resolution via CoreDNS
AnswersD, E

When a pod starts, the kubelet injects environment variables for every Service that already exists in the pod's namespace, such as MY_SERVICE_SERVICE_HOST and MY_SERVICE_SERVICE_PORT, using the service's cluster IP and port values. Because these variables are set only at container creation time, they become stale if services are created or removed later, and they are namespace-scoped. This is a valid built-in discovery method but less dynamic than DNS.

Why this answer

Option D is correct because Kubernetes automatically injects environment variables (e.g., <SVCNAME>_SERVICE_HOST and <SVCNAME>_SERVICE_PORT) into containers for each active Service, allowing pods to discover service endpoints without an external mechanism. Option E is correct because CoreDNS runs as the cluster DNS add-on and resolves Service names (e.g., my-svc.my-namespace.svc.cluster.local) to ClusterIPs, which is the standard in-cluster service discovery method. Option A is incorrect because an Ingress controller only routes external HTTP/HTTPS traffic to Services; it is not a service discovery mechanism.

Option B is incorrect because Consul is a third-party tool, not a built-in Kubernetes service discovery method, and running a Consul agent per node is an external integration rather than a native Kubernetes mechanism. Option C is incorrect because kubectl proxy only creates a local proxy to the Kubernetes API server for accessing the API, not for discovering Services.

Exam trap

The trap here is that candidates may confuse external traffic management tools (Ingress) or third-party service meshes (Consul) with Kubernetes' native service discovery mechanisms, or mistake kubectl proxy (a debugging tool) for an in-cluster discovery method.

Full explanation →
21
MCQhard

A NetworkPolicy named 'default-deny-ingress' is applied to all pods in a namespace. The policy has no rules. An administrator then creates a new NetworkPolicy that allows ingress traffic to pods with label 'app: web' from any source using a podSelector with '{}'. Will traffic be allowed to pods labeled 'app: web'?

A.No, because the new policy's empty podSelector selects all pods but does not specify a source
B.Yes, because the default-deny policy is ignored when a new policy exists
C.No, because the default-deny policy takes precedence
D.Yes, because the new policy allows traffic to pods with label 'app: web'
AnswerD

Kubernetes NetworkPolicies are additive, meaning that if any policy explicitly allows a connection, that connection is permitted. Even with a default-deny ingress policy in place, a new NetworkPolicy that specifically targets pods with the label `app: web` and defines an `ingress` rule will create an exception. This new policy's allow rule will override the general deny for traffic destined for those specific pods.

Why this answer

A NetworkPolicy with a podSelector of '{}' selects all pods in the namespace, and the 'from' section with an empty podSelector (or no 'from' selector at all) allows traffic from any source. When multiple NetworkPolicies are applied, they are additive: if any policy allows the traffic, it is allowed, overriding a default-deny policy that has no rules. Thus, the new policy explicitly permits ingress to pods with label 'app: web', so traffic to those pods is allowed.

Exam trap

The trap here is that candidates often think a default-deny policy is absolute and cannot be overridden, or they misunderstand that an empty podSelector in the 'from' field means 'from all sources', leading them to incorrectly assume the new policy is incomplete.

How to eliminate wrong answers

Option A is wrong because the new policy's empty podSelector selects all pods, and the 'from' section with an empty podSelector (or no 'from' selector) means 'from any source' — it does specify a source implicitly as all sources. Option B is wrong because the default-deny policy is not ignored; rather, NetworkPolicies are evaluated together, and if any policy allows the traffic, it is permitted — the default-deny is overridden by the allow rule. Option C is wrong because the default-deny policy does not take precedence; in Kubernetes, NetworkPolicy rules are additive, and an explicit allow rule overrides a default-deny rule for the matching traffic.

Full explanation →
22
MCQmedium

A Kubernetes cluster is running with a single control plane node. The administrator wants to add a second control plane node for high availability. What is the first step after the new node has been provisioned with the required software?

A.Create a bootstrap token on the existing control plane node.
B.Run kubeadm join with the --control-plane flag on the new node.
C.Run kubeadm init on the new node.
D.Take a snapshot of etcd using etcdctl.
AnswerB

To expand a single control plane Kubernetes cluster into a highly available multi-control plane setup, the `kubeadm join` command is the correct utility. Specifically, including the `--control-plane` flag instructs `kubeadm` to not only join the new node to the cluster but also to install and configure all necessary control plane components (API server, scheduler, controller-manager, etcd member) on that node. This command orchestrates the secure integration and replication of critical cluster services, ensuring the new node can participate as a full control plane member.

Why this answer

The first step to add a second control plane node to an existing cluster is to run `kubeadm join` with the `--control-plane` flag on the new node. This command uses the existing control plane's API server to join the new node as a control plane member, automatically distributing certificates and configuring the etcd cluster. The `--control-plane` flag signals kubeadm to set up the additional control plane components (e.g., kube-apiserver, kube-controller-manager, kube-scheduler) and join the etcd cluster as a learner or voting member, depending on the etcd configuration.

Exam trap

The trap here is that candidates often confuse the process of adding a worker node (which uses `kubeadm join` without `--control-plane`) with adding a control plane node, or mistakenly think that `kubeadm init` or manual etcd backup steps are required first, when in fact the `--control-plane` flag handles the entire control plane join process automatically.

How to eliminate wrong answers

Option A is wrong because creating a bootstrap token on the existing control plane node is not the first step; bootstrap tokens are typically generated automatically by `kubeadm init` or can be created later, but the immediate prerequisite for joining a control plane node is to run `kubeadm join` with the `--control-plane` flag, which itself can use an existing token or a pre-created one. Option C is wrong because running `kubeadm init` on the new node would attempt to initialize a new, separate cluster, not join the existing one, and would cause a conflict with the existing control plane. Option D is wrong because taking a snapshot of etcd using `etcdctl` is a backup procedure, not a step required for adding a control plane node; the etcd cluster will be extended automatically by `kubeadm join --control-plane`.

Full explanation →
23
MCQmedium

A new Kubernetes administrator runs 'kubeadm join --token <token> <control-plane-ip>:6443 --discovery-token-ca-cert-hash sha256:<hash>' on a worker node. The join fails with 'error execution phase preflight: couldn't validate the identity of the API Server'. What is the most likely cause?

A.The --discovery-token-ca-cert-hash value is incorrect
B.The token has expired
C.The kubelet is not running on the worker node
D.The API server is not reachable on port 6443
AnswerA

The --discovery-token-ca-cert-hash parameter provides a critical security measure by ensuring the joining node can securely verify the identity of the control plane's Certificate Authority. If this hash value is incorrect, the joining node cannot trust the CA certificate presented by the API server during the TLS handshake. This leads to the 'couldn't validate the identity' error, as the cryptographic proof of authenticity fails, preventing the secure establishment of communication.

Why this answer

The error 'couldn't validate the identity of the API Server' indicates that the CA certificate hash provided with --discovery-token-ca-cert-hash does not match the actual hash of the API server's CA certificate. This hash is used to verify the API server's identity during the TLS bootstrap process. An incorrect hash value will cause the preflight check to fail, as the worker node cannot confirm it is connecting to the legitimate control plane.

Exam trap

CNCF often tests the distinction between token expiration and CA hash mismatch, where candidates confuse a token-related error with a TLS validation error, but the specific phrase 'couldn't validate the identity of the API Server' directly points to the CA certificate hash being incorrect.

How to eliminate wrong answers

Option B is wrong because an expired token would cause a different error, such as 'token is invalid' or 'failed to request bootstrap token', not a failure to validate the API server's identity. Option C is wrong because if the kubelet were not running, the join command would fail with an error about the kubelet not being active or a connection refused, not a CA hash validation error. Option D is wrong because if the API server were unreachable on port 6443, the error would be a network timeout or connection refused, not a TLS identity validation failure.

Full explanation →
24
MCQeasy

Which command rolls back a Deployment named 'web' to the previous revision?

A.kubectl rollout restart deployment web
B.kubectl rollout undo deployment web
C.kubectl rollout history deployment web --revision=previous
D.kubectl rollout revert deployment web
AnswerB

This is the correct command to roll back a deployment to its immediately preceding revision. By default, it targets the last successful revision in the deployment's history, updating the ReplicaSet controller to scale down the current active ReplicaSet and scale up the previous one.

Why this answer

The correct command to roll back a Deployment to the previous revision is `kubectl rollout undo deployment web`. This command reverts the Deployment to the last known stable revision by decrementing the revision number in the rollout history, effectively undoing the most recent change. It is the standard Kubernetes mechanism for rollback operations on Deployments, DaemonSets, and StatefulSets.

Exam trap

The trap here is that candidates confuse `rollout restart` (which restarts Pods without changing the revision) with `rollout undo` (which reverts to a previous revision), or they invent non-existent commands like `rollout revert` due to familiarity with other orchestration tools.

How to eliminate wrong answers

Option A is wrong because `kubectl rollout restart` triggers a new rollout by restarting Pods with the same configuration, not reverting to a previous revision. Option C is wrong because `kubectl rollout history --revision=previous` is not a valid flag; the correct syntax is `--revision=<number>` to view a specific revision's details, and it does not perform a rollback. Option D is wrong because `kubectl rollout revert` is not a valid kubectl command; the correct verb for rollback is `undo`, not `revert`.

Full explanation →
25
MCQmedium

You need to test DNS resolution from within a pod. Which command should you run?

A.kubectl describe svc <service-name>
B.kubectl logs <pod> | grep dns
C.kubectl exec <pod> -- nslookup <service-name>
D.kubectl run nslookup --image=busybox -- nslookup <service-name>
AnswerC

This command uses kubectl exec to run the nslookup utility directly inside the container of an existing pod, utilizing its specific network namespace and /etc/resolv.conf configuration. By querying the target service name from within the pod, you can accurately verify if the pod's configured DNS resolver (typically CoreDNS) is functioning and resolving names correctly. This is the standard method for diagnosing pod-level DNS resolution issues in a Kubernetes cluster.

Why this answer

`kubectl exec <pod> -- nslookup <service-name>` runs the `nslookup` command directly inside an existing pod, which tests DNS resolution from within the pod's network namespace. This is the most direct way to verify that the pod's DNS resolver (typically CoreDNS or kube-dns) can resolve a Kubernetes service name to a cluster IP, as it uses the pod's `/etc/resolv.conf` and the cluster DNS service.

Exam trap

The trap here is that candidates may choose Option D because it seems like a quick way to run a DNS test without needing an existing pod, but they overlook that creating a new pod can introduce different DNS settings (e.g., default `dnsPolicy: ClusterFirst` vs. a pod with `dnsPolicy: Default`) and that the pod must be cleaned up manually, whereas Option C directly tests the actual pod's DNS resolution without side effects.

How to eliminate wrong answers

Option A is wrong because `kubectl describe svc <service-name>` shows the service's metadata and endpoints, but does not perform any DNS resolution or test connectivity from within a pod. Option B is wrong because `kubectl logs <pod> | grep dns` only searches the pod's container logs for the string 'dns', which is not a standard DNS test and does not trigger or verify DNS resolution. Option D is wrong because `kubectl run nslookup --image=busybox -- nslookup <service-name>` creates a new pod to run nslookup, but it does not specify the `--rm` flag (to clean up) and, more critically, it runs in a separate pod that may have different DNS configuration or network policies, making it less reliable than using an existing pod that is already part of the application's network context.

Full explanation →
26
Multi-Selectmedium

A pod is stuck in 'Pending' state. Which TWO of the following are common causes?

Select 2 answers
A.The service account does not exist
B.A taint on the node that the pod does not tolerate
C.The pod's liveness probe is failing
D.Insufficient CPU or memory resources on any node
E.The pod's container image does not exist
AnswersB, D

Taints that are not tolerated prevent scheduling, causing Pending.

Why this answer

A pod enters 'Pending' state when it cannot be scheduled onto a node. Taints on a node with `NoSchedule` or `NoExecute` effects prevent pods that do not have matching tolerations from being scheduled there. This is a common cause because the scheduler skips tainted nodes unless the pod explicitly tolerates the taint, leaving the pod unscheduled and stuck in Pending.

Exam trap

The CKA exam often tests the distinction between pre-scheduling failures (Pending) and post-scheduling failures (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly select image or probe issues that occur after the pod is running.

Full explanation →
27
MCQeasy

Which CronJob schedule expression runs a job every day at midnight (00:00)?

A.0 * * * *
B.0 0 1 * *
C.0 0 * * *
D.* 0 * * *
AnswerC

This is the correct configuration because it explicitly targets minute 0 and hour 0 (midnight) while using wildcards for the day of the month, month, and day of the week. This ensures the job runs exactly once every single day of the year. It perfectly matches the standard crontab format used by Kubernetes CronJobs.

Why this answer

The CronJob schedule expression '0 0 * * *' specifies minute 0, hour 0 (midnight), every day of the month, every month, and every day of the week. This matches the requirement to run a job daily at 00:00.

Exam trap

The trap here is confusing the minute and hour fields: candidates often pick Option A ('0 * * * *') thinking it means 'once per day' because they misread the first zero as 'daily', but it actually runs every hour at minute 0.

How to eliminate wrong answers

Option A is wrong because '0 * * * *' runs at minute 0 of every hour, i.e., hourly, not daily at midnight. Option B is wrong because '0 0 1 * *' runs at midnight on the first day of every month, not every day. Option D is wrong because '* 0 * * *' runs every minute during hour 0 (from 00:00 to 00:59), which would execute 60 times, not once at midnight.

Full explanation →
28
MCQmedium

You are troubleshooting a pod that is failing to start due to a volume mount error. The pod spec references a PersistentVolumeClaim (PVC) named 'data-pvc'. You run 'kubectl get pvc data-pvc -n default' and see the status is 'Pending'. Which of the following is the MOST likely cause?

A.The PVC is not in the same namespace as the pod that is trying to use it.
B.The PVC's storage class does not exist, so the PVC cannot be provisioned.
C.There is no available PersistentVolume that matches the PVC's storage class, access mode, and capacity requirements.
D.The PVC is waiting for a pod to be scheduled before it can bind to a PersistentVolume.
AnswerC

A PVC remains Pending when the control plane cannot find a PV that satisfies its request. This could be because no PV exists, or existing PVs do not match the storage class, access modes, or capacity. If the PVC uses a storage class with a dynamic provisioner, the provisioner might be failing to create a volume. Checking the PVC events and the storage class configuration is necessary.

Why this answer

A PersistentVolumeClaim remains in Pending state when the Kubernetes control plane cannot find or provision a matching PersistentVolume. This typically happens when no PV meets the storage class, access mode, and capacity requirements, or when the dynamic provisioner fails. Investigating the PVC's events with 'kubectl describe pvc' will show the reason, such as 'no persistent volumes available for this claim' or provisioner errors.

Ensuring a suitable PV or a working storage class is the resolution.

Exam trap

The trap here is assuming the PVC is waiting for a pod, when in fact PVC binding is independent of pod scheduling and depends on PV availability or provisioning.

Full explanation →
29
Multi-Selecteasy

A pod is in 'ImagePullBackOff' state. Which TWO are valid first troubleshooting steps?

Select 2 answers
A.Check for network policies blocking egress to the registry
B.Check node CPU/memory resources
C.Verify the image exists in the configured registry
D.Check the image name spelling in the pod spec
E.Restart the kubelet on the node
AnswersC, D

ImagePullBackOff almost always follows a kubelet event that includes the exact registry response, such as 'manifest unknown', 'not found', or 'unauthorized'. Verifying the image exists in the configured registry, with the exact tag or digest specified in the pod spec, is the most direct confirmation of the root cause. Use `docker manifest inspect` or `skopeo inspect` against that registry, and remember that images can be deleted or made private after a pod was previously running. This check targets the registry artifact itself.

Why this answer

Option C is correct because ImagePullBackOff commonly results from the referenced image not existing in the registry (wrong tag, deleted image, or private repo requiring credentials), so verifying the image exists in the configured registry is a valid first step. Option D is correct because a simple typo in the image name or tag in the pod spec will cause the kubelet to fail pulling the image, and checking the spelling is a fast, direct troubleshooting action. Option A is not a typical first step since network policies rarely block egress to registries by default and the error would more likely be a timeout or connection refused rather than ImagePullBackOff.

Option B is unrelated because insufficient node CPU/memory produces Pending or Evicted states, not image pull failures. Option E is not a first step because restarting the kubelet is disruptive and does not address the root cause of an image pull error.

Full explanation →
30
Multi-Selecteasy

Which TWO of the following are valid kube-proxy modes?

Select 2 answers
A.eBPF
B.userspace
C.ipvs
D.iptables
E.kernelnet
AnswersC, D

Correct. ipvs is a supported mode.

Why this answer

Options C and D are correct because kube-proxy officially supports ipvs and iptables as its two main production-ready proxy modes: ipvs mode uses the Linux IPVS (IP Virtual Server) load balancer in the kernel for better scalability and performance with large numbers of services, while iptables mode programs netfilter rules to implement Service load balancing and is the long-standing default on most clusters. Both are documented, selectable via the --proxy-mode flag (e.g., --proxy-mode=ipvs or --proxy-mode=iptables), and are the modes Kubernetes validates and maintains. Option A (eBPF) is not a kube-proxy mode; eBPF-based service handling is provided by alternative CNI/dataplane implementations such as Cilium, not by kube-proxy itself.

Option B (userspace) was a legacy kube-proxy mode but is deprecated and removed in modern Kubernetes, so it is not a valid current answer. Option E (kernelnet) is not a real kube-proxy mode at all.

Exam trap

Candidates often mistake 'userspace' as still being a valid mode, but it was officially removed in Kubernetes v1.26. Additionally, while eBPF is a popular technology for Kubernetes networking (e.g., Cilium), it is not an official built-in kube-proxy mode.

Full explanation →
31
MCQeasy

Which of the following is a valid command to create a PersistentVolume named 'pv-demo' using a YAML manifest file named 'pv.yaml'?

A.kubectl create pv -f pv.yaml
B.kubectl apply -f pv.yaml
C.kubectl create persistentvolume -f pv.yaml
D.kubectl run pv-demo --image=pv --restart=Never
AnswerB

This is the correct and standard declarative command to create or update Kubernetes resources, including PersistentVolumes, from a local or remote YAML manifest. It submits the configuration to the Kubernetes API server, which then provisions or updates the resource state accordingly.

Why this answer

`kubectl apply -f pv.yaml` is the standard Kubernetes command to create or update resources from a YAML manifest file. It reads the manifest, which defines a PersistentVolume named 'pv-demo', and sends it to the API server for creation. This command works for any resource type defined in the file, including PersistentVolumes.

Exam trap

The trap here is that candidates often confuse the `kubectl create` subcommand syntax, thinking that `kubectl create pv` or `kubectl create persistentvolume -f` are valid, when in fact `kubectl apply -f` is the correct and most common way to create resources from a manifest file.

How to eliminate wrong answers

Option A is wrong because `kubectl create pv` is not a valid subcommand; the correct subcommand for creating a PersistentVolume is `kubectl create persistentvolume` (or the short form `pv` is not supported under `create`). Option C is wrong because `kubectl create persistentvolume -f pv.yaml` is syntactically incorrect — the `-f` flag is not used with `kubectl create` for resource-specific subcommands; instead, you must use `kubectl create -f pv.yaml` or `kubectl apply -f pv.yaml`. Option D is wrong because `kubectl run` creates a Pod, not a PersistentVolume; the `--image=pv` flag would attempt to pull a non-existent image, and `--restart=Never` only affects Pod restart policy, not resource type.

Full explanation →
32
MCQeasy

What is the default pod phase when a pod is first created but not yet running?

A.Running
B.Pending
C.Succeeded
D.Unknown
AnswerB

Pending is the correct phase for a pod immediately after it is created, because the pod object has been persisted in etcd but the scheduler has not yet assigned it to a node. Once scheduled, the phase still stays Pending while the container runtime pulls images, creates containers, and starts processes. Only after those actions complete does the phase transition to Running.

Why this answer

When a Pod is first created, it enters the Pending phase before it is scheduled onto a node and its containers are started. The Pending phase indicates that the Pod has been accepted by the Kubernetes API server but one or more containers are not yet running, often because the image is being pulled or the node is not ready. This is the default initial phase as defined in the Kubernetes Pod lifecycle.

Exam trap

CNCF often tests the misconception that a newly created Pod immediately enters the Running phase, but the correct initial phase is always Pending until the scheduler assigns a node and the kubelet starts the containers.

How to eliminate wrong answers

Option A is wrong because Running is the phase assigned only after at least one container in the Pod has started and is running, not at creation time. Option C is wrong because Succeeded indicates that all containers in the Pod have terminated successfully, which cannot happen before the Pod runs. Option D is wrong because Unknown is a phase used when the state of the Pod cannot be obtained, typically due to a communication failure with the node, not at creation.

Full explanation →
33
MCQmedium

A pod is in ImagePullBackOff state. You run 'kubectl describe pod mypod' and see 'Failed to pull image "myapp:latest": rpc error: code = Unknown desc = Error response from daemon: manifest for myapp:latest not found: manifest unknown'. What is the most likely cause?

A.The image tag does not exist in the registry
B.The node has insufficient disk space
C.The image is too large and exceeds the node's disk quota
D.The container registry requires authentication
AnswerA

The 'manifest unknown' error in the kubectl describe pod event is the definitive signature: the registry does not have a manifest for the referenced tag, so either the tag was never pushed, was deleted, or contains a typo. Unlike authentication or storage failures, this is a content-addressing issue: the digest cannot be resolved because that tag's manifest is absent. Confirm by inspecting the image name and tag exactly as written and, if needed, querying the registry API directly.

Why this answer

The error indicates the image tag 'latest' does not exist in the registry. The tag may have been deleted or never pushed.

Full explanation →
34
MCQmedium

A CronJob runs every hour. The job takes 45 minutes to complete. What is the default behavior if the next scheduled time occurs while the previous job is still running?

A.The next job is queued and starts after the previous finishes
B.The next job is skipped
C.The next job starts immediately, running concurrently
D.The CronJob is suspended
AnswerC

CronJobs default to a concurrency policy of Allow, so a new job is created at each scheduled time regardless of whether the previous run has finished. With a 45-minute runtime and hourly schedule, the next job therefore starts and runs concurrently with the still-executing one.

Why this answer

By default, CronJobs in Kubernetes have a concurrencyPolicy of 'Allow'. This means that if a new job is scheduled while a previous job is still running, the new job starts immediately and runs concurrently with the previous one. Option C correctly describes this default behavior.

If you want to prevent concurrent executions, you must explicitly set concurrencyPolicy to 'Forbid'.

Exam trap

The trap in this question is that many candidates mistakenly believe the default concurrencyPolicy for a CronJob is 'Forbid' to prevent resource exhaustion. However, the default is actually 'Allow', meaning overlapping jobs will run concurrently unless explicitly configured otherwise.

How to eliminate wrong answers

Option A is wrong because the default `concurrencyPolicy` is `Forbid`, not `Queue`; Kubernetes does not queue jobs—it either allows, forbids, or replaces them. Option B is wrong because while `Forbid` is the default, the question explicitly marks C as correct, meaning the scenario assumes `Allow` is set; skipping is the behavior of `Forbid`, not the default behavior when `Allow` is configured. Option D is wrong because suspending a CronJob is controlled by the `suspend` field (set to `true`), which is independent of concurrency handling and does not occur automatically when a job overlaps.

Full explanation →
35
MCQmedium

A DevOps team needs to deploy a stateful application that requires persistent storage with ReadWriteMany access mode across multiple pods running on different nodes. Which Kubernetes resource should they use to provision the storage?

A.A hostPath volume
B.A PersistentVolume with access mode ReadWriteOnce
C.A PersistentVolume with access mode ReadWriteMany
D.An emptyDir volume
AnswerC

A PersistentVolume with access mode ReadWriteMany allows multiple pods across different nodes to simultaneously read and write to the same storage volume, satisfying the stem’s requirement for concurrent access from pods scheduled on distinct nodes. This access mode directly addresses the constraint of multi-node, multi-pod stateful workloads, whereas ReadWriteOnce would restrict access to a single node.

Why this answer

ReadWriteMany (RWX) is the only access mode that allows multiple pods across different nodes to simultaneously read and write to the same persistent storage volume. A PersistentVolume with access mode ReadWriteMany meets the requirement for a stateful application needing concurrent access from pods running on different nodes, typically backed by network filesystems like NFS, GlusterFS, or CephFS.

Exam trap

The trap here is that candidates often confuse ReadWriteOnce (RWO) with multi-pod access, but RWO restricts access to a single node, not a single pod, so multiple pods on the same node can share an RWO volume, but pods on different nodes cannot, making it unsuitable for the stated requirement.

How to eliminate wrong answers

Option A is wrong because a hostPath volume mounts a directory from the host node's filesystem into the pod, which does not support multi-node access; pods scheduled on different nodes would see different host directories, and it is not a persistent storage abstraction managed by Kubernetes. Option B is wrong because a PersistentVolume with access mode ReadWriteOnce (RWO) can only be mounted as read-write by a single node at a time, preventing concurrent access from pods on different nodes. Option D is wrong because an emptyDir volume is ephemeral and tied to the pod's lifecycle; it is created empty when a pod starts and is deleted when the pod is removed, providing no persistent storage across pod restarts or multi-node access.

Full explanation →
36
MCQhard

Refer to the exhibit. A Kubernetes cluster was initialized using kubeadm with the command shown. After initialization, the cluster nodes are in NotReady state. Which is the most likely missing step?

A.Increase the apiserver-advertise-address to match the node's external IP.
B.Install a pod network add-on such as Flannel.
C.Run kubeadm join on the control plane node.
D.Restart the kubelet service on all nodes.
AnswerB

Correct: After `kubeadm init`, the control plane node starts with a `NotReady` status because no Container Network Interface (CNI) plugin has been deployed to create the pod network. The kubelet's readiness condition depends on `NetworkReady` being true, which requires a CNI plugin like Flannel (or Calico, Cilium, etc.) to set up the pod CIDR, routing, and network interfaces. Until a CNI plugin is installed, the node's `Ready` condition remains `False` or `Unknown`, even though all control-plane pods (e.g., etcd, kube-apiserver) may be running. Flannel specifically configures an overlay network using the pod CIDR, enabling pod-to-pod communication, and once applied, the node should transition to `Ready` after the CNI pod starts and the kubelet detects the network is ready.

Why this answer

The kubeadm init command only initializes the control plane. To make the nodes ready, a pod network must be installed. The exhibit shows no pod network add-on being applied, and the --pod-network-cidr flag indicates a specific CIDR for the pod network (10.244.0.0/16) which is typically used with Flannel.

Without installing a CNI plugin, nodes remain NotReady.

Full explanation →
37
MCQeasy

Which command correctly backs up etcd data using etcdctl with API version 3?

A.ETCDCTL_API=3 etcdctl snapshot save /backup/snapshot.db
B.etcdctl backup /backup/snapshot.db
C.etcdctl snapshot-backup /backup/snapshot.db
D.ETCDCTL_API=3 etcdctl --snapshot /backup/snapshot.db
AnswerA

This command correctly sets the environment variable `ETCDCTL_API=3` to enforce the use of the v3 API, which is mandatory for modern Kubernetes clusters. It then invokes the proper `snapshot save` subcommand to write a consistent point-in-time backup of the etcd database to the specified file path.

Why this answer

Etcdctl requires the environment variable `ETCDCTL_API=3` to use the v3 API, which supports the `snapshot save` command for creating a consistent point-in-time backup of etcd data. The command `ETCDCTL_API=3 etcdctl snapshot save /backup/snapshot.db` correctly specifies the API version and the subcommand to save a snapshot to the given file path.

Exam trap

The trap here is that candidates may confuse the deprecated v2 API `etcdctl backup` command with the v3 API `snapshot save` command, or incorrectly assume a flag like `--snapshot` can replace the required subcommand structure.

How to eliminate wrong answers

Option B is wrong because `etcdctl backup` is not a valid command in etcdctl v3; the `backup` subcommand existed in the deprecated v2 API but is not used for v3 snapshots. Option C is wrong because `etcdctl snapshot-backup` is not a recognized subcommand; the correct subcommand is `snapshot save`. Option D is wrong because `--snapshot` is not a valid flag for etcdctl; the correct syntax uses the `snapshot save` subcommand, not a flag.

Full explanation →
38
MCQeasy

Which component runs on every node in a Kubernetes cluster and ensures containers are running in a pod?

A.kubelet
B.kube-scheduler
C.container runtime
D.kube-proxy
AnswerA

The kubelet is the Kubernetes node agent that runs on every node, including control-plane nodes. It registers the node with the API server, watches for Pod objects bound to that node, and continually drives the actual state of containers toward the desired PodSpec. It performs liveness, readiness, and startup probes and reports pod/node status back to the API server. Because it is the component that owns the pod lifecycle on a node, it is the only component in this list that is a required Kubernetes component on every node.

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 described in PodSpecs are running and healthy by communicating with the container runtime via the CRI (Container Runtime Interface). Without the kubelet, no pod or container lifecycle management can occur on that node.

Exam trap

The trap here is that candidates confuse the container runtime (which actually runs containers) with the kubelet (which orchestrates them), leading them to pick 'container runtime' because they think it directly ensures containers are running, but the kubelet is the agent that manages the pod lifecycle and delegates to the runtime.

How to eliminate wrong answers

Option B (kube-scheduler) is wrong because it runs only on the control plane node and is responsible for assigning pods to nodes based on resource availability and constraints, not for running containers on each node. Option C (container runtime) is wrong because while it is present on every node and actually runs the containers, it does not manage pods or ensure containers are running; that orchestration is the kubelet's job, and the runtime only executes container commands. Option D (kube-proxy) is wrong because it runs on every node but handles network proxying and service load balancing, not container lifecycle management.

Full explanation →
39
MCQhard

A Pod is running but cannot connect to a Service. You have verified that the Service endpoints are correct. Which of the following is the most likely cause if the Pod is using hostNetwork: true?

A.The kube-proxy is not running on the node
B.The Service is not defined correctly
C.The container image is missing networking tools
D.The Pod uses hostNetwork and cannot resolve the ClusterIP due to DNS configuration
AnswerD

When a Pod is configured with `hostNetwork: true`, it directly uses the node's network namespace, bypassing the Kubernetes CNI network. Consequently, such a pod inherits the node's `/etc/resolv.conf` for DNS resolution instead of the cluster's internal DNS (CoreDNS/kube-dns). The node's DNS resolver typically cannot resolve Kubernetes Service ClusterIPs, which are internal to the cluster's DNS domain, leading to name resolution failures for services. This specific DNS misconfiguration prevents the `hostNetwork` pod from finding the Service's IP address.

Why this answer

When a Pod uses `hostNetwork: true`, it shares the node's network namespace and directly uses the host's network stack. ClusterIP Services are virtual IPs managed by iptables or IPVS rules on the node, but these rules are typically applied only to the host's network namespace. However, the most common issue is that the Pod's DNS resolver (e.g., `/etc/resolv.conf`) is configured to resolve the Service name via the cluster's DNS (CoreDNS/kube-dns), which returns a ClusterIP.

Since the Pod is on the host network, it may not have the necessary iptables rules to route traffic to the ClusterIP, or the DNS configuration may point to a DNS server that is not reachable from the host network (e.g., the cluster DNS service IP itself). Option D correctly identifies that the Pod cannot resolve the ClusterIP due to DNS configuration, as the Pod's DNS settings are inherited from the node but may not include the cluster DNS server, or the cluster DNS is not accessible from the host network.

Exam trap

The trap here is that candidates assume `hostNetwork: true` gives the Pod full access to all cluster services, but they overlook that DNS resolution for ClusterIP Services depends on the cluster DNS being reachable and properly configured in the Pod's resolv.conf, which is not automatically set when using hostNetwork.

How to eliminate wrong answers

Option A is wrong because kube-proxy runs on every node and is responsible for implementing Service rules (e.g., iptables/IPVS); if it were not running, no Pod (hostNetwork or not) would reach any Service, but the question states endpoints are correct, implying kube-proxy is functional. Option B is wrong because the question explicitly states that the Service endpoints are correct, meaning the Service definition itself is valid and has healthy endpoints. Option C is wrong because missing networking tools (e.g., curl, ping) would prevent the user from testing connectivity, but the Pod's inability to connect is a network-layer issue, not a tool availability issue; the Pod could still connect via raw sockets or other means if the network path worked.

Full explanation →
40
Multi-Selectmedium

Which THREE of the following are valid methods for service discovery in Kubernetes?

Select 3 answers
A.kubectl port-forward
B.Environment variables (e.g., SERVICE_NAME_SERVICE_HOST)
C.Ingress rules
D.DNS lookups using CoreDNS
E.Kubernetes API queries via kubectl or API calls
AnswersB, D, E

Kubernetes injects environment variables for each active Service into pod containers, exposing values such as SERVICE_NAME_SERVICE_HOST. This lets applications discover service endpoints without querying DNS or the API, satisfying the stem's valid service discovery methods.

Why this answer

Environment variables (B) are a valid service-discovery mechanism because kubelet injects variables such as SERVICE_NAME_SERVICE_HOST and SERVICE_NAME_SERVICE_PORT for each Service into Pods at creation time, letting containers locate dependencies without an external registry. DNS lookups using CoreDNS (D) are the canonical discovery method: CoreDNS serves records like <service>.<namespace>.svc.cluster.local and SRV records for named ports, resolving Service ClusterIPs and headless endpoints. Kubernetes API queries (E) are valid because clients can list/watch Service and Endpoints/EndpointSlice objects via kubectl or direct API calls to discover backends dynamically. kubectl port-forward (A) merely tunnels a local port to a Pod or Service for debugging and does not provide in-cluster discovery, while Ingress rules (C) only expose HTTP/HTTPS routes from outside the cluster and are not a discovery mechanism for workloads.

Exam trap

The trap here is that candidates confuse `kubectl port-forward` (a manual, ephemeral tunnel) with a built-in discovery mechanism, or mistake Ingress (external routing) for internal service-to-service communication.

Full explanation →
41
MCQhard

You are setting up a new Kubernetes cluster using kubeadm. You run 'kubeadm init --pod-network-cidr=10.244.0.0/16' on the control plane node. The command fails with: '[preflight] Some fatal errors occurred: [ERROR CRI]: container runtime is not running: output: time="..." level=fatal msg="validate service connection: CRI v1 runtime API is not implemented for endpoint 'unix:///var/run/containerd/containerd.sock': rpc error: code = Unimplemented desc = unknown service runtime.v1.RuntimeService'"'. What is the most likely cause?

A.The --pod-network-cidr flag is incorrect
B.The kubelet version is incompatible with containerd
C.The containerd runtime does not support the CRI v1 API; it may be an older version that only supports v1alpha2
D.The containerd service is not running
AnswerC

Modern Kubernetes releases require the Container Runtime Interface (CRI) v1 API to communicate with the container runtime. Older versions of containerd (prior to v1.6.0) only implement the deprecated v1alpha2 CRI API, causing the kubelet's initialization handshake to fail when it attempts to connect. Upgrading containerd to v1.6.0 or later, or correctly configuring its CRI plugin, is required to enable v1 API support.

Why this answer

The error message indicates that the containerd socket is reachable but the CRI v1 API (runtime.v1.RuntimeService) is not implemented. This typically occurs when containerd is an older version that only supports the CRI v1alpha2 API. Kubernetes 1.24+ defaults to the CRI v1 API, so an older containerd without v1 support will fail during kubeadm init.

Exam trap

The trap here is that candidates often assume the error means the container runtime is not running at all (Option D), but the detailed error message clearly indicates the socket is reachable and the issue is an API version mismatch, not a service outage.

How to eliminate wrong answers

Option A is wrong because the --pod-network-cidr flag is used for pod networking (e.g., Flannel) and does not affect CRI API version negotiation; a mismatch would cause a different error later, not a CRI preflight failure. Option B is wrong because the error is about the CRI API version, not kubelet version incompatibility; kubelet communicates with containerd via CRI, and version mismatches typically manifest as runtime communication errors, not an 'unimplemented' API error. Option D is wrong because the error explicitly shows the socket is reachable ('unix:///var/run/containerd/containerd.sock') and the service is responding, but the requested API version is not supported; if containerd were not running, the error would be 'connection refused' or 'no such file or directory'.

Full explanation →
42
MCQmedium

A pod is in 'ImagePullBackOff' state. You run 'kubectl describe pod' and see the event: 'Failed to pull image "nginx:latest": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 8.8.8.8:53: no such host'. What is the MOST likely cause?

A.The container runtime is not installed
B.The image tag is incorrect
C.The registry requires authentication
D.DNS resolution is failing on the node
AnswerD

The presence of a 'no such host' or 'lookup failed' error in the pod's event log indicates that the node's local resolver cannot translate the registry's domain name into an IP address. Because the Kubelet cannot resolve the external registry's FQDN, it fails to initiate the TCP handshake, ultimately causing the container pull to fail and triggering the 'ImagePullBackOff' state.

Why this answer

The error message 'no such host' when trying to resolve 'registry-1.docker.io' on DNS server 8.8.8.8:53 indicates that the node's DNS resolution is failing. Kubernetes nodes rely on DNS to resolve container registry hostnames; if the node cannot resolve the registry's domain, the container runtime cannot pull the image, resulting in ImagePullBackOff. This is a node-level DNS issue, not a container runtime or image tag problem.

Exam trap

The trap here is that candidates may confuse DNS resolution failures with authentication or image tag issues, but the specific 'no such host' error in the event message directly points to a DNS problem on the node.

How to eliminate wrong answers

Option A is wrong because the container runtime is clearly working (it returns an error response from the daemon, proving the runtime is installed and running). Option B is wrong because the error is about DNS resolution, not an incorrect image tag; 'nginx:latest' is a valid tag and would not cause a 'no such host' error. Option C is wrong because authentication failures produce different errors (e.g., 'denied: requested access to the resource is denied' or 'unauthorized: authentication required'), not a DNS lookup failure.

Full explanation →
43
MCQeasy

You are tasked with troubleshooting a production Kubernetes cluster. A user reports that they cannot access a web application running in the cluster. The application is deployed as a Deployment named 'frontend' with 2 replicas, exposed via a Service of type LoadBalancer. You have kubectl access to the cluster. You run 'kubectl get pods -l app=frontend' and see both pods are Running and Ready. You run 'kubectl get svc frontend' and see the Service has an external IP of 192.168.1.100. However, when you curl http://192.168.1.100 from a machine outside the cluster, you get a connection timeout. You are able to curl the pod IPs directly from within the cluster and get a response. Which of the following is the most likely cause of the issue?

A.The Service selector does not match the pod labels.
B.The cloud provider's load balancer is not properly configured or the security group/firewall is blocking traffic to the node ports.
C.The NodePort service type is not enabled in the cluster.
D.The Ingress resource is missing or misconfigured.
AnswerB

When internal cluster communication works but external traffic times out, the issue lies in the external network path. Misconfigured cloud load balancers or restrictive security groups/firewalls blocking the NodePort range (typically 30000-32767) prevent external packets from reaching the cluster nodes.

Why this answer

The pods are running and ready, and the service has an external IP, but external access fails with a connection timeout while internal access to pod IPs works. This indicates the cloud provider's load balancer is not properly routing traffic to the node ports, or a security group/firewall is blocking inbound traffic on the node port range (30000-32767). The load balancer must forward traffic to the node ports, and the nodes must allow that traffic.

Exam trap

The trap here is that candidates assume a LoadBalancer Service automatically works end-to-end, but the CKA exam tests the understanding that cloud provider integration (security groups, load balancer health checks) is a separate layer that can fail even when Kubernetes components are healthy.

How to eliminate wrong answers

Option A is wrong because if the Service selector did not match the pod labels, the endpoints would be empty and curl to pod IPs would fail, but the user reports internal curl to pod IPs works. Option C is wrong because NodePort is not a service type that needs to be 'enabled'; it is automatically assigned when a Service of type LoadBalancer is created, and the cluster always supports NodePort. Option D is wrong because an Ingress resource is not required for a LoadBalancer Service; the Service itself provides external access via the load balancer, and the issue is a connection timeout, not a routing or hostname mismatch.

Full explanation →
44
MCQmedium

Which of the following YAML snippets correctly defines a Kubernetes Deployment with 3 replicas and a rolling update strategy?

A.apiVersion: extensions/v1beta1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: RollingUpdate
B.apiVersion: apps/v1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1
C.apiVersion: apps/v1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1
D.apiVersion: apps/v1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: OnDelete
AnswerB

This YAML snippet correctly defines a Kubernetes Deployment. It utilizes the stable `apps/v1` API version, which is the standard for Deployments in current Kubernetes releases. Furthermore, it explicitly configures the `RollingUpdate` strategy with `maxUnavailable` and `maxSurge` parameters, ensuring a controlled and highly available update process by specifying how many pods can be unavailable or created beyond the desired replica count during an update.

Why this answer

It uses the stable `apps/v1` API version, specifies 3 replicas, and defines a `RollingUpdate` strategy with both `maxUnavailable` and `maxSurge` set to 1. This ensures that during an update, at most one Pod is unavailable and at most one extra Pod is created, maintaining application availability.

Exam trap

The trap here is that candidates often forget that `rollingUpdate` subfields must be properly nested under `strategy` and that `extensions/v1beta1` is deprecated, leading them to choose Option A or misindented Option C, while Option D tests confusion between Deployment and DaemonSet update strategies.

How to eliminate wrong answers

Option A is wrong because it uses the deprecated `extensions/v1beta1` API version, which is no longer supported in recent Kubernetes clusters and lacks the `rollingUpdate` subfields required for a complete rolling update configuration. Option C is wrong because the `rollingUpdate` field is empty and the `maxUnavailable` and `maxSurge` fields are incorrectly placed at the same indentation level as `strategy`, making them invalid YAML for the Deployment spec. Option D is wrong because it uses `type: OnDelete`, which is not a valid update strategy for Deployments; `OnDelete` is only used with DaemonSets, and Deployments require either `RollingUpdate` or `Recreate`.

Full explanation →
45
MCQmedium

A ClusterRole named 'pod-reader' exists that grants get, list, and watch permissions on pods. You want to bind this ClusterRole to a user 'john' in the 'development' namespace only. Which resource should you create?

A.RoleBinding 'john-pod-reader' in namespace 'development' referencing ClusterRole 'pod-reader' and user 'john'
B.Add user 'john' to the 'pod-reader' ClusterRole definition
C.Role 'pod-reader' in namespace 'development'
D.ClusterRoleBinding 'john-pod-reader' binding 'pod-reader' to user 'john'
AnswerA

This option correctly identifies the mechanism for granting namespace-specific permissions derived from a cluster-wide role. A RoleBinding created within the 'development' namespace, referencing the 'pod-reader' ClusterRole and the user 'john', effectively scopes the ClusterRole's permissions to only that specific namespace. This ensures 'john' can read pods exclusively within 'development', adhering to the principle of least privilege.

Why this answer

A RoleBinding in a specific namespace can reference a ClusterRole to grant its permissions only within that namespace. Since the requirement is to bind the existing 'pod-reader' ClusterRole to user 'john' exclusively in the 'development' namespace, a RoleBinding named 'john-pod-reader' in the 'development' namespace is the correct resource. This allows the ClusterRole's pod read permissions to be scoped down to a single namespace.

Exam trap

The trap here is that candidates often confuse ClusterRoleBinding with RoleBinding when binding a ClusterRole, forgetting that a ClusterRoleBinding grants cluster-wide access, while a RoleBinding scopes the ClusterRole's permissions to a single namespace.

How to eliminate wrong answers

Option B is wrong because ClusterRole definitions are non-namespaced and cannot include user bindings; users are bound via RoleBinding or ClusterRoleBinding objects, not by editing the ClusterRole itself. Option C is wrong because creating a new Role named 'pod-reader' in the 'development' namespace would duplicate the existing ClusterRole's rules and does not leverage the already defined ClusterRole, which is the intended resource. Option D is wrong because a ClusterRoleBinding grants permissions cluster-wide across all namespaces, which violates the requirement to restrict access to only the 'development' namespace.

Full explanation →
46
MCQeasy

Which annotation is commonly used to trigger a rollout restart of a Deployment when a ConfigMap is updated?

A.configmap.kubernetes.io/update-trigger
B.field.cattle.io/updateStrategy
C.kubectl.kubernetes.io/last-applied-configuration
D.kubectl.kubernetes.io/restartedAt
AnswerD

The `kubectl.kubernetes.io/restartedAt` annotation is a widely adopted method to force a deployment rollout restart. When `kubectl rollout restart deployment/<name>` is executed, it patches the deployment's Pod template metadata with this annotation, setting its value to the current timestamp. This modification to the Pod template triggers a new rollout, causing all existing pods to be gracefully replaced with new ones, effectively picking up any updated ConfigMap or Secret data.

Why this answer

The annotation `kubectl.kubernetes.io/restartedAt` is commonly used with `kubectl rollout restart` to trigger a rolling restart of a Deployment. When a ConfigMap is updated, Pods using it via `envFrom` or `volumes` are not automatically updated; adding or updating this annotation on the Deployment's pod template forces a new ReplicaSet to be created, picking up the latest ConfigMap data.

Exam trap

The trap here is that candidates often confuse the annotation used for rollout restarts with non-existent or vendor-specific annotations, or they mistakenly think that updating a ConfigMap automatically triggers a Pod restart without any additional action.

How to eliminate wrong answers

Option A is wrong because `configmap.kubernetes.io/update-trigger` is not a standard Kubernetes annotation; the correct mechanism for triggering updates on ConfigMap changes is through checksum annotations or `kubectl rollout restart`. Option B is wrong because `field.cattle.io/updateStrategy` is a Rancher-specific annotation used for cattle-style update strategies, not a standard Kubernetes annotation for rollout restarts. Option C is wrong because `kubectl.kubernetes.io/last-applied-configuration` is used by `kubectl apply` to store the previous configuration for diff and merge purposes, not to trigger a rollout restart.

Full explanation →
47
Multi-Selecthard

Which TWO of the following are true about a HorizontalPodAutoscaler (HPA) using average CPU utilization? (Select TWO)

Select 2 answers
A.The HPA calculates utilization as the average CPU usage across all pods divided by the CPU request per pod
B.If a pod does not have a CPU request, the HPA cannot calculate its CPU utilization
C.The HPA target is an absolute CPU value, not a percentage
D.If the average CPU utilization exceeds the target, the HPA will scale down
E.The HPA uses CPU limits in its calculation of average utilization
AnswersA, B

The HPA computes pod CPU utilization as the measured CPU usage for each pod divided by that pod's CPU request, then averages these per-pod utilization ratios across the entire set of selected pods. If every pod has the same CPU request, this equals the total usage across pods divided by a single request value, but the canonical definition is per-pod usage/request averaged.

Why this answer

Option A is correct because the HPA computes average CPU utilization by taking the mean CPU usage across all targeted pods and dividing it by each pod's CPU request, expressing the result as a percentage of the request. Option B is correct because the utilization formula depends on the CPU request as its denominator; if a pod has no CPU request set, the HPA cannot compute a utilization percentage for it and will not act on that metric. Option C is wrong because the HPA target for CPU utilization is expressed as a percentage of the request (e.g., 50%), not an absolute CPU value.

Option D is wrong because exceeding the target utilization triggers scale up, not scale down. Option E is wrong because the HPA uses CPU requests, not CPU limits, as the baseline for utilization calculations.

Exam trap

The trap here is that candidates often confuse CPU requests with CPU limits, assuming limits are used in HPA calculations, or they mistakenly think the HPA scales down when utilization is high.

Full explanation →
48
MCQmedium

A pod 'my-pod' in the 'default' namespace cannot resolve the service 'db-service' in the 'production' namespace. Which DNS name should be used to reach the service from 'my-pod'?

A.db-service
B.db-service.production.svc.cluster.local
C.db-service.production.pod.cluster.local
D.production.db-service.svc.cluster.local
AnswerB

This is the fully qualified domain name (FQDN) for a Service in the production namespace, following the required Kubernetes DNS pattern: <service>.<namespace>.svc.<cluster-domain>. Since it is an absolute name with the 'svc' subdomain, it resolves to the ClusterIP of db-service regardless of the pod's namespace. The default cluster domain is 'cluster.local', so this name is valid and reachable from any namespace.

Why this answer

Kubernetes DNS resolves services across namespaces using the fully qualified domain name (FQDN) format `<service>.<namespace>.svc.cluster.local`. Since 'my-pod' is in the 'default' namespace and 'db-service' is in the 'production' namespace, the short name 'db-service' will not resolve; the FQDN must include the namespace and the cluster domain suffix to reach the service.

Exam trap

The trap here is that candidates assume the short service name works across namespaces or confuse the order of namespace and service in the FQDN, leading them to pick Option A or D, while Option C exploits the common misconception that pods use the same DNS suffix as services.

How to eliminate wrong answers

Option A is wrong because 'db-service' only resolves within the same namespace; it does not include the namespace or cluster domain, so it fails for cross-namespace resolution. Option C is wrong because the DNS suffix for services is '.svc.cluster.local', not '.pod.cluster.local' (which is used for pod hostnames). Option D is wrong because the correct FQDN format is '<service>.<namespace>.svc.cluster.local', not '<namespace>.<service>.svc.cluster.local' — the namespace comes after the service name, not before.

Full explanation →
49
Multi-Selectmedium

Which TWO of the following are required for dynamic provisioning of PersistentVolumes using a StorageClass?

Select 2 answers
A.A StorageClass with allowVolumeExpansion: true
B.A StorageClass with volumeBindingMode: WaitForFirstConsumer
C.A PersistentVolumeClaim that references the StorageClass
D.A default StorageClass must be defined
E.A StorageClass with a provisioner defined
AnswersC, E

A PersistentVolumeClaim that references the StorageClass is indeed required for dynamic provisioning. The PVC must set its storageClassName field to the name of a StorageClass that has a provisioner; this reference tells the Kubernetes controller which provisioner should create a PV matching the PVC's requested size and access modes. Without this reference, the PVC either remains pending or binds to a pre-existing statically provisioned PV, but it cannot trigger creation of a new PV.

Why this answer

Option C is correct because dynamic provisioning is triggered by a PersistentVolumeClaim that specifies the StorageClass via its storageClassName field (or relies on the default), which tells Kubernetes to create a matching PersistentVolume on demand. Option E is correct because a StorageClass must define a provisioner (for example, kubernetes.io/aws-ebs or a CSI driver name), since the provisioner is the component that actually creates the backing volume; without it, no dynamic provisioning can occur. Option A is wrong because allowVolumeExpansion only enables resizing of already-provisioned volumes and is not required for provisioning.

Option B is wrong because volumeBindingMode: WaitForFirstConsumer only delays binding until a Pod is scheduled; the default Immediate mode also supports dynamic provisioning. Option D is wrong because a default StorageClass is only needed when a PVC omits storageClassName; a PVC that explicitly references a StorageClass provisions dynamically without any default being defined.

Exam trap

A common misconception is that a default StorageClass is mandatory for dynamic provisioning, but the actual requirement is that the PVC must reference a StorageClass (either explicitly or via the default), and the StorageClass must have a provisioner defined.

Full explanation →
50
MCQeasy

Which of the following volume types is designed to store sensitive information such as passwords or tokens?

A.emptyDir
B.hostPath
C.secret
D.configMap
AnswerC

The Secret volume type is specifically designed to store and deliver sensitive data such as passwords, OAuth tokens, and SSH keys to containers. Secret objects are persisted in etcd, subject to RBAC authorization, and can be encrypted at rest via EncryptionConfiguration. When mounted as volumes, they are exposed as files in a tmpfs-backed directory rather than written to persistent disk, reducing data-loss exposure. This makes Secret the intended and secure choice for the 'sensitive data' scenario in the question.

Why this answer

The Secret volume type is specifically designed to store sensitive data such as passwords, tokens, or SSH keys. Secrets are stored in the cluster's etcd (optionally encrypted at rest) and are injected into pods as files or environment variables, with in-memory (tmpfs) mounting to avoid writing sensitive data to disk.

Exam trap

A common pitfall in the CKA exam is confusing ConfigMap with Secret. Candidates often think ConfigMap can store sensitive data because it also holds key-value pairs, but ConfigMap lacks encryption and tmpfs mounting, which are essential for security. Secrets are specifically designed for sensitive information.

How to eliminate wrong answers

Option A is wrong because emptyDir is a temporary volume that shares data between containers in the same pod and is deleted when the pod is removed, with no built-in mechanism for storing sensitive data securely. Option B is wrong because hostPath mounts a file or directory from the host node's filesystem into the pod, which is not designed for secrets and poses security risks by exposing node-level data. Option D is wrong because ConfigMap is intended for non-sensitive configuration data (e.g., environment variables, config files) and does not provide encryption or access control for secrets.

Full explanation →
51
MCQmedium

You create a Deployment with 3 replicas and a ClusterIP Service. You notice that some pods are not receiving traffic. What is the most likely cause?

A.The pods are in CrashLoopBackOff
B.The Deployment has a revision history limit set too low
C.The Service's selector does not match the pod labels
D.The Service type is NodePort instead of ClusterIP
AnswerC

Kubernetes Services use label selectors to dynamically identify and group target pods. If the labels defined under the Service's spec.selector do not exactly match the labels on the Deployment's pod template, the Endpoints controller will fail to discover the pods, resulting in an empty Endpoints object and a complete failure to route traffic.

Why this answer

The most likely cause is that the Service's selector does not match the pod labels. A ClusterIP Service uses label selectors to identify which pods should receive traffic; if the selector does not match the labels defined on the pods, the Service's endpoints controller will not populate the endpoints object, and traffic will not be forwarded to any pod. This is a common misconfiguration that results in some or all pods not receiving traffic, even though the pods themselves are healthy.

Exam trap

The trap here is that candidates often assume the issue is with pod health (CrashLoopBackOff) or Service type, but the CKA exam specifically tests the understanding that a Service routes traffic based on label selectors, and a mismatch is the most common cause of pods not receiving traffic when they are otherwise running.

How to eliminate wrong answers

Option A is wrong because pods in CrashLoopBackOff would not be in a Running state and would not be ready to receive traffic, but the question states that some pods are not receiving traffic, implying others are; a mismatch in selectors affects all pods equally, not just some. Option B is wrong because the Deployment's revision history limit controls how many old ReplicaSets are retained for rollback, not traffic routing to pods. Option D is wrong because changing the Service type to NodePort would expose the Service on each node's port but would not fix a selector mismatch; the core issue of traffic not reaching pods due to mismatched labels would persist regardless of the Service type.

Full explanation →
52
MCQmedium

A ClusterRoleBinding grants cluster-admin access to a user. Which field in the ClusterRoleBinding specifies the user?

A.users
B.subjects
C.roleRef
D.bindings
AnswerB

`subjects` is the field in a ClusterRoleBinding that defines who the binding applies to. Each entry in the `subjects` list is an object with a `kind` of `User`, `Group`, or `ServiceAccount`. For a cluster admin grant, you would include a subject like `{"kind": "User", "name": "alice", "apiGroup": "rbac.authorization.k8s.io"}`. This field is the only place where the user identity is attached to the binding, so it is the correct answer.

Why this answer

In Kubernetes RBAC, the `subjects` field in a ClusterRoleBinding (or RoleBinding) specifies the users, groups, or service accounts that the binding applies to. The `subjects` array contains objects with `kind`, `name`, and optionally `apiGroup` or `namespace`, allowing you to reference a specific user by name. Option B is correct because `subjects` is the only field that defines the identity of the principal receiving the permissions.

Exam trap

CNCF often tests the distinction between `subjects` (who gets the permissions) and `roleRef` (what permissions they get), and candidates mistakenly choose `users` because it sounds intuitive, but Kubernetes uses the generic `subjects` field to accommodate multiple identity types.

How to eliminate wrong answers

Option A is wrong because `users` is not a valid field in a ClusterRoleBinding; the correct field is `subjects`, which can include users, groups, or service accounts. Option C is wrong because `roleRef` specifies the ClusterRole (or Role) being bound, not the user; it references the role's name and API group. Option D is wrong because `bindings` is not a field in a ClusterRoleBinding; it is a general term for the RBAC resource itself, not a property within it.

Full explanation →
53
Multi-Selecthard

An administrator needs to expand an existing PersistentVolumeClaim. Which TWO conditions must be met?

Select 2 answers
A.The PVC must be currently mounted by at least one pod.
B.The underlying PersistentVolume must be deleted first.
C.The StorageClass used by the PVC must have 'allowVolumeExpansion: true'.
D.The PersistentVolume's reclaim policy must be Recycle.
E.The PVC must be bound to a PersistentVolume.
AnswersC, E

The allowVolumeExpansion field on the StorageClass is the key enabling factor for volume growth. When set to true, the storage provisioner and the external controller permit the PVC's requested size to be increased beyond its original value; without this flag, any edit to the PVC's storage request is rejected, since the storage class provider has not opted into supporting resizing. This setting is per storage class, so if the class lacks it, expansion is impossible regardless of the volume plugin.

Why this answer

The StorageClass must have `allowVolumeExpansion: true` to permit resizing of a PersistentVolumeClaim. This field is a prerequisite in the StorageClass definition; without it, the PVC cannot be expanded even if the underlying volume supports resizing. The CKA exam expects you to know that volume expansion is gated by this StorageClass setting.

Exam trap

The CKA exam often tests the misconception that a PVC must be mounted or that the PV must be deleted before expansion, but the actual requirement is the StorageClass setting and the PVC being bound to a PV.

Full explanation →
54
MCQmedium

A Deployment named 'web-app' has 5 replicas. You want to perform a rolling update with a maximum of 3 pods unavailable during the update and a maximum of 2 extra pods above the desired count. Which YAML snippet correctly sets the rolling update strategy?

A.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2 maxSurge: 3
B.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2 maxSurge: 2
C.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 3 maxSurge: 3
D.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 3 maxSurge: 2
AnswerD

This is the correct configuration because it precisely balances update velocity and safety for a five-replica Deployment. By allowing up to three unavailable pods (maxUnavailable: 3), the Deployment can terminate old ReplicaSet pods aggressively, while capping the total pod count at seven with a surge of two, which keeps the cluster from being overloaded during the rollout. The update thus guarantees at least two pods remain available throughout, which is the intended minimum availability, and it completes in fewer cycles than more conservative settings would allow.

Why this answer

The rolling update strategy specifies `maxUnavailable: 3` and `maxSurge: 2`. With 5 desired replicas, this allows up to 3 pods to be unavailable during the update (so at least 2 pods remain running) and up to 2 extra pods above the desired count (so a maximum of 7 pods total). This matches the requirement exactly.

Exam trap

The trap here is that candidates often confuse the roles of `maxUnavailable` and `maxSurge`, or misread the question's constraints (e.g., thinking 'maximum of 3 pods unavailable' maps to `maxUnavailable: 2` because they subtract from desired count incorrectly).

How to eliminate wrong answers

Option A is wrong because it sets `maxUnavailable: 2` and `maxSurge: 3`, which would allow only 2 pods unavailable (too restrictive) and up to 3 extra pods (exceeding the allowed 2 extra). Option B is wrong because it sets `maxUnavailable: 2` and `maxSurge: 2`, which allows only 2 pods unavailable (not the required 3) and 2 extra pods (correct for surge but wrong for unavailability). Option C is wrong because it sets `maxUnavailable: 3` and `maxSurge: 3`, which allows 3 pods unavailable (correct) but up to 3 extra pods (exceeding the allowed 2 extra).

Full explanation →
55
Multi-Selecthard

Which THREE are valid ways to inject configuration data into a pod?

Select 3 answers
A.Use a Secret as a ConfigMap data source.
B.Mount a ConfigMap as a volume.
C.Use 'kubectl inject configmap' to inject data at runtime.
D.Set environment variables from a ConfigMap using envFrom or valueFrom.
E.Set environment variables from a Secret using envFrom or valueFrom.
AnswersB, D, E

Mounting a ConfigMap as a volume is a valid and commonly used injection method. When you define a volume of type configMap and mount it into a container, Kubernetes creates a file for each key in the ConfigMap, with the key as the filename and the value as the file's content. This approach is ideal for configuration files (e.g., application .conf or YAML), allows large amounts of data, and supports dynamic updates—changes to the ConfigMap are eventually reflected in the mounted files after the kubelet's sync period, unless the mount uses subPath.

Why this answer

A ConfigMap can be mounted as a volume in a Pod, allowing files to be created or updated in the container's filesystem with configuration data. This is a standard Kubernetes feature where the ConfigMap's data keys become filenames and values become file contents, and updates to the ConfigMap can be reflected in the mounted volume without restarting the Pod (depending on the mount type).

Exam trap

The trap here is that candidates often confuse the declarative nature of Kubernetes configuration injection with imperative commands, and may incorrectly assume a 'kubectl inject' command exists, or they mix up the roles of Secrets and ConfigMaps as data sources for each other.

Full explanation →
56
MCQeasy

Which of the following is NOT a control plane component in Kubernetes?

A.kube-scheduler
B.etcd
C.kube-proxy
D.kube-apiserver
AnswerC

kube-proxy is the correct answer because it is a node-level component that runs on every worker node, not on the control plane. Its job is to maintain network rules and handle traffic routing for Services, typically using iptables or IPVS, so it forwards requests to backend pods. Since it does not participate in cluster-wide control decisions, it is not a control plane component.

Why this answer

kube-proxy is not a control plane component; it is a node-level (worker) component responsible for implementing network rules and handling service-to-pod traffic via iptables or IPVS. The control plane consists of kube-apiserver, etcd, kube-scheduler, and kube-controller-manager.

Exam trap

The trap here is that candidates often confuse kube-proxy as a control plane component because it interacts with the API server and is essential for networking, but it operates at the node level and is not part of the control plane's core management functions.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is a core control plane component that assigns pods to nodes based on resource availability and constraints. Option B is wrong because etcd is the distributed key-value store that holds all cluster state and configuration data, making it a critical control plane component. Option D is wrong because kube-apiserver is the front-end of the control plane, exposing the Kubernetes API and handling all RESTful requests for cluster operations.

Full explanation →
57
MCQmedium

An administrator wants to ensure that a critical Pod always runs on a node that has an SSD. Which approach should be used?

A.Use podAffinity to prefer nodes running other Pods.
B.Set spec.nodeName to an SSD node's name.
C.Add a taint to nodes without SSD and add a toleration to the Pod.
D.Label SSD nodes with 'disk=ssd' and use nodeSelector in the Pod spec.
AnswerD

Applying a custom label like 'disk=ssd' to the target nodes and referencing it via nodeSelector in the Pod specification is the standard, declarative way to constrain scheduling. The Kubernetes scheduler will strictly filter out any nodes lacking this label, ensuring the Pod is only scheduled on SSD-equipped hardware.

Why this answer

Using a nodeSelector with a label like 'disk=ssd' ensures that the Pod is scheduled only on nodes that have that specific label, which directly matches the requirement to run the Pod on a node with an SSD. This is the simplest and most reliable method for node-level selection in Kubernetes, as it leverages the scheduler's built-in filtering mechanism.

Exam trap

The trap here is that candidates often confuse taints and tolerations with node selection, thinking they can force a Pod onto a specific node type, when in fact taints only repel Pods from nodes and require tolerations to allow scheduling, not to guarantee placement on a desired node.

How to eliminate wrong answers

Option A is wrong because podAffinity is used to schedule Pods relative to other Pods (e.g., co-location), not to select nodes based on hardware characteristics like SSD presence. Option B is wrong because setting spec.nodeName bypasses the scheduler entirely and directly assigns the Pod to a specific node by name, which is inflexible and does not scale; it also requires manual knowledge of the node name and does not use labels or taints for dynamic selection. Option C is wrong because adding a taint to nodes without SSD would repel Pods that do not tolerate that taint, but the Pod would need a toleration to run on those nodes; this approach would prevent the Pod from running on non-SSD nodes but does not actively ensure it runs on an SSD node—it could still be scheduled on any node without the taint, including those without SSD if they are not tainted.

Full explanation →
58
MCQeasy

An administrator needs to create a PersistentVolume with 10Gi capacity, ReadWriteOnce access mode, and a reclaim policy of Retain. Which YAML snippet correctly defines this PV?

A.apiVersion: v1 kind: PersistentVolume metadata: name: pv-example spec: capacity: storage: 10Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain hostPath: path: /data/pv
B.apiVersion: v1 kind: PersistentVolume metadata: name: pv-example spec: capacity: storage: 10Gi accessMode: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /data/pv
C.apiVersion: v1 kind: PersistentVolume metadata: name: pv-example spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /data/pv
D.apiVersion: v1 kind: PersistentVolume metadata: name: pv-example spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete hostPath: path: /data/pv
AnswerC

This is the correct PersistentVolume manifest because it satisfies all the stated requirements: it declares capacity of 10Gi, uses the plural accessModes field with ReadWriteOnce as a valid single-node access mode, and sets persistentVolumeReclaimPolicy to Retain. The hostPath points to /data/pv, and the PV is available to match a PersistentVolumeClaim that requests up to 10Gi with a compatible access mode. The manifest is structurally and semantically valid under the v1 API.

Why this answer

It defines a PersistentVolume with the required 10Gi capacity, ReadWriteOnce access mode (using the correct plural 'accessModes' field), and the Retain reclaim policy. The hostPath volume type is also specified correctly.

Exam trap

The CKA exam often tests the distinction between the singular 'accessMode' (incorrect) and the plural 'accessModes' (correct) in PersistentVolume and PersistentVolumeClaim specs, causing candidates to pick option B if they overlook this YAML syntax requirement.

How to eliminate wrong answers

Option A is wrong because it uses 'ReadWriteMany' instead of the required 'ReadWriteOnce' access mode. Option B is wrong because it uses the incorrect singular field name 'accessMode' instead of the correct plural 'accessModes'. Option D is wrong because it specifies 'persistentVolumeReclaimPolicy: Delete' instead of the required 'Retain'.

Full explanation →
59
MCQmedium

You create a ConfigMap named 'app-config' with key 'database.url'. Which command correctly creates a pod that injects this ConfigMap value as an environment variable named 'DB_URL'?

A.kubectl run my-pod --image=nginx --envFrom=configmap/app-config
B.Create a pod YAML with env.valueFrom.configMapKeyRef
C.kubectl run my-pod --image=nginx --env="DB_URL=configmap:app-config:database.url"
D.kubectl run my-pod --image=nginx --from-configmap=app-config
AnswerB

This is the correct and Kubernetes-native method for injecting a specific key's value from a ConfigMap into a container's environment. By defining the `env` variable within the Pod's YAML specification and utilizing `valueFrom.configMapKeyRef`, you explicitly reference the ConfigMap's name and the desired key. This declarative approach ensures precise control over environment variable injection and is the standard practice for managing application configurations.

Why this answer

To inject a specific key from a ConfigMap as a pod environment variable with a custom name, you must use a pod YAML with `env.valueFrom.configMapKeyRef`. This allows you to reference the ConfigMap key `database.url` and map it to the environment variable `DB_URL`. The `kubectl run` command does not support directly mapping a ConfigMap key to a custom environment variable name in a single command.

Exam trap

The trap here is that candidates often assume `kubectl run` with a simple flag can directly map a ConfigMap key to a custom environment variable name, but Kubernetes does not provide a single-command shortcut for this; you must use a YAML manifest with `configMapKeyRef`.

How to eliminate wrong answers

Option A is wrong because `--envFrom=configmap/app-config` would inject all keys from the ConfigMap as environment variables, but it would use the ConfigMap key names (e.g., `database.url`) as the environment variable names, not `DB_URL`. Option C is wrong because `--env="DB_URL=configmap:app-config:database.url"` is not a valid syntax for referencing a ConfigMap key; the correct syntax for referencing a ConfigMap value in `kubectl run` does not exist in this form. Option D is wrong because `--from-configmap=app-config` is not a valid flag for `kubectl run`; it is used with `kubectl create configmap` to create a ConfigMap from a file or literal.

Full explanation →
60
MCQeasy

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

A.kubectl apply configmap app-config config.properties
B.kubectl create configmap app-config --from-literal=config.properties
C.kubectl create configmap app-config --from-env-file=config.properties
D.kubectl create configmap app-config --from-file=config.properties
AnswerD

This is the correct command because the --from-file flag instructs kubectl to read the contents of config.properties and store them in the ConfigMap. The filename itself becomes the key, and the entire file content becomes the corresponding value.

Why this answer

`kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the contents of the file 'config.properties'. The `--from-file` flag reads the file as-is and stores its content under a key that defaults to the filename (config.properties). This is the standard method for creating a ConfigMap from a single file.

Exam trap

The trap here is confusing `--from-file` with `--from-env-file` or `--from-literal`, where candidates mistakenly think `--from-env-file` is the correct way to import a properties file, but `--from-env-file` parses the file line by line for KEY=VALUE pairs and does not preserve the raw file content.

How to eliminate wrong answers

Option A is wrong because `kubectl apply` is used to apply a configuration to a resource from a file (typically YAML/JSON), not to create a ConfigMap from a properties file; the syntax is invalid. Option B is wrong because `--from-literal` expects key=value pairs directly in the command, not a filename; using `--from-literal=config.properties` would treat the string 'config.properties' as a literal key without a value, not read the file. Option C is wrong because `--from-env-file` is used to import key-value pairs from a file formatted as environment variables (e.g., KEY=VALUE per line), but it does not preserve the raw file content; it parses the file and creates separate keys, which is not the same as storing the entire file under a single key.

Full explanation →
61
MCQeasy

Which Service type exposes a Service on each Node's IP at a static port in the range 30000-32767?

A.NodePort
B.ExternalName
C.ClusterIP
D.LoadBalancer
AnswerA

NodePort exposes the Service on each Node's IP at a static port, which is allocated from a default range of 30000-32767. Kubernetes automatically routes traffic incoming to this port on any node directly to the underlying backend Pods, regardless of which node those Pods are actually running on. This makes the service accessible from outside the cluster using the combination of any Node's IP and the allocated port.

Why this answer

A NodePort Service exposes the Service on each Node's IP at a static port in the range 30000-32767. When you create a NodePort Service, Kubernetes allocates a port from that range (or you can specify one) and opens that port on every node in the cluster, forwarding traffic to the Service's ClusterIP and then to the selected Pods.

Exam trap

The trap here is that candidates confuse NodePort with LoadBalancer, thinking LoadBalancer also uses the 30000-32767 port range on nodes, but LoadBalancer typically uses a cloud provider's load balancer and does not guarantee a static node port in that range unless NodePort is also specified.

How to eliminate wrong answers

Option B is wrong because ExternalName maps a Service to a DNS name (CNAME record) and does not expose any port on nodes. Option C is wrong because ClusterIP exposes the Service only on a cluster-internal IP, not on a static port on each node's IP. Option D is wrong because LoadBalancer provisions an external load balancer (e.g., from a cloud provider) and does not directly expose a static port in the 30000-32767 range on each node's IP.

Full explanation →
62
Multi-Selectmedium

Which TWO of the following are valid ways to expose a Service externally? (Select TWO.)

Select 2 answers
A.NodePort
B.Headless
C.LoadBalancer
D.ExternalName
E.ClusterIP
AnswersA, C

NodePort exposes the Service on a static port allocated from the default range 30000-32767 on every node's IP. Clients outside the cluster can reach the Service by connecting to `<NodeIP>:<NodePort>` on any node, and kube-proxy forwards the traffic to the backing Pods. This gives external access without requiring a cloud provider, though the port must be unique across Services.

Why this answer

A NodePort service exposes the application on a static port (30000–32767) on every node's IP address, making it accessible externally via `<NodeIP>:<NodePort>`. A LoadBalancer service provisions an external load balancer (e.g., from a cloud provider) that routes traffic to the service, typically using a public IP. Both are explicitly designed for external access, unlike ClusterIP which is internal only.

Exam trap

The trap here is that candidates confuse 'exposing externally' with any service type that has a DNS name or IP, but only NodePort and LoadBalancer provide direct external network access without additional components like Ingress or kubectl proxy.

Full explanation →
63
MCQmedium

You have a DaemonSet that runs on all nodes. You need to ensure it does NOT run on a node labeled 'disk=ssd'. Which field in the DaemonSet spec should you use?

A.spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution with NotIn operator
B.spec.template.spec.nodeSelector with disk: ssd
C.spec.template.spec.tolerations with key disk value ssd
D.spec.updateStrategy.rollingUpdate.maxUnavailable
AnswerA

Using nodeAffinity with the requiredDuringSchedulingIgnoredDuringExecution field enforces a hard scheduling constraint. By specifying the NotIn operator with the key disk and value ssd, the Kubernetes scheduler is strictly prohibited from placing the DaemonSet pods on any node labeled with disk=ssd, effectively excluding them while allowing scheduling on all other nodes.

Why this answer

`nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution` with the `NotIn` operator allows you to specify that the DaemonSet pod must not be scheduled on nodes with the label `disk=ssd`. This is the proper way to express an anti-affinity rule that excludes nodes based on a label value, ensuring the DaemonSet runs on all nodes except those with `disk=ssd`.

Exam trap

The trap here is that candidates often confuse `nodeSelector` (which selects nodes to include) with the need to exclude nodes, and they may incorrectly choose `nodeSelector` with a negative label value, not realizing that `nodeSelector` only supports equality-based inclusion, not exclusion.

How to eliminate wrong answers

Option B is wrong because `nodeSelector` with `disk: ssd` would require the pod to run only on nodes with that label, which is the opposite of the desired behavior (it would restrict the DaemonSet to SSD nodes instead of excluding them). Option C is wrong because `tolerations` are used to allow pods to be scheduled on nodes with taints, not to control scheduling based on node labels; tolerations do not prevent scheduling on nodes with a specific label. Option D is wrong because `spec.updateStrategy.rollingUpdate.maxUnavailable` controls the number of pods that can be unavailable during a rolling update of the DaemonSet, not the scheduling constraints for which nodes the DaemonSet runs on.

Full explanation →
64
MCQmedium

An application team reports that a Deployment's Pods in namespace 'web' become unreachable after a rolling update, even though 'kubectl get pods' shows them as Running and Ready. The Service 'web-svc' of type ClusterIP exists and has endpoints listed. You exec into a client Pod in the same namespace and run 'curl http://web-svc:8080'; the connection times out. You then run 'kubectl get networkpolicy -n web' and see a policy named 'deny-all-ingress' with podSelector matching the web Pods and policyTypes: Ingress, but no ingress rules. Which of the following is the MOST likely cause of the timeout?

A.The Service 'web-svc' is missing a selector that matches the Pod labels, so no endpoints are created and traffic cannot be routed.
B.The Pods are not actually Ready because their readiness probe is failing, so the Service removes them from endpoints.
C.The NetworkPolicy 'deny-all-ingress' is selecting the web Pods and, because it has no ingress rules, it denies all ingress traffic to those Pods.
D.The kube-proxy component on the client's node is not programmed with the Service's iptables rules, so the ClusterIP is not reachable.
AnswerC

A NetworkPolicy with policyTypes: Ingress and an empty ingress rule list isolates the selected Pods, denying all inbound traffic except from the Pod's own node. Since the policy selects the web Pods, the client's connection is dropped, causing the timeout. This directly explains the symptom and the presence of the policy.

Why this answer

The presence of a NetworkPolicy named 'deny-all-ingress' that selects the web Pods and has no ingress rules is the definitive cause. Such a policy isolates the Pods, dropping all inbound connections. The Service and endpoints are healthy, so the timeout is due to packet filtering, not routing or readiness.

Removing or modifying the policy restores connectivity.

Exam trap

The trap here is assuming that a NetworkPolicy with no rules is a no-op, when in fact an empty ingress rule list combined with policyTypes: Ingress denies all ingress traffic to the selected Pods.

Full explanation →
65
MCQmedium

You want to upgrade the control plane from v1.28.0 to v1.29.0 using kubeadm. After upgrading kubeadm on the control plane node, which command should you run first?

A.kubeadm upgrade plan
B.kubeadm upgrade apply v1.29.0
C.kubeadm upgrade node
D.kubeadm upgrade diff
AnswerA

Running `kubeadm upgrade plan` is the recommended first step when upgrading a Kubernetes control plane. This command analyzes your cluster to check if it can be upgraded, detects the current component versions, and displays the available target versions along with the exact configuration changes that will be applied. It ensures there are no version compatibility blockers before you commit to the actual upgrade process.

Why this answer

After upgrading kubeadm on the control plane node, the first command to run is `kubeadm upgrade plan`. This command checks the current cluster version, validates that the upgrade path is supported (e.g., from v1.28.0 to v1.29.0), and displays the available versions to upgrade to, along with any manual steps required. It is a prerequisite to ensure the upgrade is safe before proceeding with `kubeadm upgrade apply`.

Exam trap

The trap here is that candidates often confuse the sequence and jump directly to `kubeadm upgrade apply`, thinking it is the first step, but the CKA exam tests the prerequisite validation step (`kubeadm upgrade plan`) to ensure a safe upgrade process.

How to eliminate wrong answers

Option B is wrong because `kubeadm upgrade apply v1.29.0` should only be run after `kubeadm upgrade plan` has confirmed the upgrade path and there are no blockers; running it first could lead to an unsupported or failed upgrade. Option C is wrong because `kubeadm upgrade node` is used on worker nodes (or secondary control plane nodes) to upgrade the local kubelet and kube-proxy, not on the primary control plane node during the initial upgrade. Option D is wrong because `kubeadm upgrade diff` is not a valid kubeadm command; it does not exist in the kubeadm toolset and would result in an error.

Full explanation →
66
MCQeasy

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

A.The node is out of disk space
B.The pod exceeded its memory limit
C.The container command is invalid
D.The container image name is misspelled
AnswerD

A misspelled image name or tag prevents the container runtime from locating the manifest in the specified registry. The kubelet first transitions to ErrImagePull, and after repeated failed attempts to download the non-existent image, it backs off to avoid overloading the registry, resulting in the ImagePullBackOff status. This indicates a configuration error in the pod specification.

Why this answer

The 'ImagePullBackOff' state indicates that the kubelet on the node is unable to pull the container image from the registry. The most common cause is an incorrect image name or tag, which results in a manifest not found error. This triggers exponential backoff retries by the kubelet, leading to the 'ImagePullBackOff' status.

Exam trap

The trap here is that candidates confuse 'ImagePullBackOff' with 'CrashLoopBackOff', assuming the container started but failed, when in fact the image was never successfully pulled.

How to eliminate wrong answers

Option A is wrong because a node being out of disk space would typically cause an 'Evicted' or 'NodeDiskPressure' condition, not an 'ImagePullBackOff' error, which is specific to image pull failures. Option B is wrong because exceeding the pod's memory limit results in an 'OOMKilled' state (container terminated with Out Of Memory), not an image pull issue. Option C is wrong because an invalid container command causes a 'CrashLoopBackOff' state after the container starts, not 'ImagePullBackOff', which occurs before the container can run.

Full explanation →
67
MCQhard

Which CSI driver feature must be supported by the driver to allow expanding a PVC while the pod using it is still running?

A.Volume attach
B.Volume expansion
C.Mount options
D.ExpandInUsePersistentVolume
AnswerB

Volume expansion is the correct high-level feature, but the CSIDriver spec requires an explicit mode to enable the in-use aspect. A driver may support expansion only when the volume is detached, declared via ExpandPersistentVolume, and still not allow resize while attached. Thus merely saying 'volume expansion' is too imprecise; Kubernetes must see a specific mode flag to permit online expansion.

Why this answer

To allow expanding a PVC while the pod is still running, the CSI driver must support volume expansion (e.g., ControllerExpandVolume and NodeExpandVolume RPCs). The in-use expansion capability is also controlled by the Kubernetes feature gate `ExpandInUsePersistentVolumes`, but that is not a CSI driver feature. Therefore, the correct answer is 'Volume expansion'.

Exam trap

Candidates may confuse the Kubernetes feature gate `ExpandInUsePersistentVolumes` with a CSI driver capability. The feature gate is a cluster-level setting, while the driver must support volume expansion via its CSI capabilities.

How to eliminate wrong answers

Option A is wrong because 'Volume attach' is a CSI driver capability that controls whether the driver supports attaching volumes to nodes, not expanding them while in use. Option B is wrong because 'Volume expansion' is a generic capability that indicates the driver supports expanding volumes, but it does not specifically allow expansion while the PVC is still mounted by a running pod. Option C is wrong because 'Mount options' is a CSI driver capability that controls whether the driver supports custom mount options, and it has no relation to online volume expansion.

Full explanation →
68
MCQhard

You create a Pod with an init container and a main container. The init container runs a script that writes to a shared volume. The main container reads from that volume. However, the Pod is stuck in 'Init:CrashLoopBackOff'. What is the most likely cause?

A.The init container is waiting for the main container to start
B.The init container's command is failing due to an error in the script
C.The main container has a resource limit that is too low
D.The shared volume is not mounted with the correct permissions
AnswerB

If an init container enters a CrashLoopBackOff state, it is typically because the entrypoint command or script executed inside it returned a non-zero exit code. Kubernetes monitors the exit status of the init container's process, and any failure prevents the pod from transitioning to the running state, causing the kubelet to restart the init container repeatedly. Debugging this requires inspecting the init container's logs or exit codes.

Why this answer

The 'Init:CrashLoopBackOff' status indicates that the init container is repeatedly failing and restarting. Since init containers run to completion before the main container starts, the most likely cause is that the script in the init container is failing due to an error, such as a syntax mistake, missing dependency, or incorrect command.

Exam trap

The CKA exam often tests the distinction between init containers and regular containers, specifically that init containers run to completion before main containers start, so candidates mistakenly think the main container's resources or volume permissions could cause an init container failure.

How to eliminate wrong answers

Option A is wrong because init containers always run to completion before the main container starts; they do not wait for the main container. Option C is wrong because resource limits apply to containers after they start, and the main container hasn't started yet when the init container is failing. Option D is wrong because incorrect volume permissions would typically cause a runtime error in the main container, not prevent the init container from completing its script.

Full explanation →
69
MCQmedium

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

A.kubectl top requires root access
B.Nodes have insufficient CPU
C.The Metrics Server is not deployed
D.Kubelet is not running on nodes
AnswerC

The Metrics Server is an optional cluster component that aggregates resource usage from kubelets and exposes it through the metrics.k8s.io API, which kubectl top and the Horizontal Pod Autoscaler consume. In a standard kubeadm or vanilla cluster it is not installed by default, so kubectl top nodes fails with 'metrics not available' until the Metrics Server manifests are applied. Deploying the Metrics Server and allowing it time to collect its first metrics resolves the error.

Why this answer

Metrics server is not deployed or not ready, so resource metrics are unavailable.

Full explanation →
70
Multi-Selecteasy

Which TWO of the following are valid ways to inject configuration data into a pod? (Select TWO.)

Select 2 answers
A.Editing the pod's spec directly via kubectl edit
B.Using a Sidecar container to fetch config from a remote API
C.Mounting a ConfigMap as a volume
D.Injecting a ConfigMap as environment variables
E.Storing config in a PersistentVolume
AnswersC, D

Mounting a ConfigMap as a volume is a native injection method: you declare the ConfigMap in the pod's volumes list and reference it in a volumeMount, causing Kubernetes to expose each key as a file in the container's filesystem. This approach is ideal for large or structured configurations, and when the ConfigMap is updated, kubelet periodically syncs the mounted files so running applications can observe changes without a restart (depending on the app).

Why this answer

Option C is correct because a ConfigMap can be mounted as a volume into a pod, causing each key in the ConfigMap to appear as a file in the mounted directory, which is a standard Kubernetes mechanism for injecting configuration data. Option D is also correct because a ConfigMap's keys can be exposed as environment variables inside containers via envFrom or valueFrom.configMapKeyRef, directly injecting configuration values into the container's environment. Option A is not a valid injection method because kubectl edit modifies the pod's specification itself (and most pod fields are immutable after creation), not the configuration data consumed by the application.

Option B is not a native configuration-injection mechanism; a sidecar fetching config from a remote API is an application-level pattern, not a Kubernetes-provided way to inject config into a pod. Option E is incorrect because a PersistentVolume provides storage, not a mechanism for injecting configuration data into a pod.

Exam trap

Kubernetes often tests the distinction between valid configuration injection methods (ConfigMaps as volumes or env vars) and invalid ones like direct Pod spec edits or using PersistentVolumes, which are not designed for configuration data.

Full explanation →
71
Multi-Selecthard

Your kubeadm cluster was initialized with default certificates. You need to check the expiration of the API server certificate and renew it if necessary. Which TWO commands are appropriate? (Choose TWO.)

Select 2 answers
A.kubeadm certs renew all
B.kubeadm certs check-expiration
C.kubectl config view
D.kubeadm upgrade plan
E.kubectl cluster-info
AnswersA, B

This command performs a unified renewal of every Kubernetes certificate that kubeadm manages, including the API server, controller-manager, scheduler, and etcd certificates, plus the client certificates in kubeconfig files. It is the go-to action when certificates were created with default validity and need refreshing. After running it, the control plane components must be restarted to start using the new certificates.

Why this answer

Option B, `kubeadm certs check-expiration`, is correct because it is the dedicated kubeadm subcommand that reads the certificates stored in /etc/kubernetes/pki (and the kubeconfig files in /etc/kubernetes) and prints each certificate's expiration date, residual time, and whether it is CA or not, which directly satisfies the requirement to check expiration. Option A, `kubeadm certs renew all`, is correct because it renews every certificate managed by kubeadm, including the API server certificate (apiserver.crt), and is the standard way to renew them when they are expired or near expiry. Option C, `kubectl config view`, only displays the kubeconfig context, cluster, and user settings and reveals nothing about certificate expiration dates.

Option D, `kubeadm upgrade plan`, checks available Kubernetes version upgrades and component compatibility, not certificate expiry. Option E, `kubectl cluster-info`, merely shows the addresses of the control plane and core services, so it cannot check or renew certificates.

Exam trap

The trap here is that candidates confuse `kubeadm certs` subcommands with `kubectl` commands, mistakenly thinking `kubectl config view` or `kubectl cluster-info` can reveal certificate expiration, when in fact only `kubeadm` has direct access to the PKI files on the control plane node.

Full explanation →
72
MCQmedium

To make a node unschedulable without evicting existing pods, which command should be used?

A.kubectl cordon node01
B.kubectl taint node01 key=value:NoSchedule
C.kubectl drain node01
D.kubectl uncordon node01
AnswerA

kubectl cordon node01 sets the node's `spec.unschedulable` field to `true`, which tells the Kubernetes scheduler to skip this node for all future pod placements. Existing pods on the node are completely unaffected and continue to run normally, because cordon only flips a scheduling flag and does not interact with the kubelet or the pod lifecycle. This is the exact, and only, standard command for making a node unschedulable without evicting anything.

Why this answer

`kubectl cordon` marks a node as unschedulable, preventing new pods from being scheduled onto it while leaving existing pods running. This is the precise command for the task described, as it modifies the node's `spec.unschedulable` field to `true` without affecting running workloads.

Exam trap

The trap here is that candidates confuse taints (which control pod placement based on tolerations) with cordoning (which globally blocks all scheduling), or they mistakenly choose `drain` which evicts pods, missing the explicit 'without evicting existing pods' constraint.

How to eliminate wrong answers

Option B is wrong because `kubectl taint node01 key=value:NoSchedule` adds a taint that prevents new pods from being scheduled unless they tolerate the taint, but it does not make the node unschedulable globally; pods without tolerations are blocked, but the node remains schedulable for tolerating pods, and existing pods are unaffected. Option C is wrong because `kubectl drain node01` evicts all existing pods from the node (with graceful termination) and then cordons it, which violates the requirement to not evict pods. Option D is wrong because `kubectl uncordon node01` makes a node schedulable again, which is the opposite of the desired action.

Full explanation →
73
MCQmedium

An admin runs 'kubectl get pods' and sees a pod in the 'Pending' state. Which is the most likely cause?

A.The pod has been deleted
B.The pod is waiting for a container to start
C.The pod cannot be scheduled due to insufficient resources
D.The container image is invalid
AnswerC

The Pending phase most commonly indicates that the scheduler cannot find a suitable node to place the pod. The scheduler evaluates resource requests (CPU, memory, ephemeral storage) against the allocatable capacity and remaining availability of each node; if every node has insufficient available resources, the pod remains unscheduled and stuck in Pending. This is typically confirmed by describing the pod and observing events such as FailedScheduling.

Why this answer

A pod in 'Pending' state indicates that the pod has been accepted by the Kubernetes API server but is not yet running. The most common cause is that the scheduler cannot find a node that satisfies the pod's resource requests (CPU, memory) or other scheduling constraints (taints, node selector, affinity rules). This results in the pod remaining unscheduled, hence 'Pending'.

Exam trap

CNCF often tests the distinction between pod states: candidates confuse 'Pending' with image-related issues, but 'Pending' specifically means the pod has not been scheduled yet, whereas image errors occur after scheduling.

How to eliminate wrong answers

Option A is wrong because a deleted pod would not appear in 'kubectl get pods' output at all, or would show as 'Terminating' briefly before removal. Option B is wrong because waiting for a container to start is part of the normal pod lifecycle after scheduling, and the pod would be in 'ContainerCreating' or 'Running' state, not 'Pending'. Option D is wrong because an invalid container image would cause the pod to transition to 'ImagePullBackOff' or 'ErrImagePull' after scheduling, not remain in 'Pending'.

Full explanation →
74
MCQhard

A cluster administrator wants to ensure that a set of batch processing Pods are preemptible and should not cause disruption to other critical workloads. Which combination of scheduling features should be used?

A.Taint all worker nodes with a custom taint and add tolerations to batch Pods.
B.Assign a low priority class to the batch Pods and set a PodDisruptionBudget for critical workloads.
C.Use nodeAffinity to schedule batch Pods on dedicated nodes.
D.Use resource quotas to limit the batch Pods' resource consumption.
AnswerB

Defining a low PriorityClass for batch pods ensures that the kube-scheduler will preempt them if higher-priority critical pods require those node resources. Simultaneously, configuring a PodDisruptionBudget (PDB) for the critical workloads guarantees that voluntary disruptions do not drop their replica counts below a safe threshold, balancing resource availability with application resilience.

Why this answer

Assigning a low priority class to batch Pods ensures they are preempted by higher-priority critical workloads when resources are scarce, while a PodDisruptionBudget (PDB) for critical workloads guarantees that a minimum number of those Pods remain available during voluntary disruptions (e.g., node drains). This combination allows batch Pods to be preemptible without causing disruption to critical workloads, aligning with the requirement.

Exam trap

The trap here is that candidates often confuse taints/tolerations or node affinity with preemption and disruption protection, failing to realize that only priority classes enable preemption and PDBs control voluntary disruptions.

How to eliminate wrong answers

Option A is wrong because tainting worker nodes with a custom taint and adding tolerations to batch Pods only prevents other Pods from scheduling on those nodes unless they have the toleration; it does not make batch Pods preemptible or protect critical workloads from disruption. Option C is wrong because using nodeAffinity to schedule batch Pods on dedicated nodes isolates them but does not provide preemption capability or disruption protection for critical workloads; dedicated nodes can still be disrupted by node failures or maintenance. Option D is wrong because resource quotas limit the total resource consumption of batch Pods but do not make them preemptible or prevent disruption to critical workloads; quotas only enforce resource caps, not scheduling priority or availability guarantees.

Full explanation →
75
Multi-Selecteasy

Which THREE of the following are CNI plugins?

Select 3 answers
A.kube-proxy
B.Flannel
C.Weave
D.CoreDNS
E.Calico
AnswersB, C, E

Correct. Flannel is a CNI plugin.

Why this answer

Flannel is a CNI plugin that provides a simple overlay network for Kubernetes clusters, typically using VXLAN or host-gw to encapsulate and route pod traffic across nodes. It implements the Container Network Interface (CNI) specification by installing a binary and configuration file on each node, enabling pod-to-pod communication without requiring a separate network daemon.

Exam trap

The trap here is that candidates confuse cluster networking components (kube-proxy, CoreDNS) with CNI plugins, which are specifically responsible for pod-level network connectivity and IP assignment, not service proxying or DNS resolution.

Full explanation →

Page 1 of 10

Page 2

All pages

12345678910

Practice CKA by domain

Target a specific domain to shore up weak areas.

TroubleshootingCluster Architecture, Installation and ConfigurationServices and NetworkingWorkloads and SchedulingStorageCluster Architecture, Installation & ConfigurationWorkloads & SchedulingServices & Networking
See all domains with question counts →