CKA Practice Exam 4 — 20 Questions

Question 1

A Kubernetes cluster has been running for months. Recently, some pods are reporting 'FailedScheduling' due to insufficient memory. The administrator wants to add a new node with 32GB RAM. However, after joining the node, the new node shows 'NotReady' and the kubelet logs indicate 'Failed to update node status: context deadline exceeded'. What is the most likely cause?

Accepted Answer

There is a network connectivity issue between the new node and the control plane.. The 'context deadline exceeded' error in the kubelet logs indicates that the kubelet on the new node is unable to communicate with the API server within the expected timeout. This is typically caused by network connectivity issues between the node and the control plane, such as firewall rules, incorrect DNS resolution, or a broken CNI plugin. Without successful node-to-API-server communication, the kubelet cannot post its status, leaving the node in 'NotReady' state.

Answer

The kubelet is not configured with the correct node IP.

Answer

The new node does not have enough disk space for container images.

Answer

The API server is overloaded and cannot handle the node update request.

Question 2

A DevOps engineer notices that the kubelet on a node is unable to register with the Kubernetes API server. The kubelet logs show 'Failed to get bootstrap CA certificate' and the node is not yet part of the cluster. What is the most likely cause?

Accepted Answer

The bootstrap token used for TLS bootstrapping has expired.. The bootstrap token used for TLS bootstrapping has expired. During the TLS bootstrap process, the kubelet uses a limited-time bootstrap token to authenticate with the API server and request a client certificate. If the token expires before the kubelet completes registration, the kubelet will fail to obtain the bootstrap CA certificate and cannot join the cluster, as indicated by the error 'Failed to get bootstrap CA certificate'.

Answer

The kubelet configuration file has incorrect node IP.

Answer

The node's RBAC permissions are misconfigured.

Answer

The API server is not running.

Question 3

Match each kubectl command to its purpose.

Question 4

Drag and drop the steps to deploy an application using a Deployment and expose it with a Service into the correct order.

Question 5

A pod with priorityClassName: high is pending. You describe the pod and see the event: '0/3 nodes are available: 3 node(s) didn't match pod affinity/anti-affinity, 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' The pod has required anti-affinity to avoid co-location with pods from the same app. How can you get the pod scheduled?

Accepted Answer

Change the anti-affinity rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution.. The pod is pending because its required anti-affinity rule cannot be satisfied on any node: all 3 nodes either have a control-plane taint (which the pod doesn't tolerate) or already host pods from the same app, violating the anti-affinity. Changing the rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution makes the anti-affinity a soft constraint, allowing the scheduler to place the pod on a node even if it means co-locating with same-app pods, thus resolving the scheduling conflict.

Answer

Add a toleration for the control-plane taint.

Answer

Increase the number of replicas of the app to spread the pods.

Answer

Delete the existing pods of the same app to free up nodes.

Question 6

Which THREE of the following are valid taint effects that can be applied to a node? (Select 3)

Accepted Answer

NoSchedule. Taint effects in Kubernetes control pod scheduling onto nodes. `NoSchedule` (C) prevents pods that do not tolerate the taint from being scheduled on the node, making it a valid taint effect.

Answer

NeverSchedule

Answer

PreferSchedule

Question 7

You have a CronJob that runs a backup job every 5 minutes. The job takes about 2 minutes to complete. You notice that sometimes two job pods are running simultaneously. What is the most likely cause?

Accepted Answer

The concurrencyPolicy is set to 'Allow' (default) which permits overlapping executions.. Option B is correct because the default `concurrencyPolicy` for a CronJob is `Allow`, which permits new Job pods to start even if a previous Job is still running. Since the backup takes 2 minutes and the CronJob runs every 5 minutes, overlapping executions should not normally occur unless the Job duration exceeds the interval. However, if the `concurrencyPolicy` is set to `Allow`, the CronJob controller will create a new Job pod regardless of whether the previous one is still running, leading to simultaneous pods. The most likely cause is that the `concurrencyPolicy` is explicitly or implicitly set to `Allow`, allowing overlapping executions.

Answer

The backup takes longer than expected due to data volume.

Answer

The job's parallelism is set to 2.

Answer

The CronJob's startingDeadlineSeconds is set too low.

Question 8

A DevOps engineer is designing a Kubernetes cluster for a production environment. Which of the following is a best practice for etcd deployment?

Accepted Answer

Deploy etcd on dedicated nodes with SSD storage.. Option C is correct because etcd is the Kubernetes cluster's primary data store, and its performance directly impacts the entire cluster's stability and responsiveness. Dedicated nodes prevent resource contention from other workloads, while SSD storage provides the low-latency, high-IOPS performance required for etcd's frequent write operations (especially with the default 1 MB write-ahead log). This isolation is a recommended best practice in the official Kubernetes documentation for production clusters.

Answer

Deploy etcd on exactly 2 nodes for simplicity.

Answer

Deploy etcd on all worker nodes to maximize redundancy.

Answer

Deploy etcd on the same nodes as GPU-accelerated workloads.

Question 9

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

Accepted Answer

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

Answer

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

Answer

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

Question 10

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?

Accepted Answer

Assign a low priority class to the batch Pods and set a PodDisruptionBudget for critical workloads.. Option B is correct because 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.

Answer

Taint all worker nodes with a custom taint and add tolerations to batch Pods.

Answer

Use nodeAffinity to schedule batch Pods on dedicated nodes.

Answer

Use resource quotas to limit the batch Pods' resource consumption.

Question 11

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

Accepted Answer

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

Answer

Between 2 and 3

Answer

Exactly 4

Answer

Always 3

Question 12

Which TWO of the following are valid ways to restrict a Pod to run only on nodes with a specific label? (Select 2)

Accepted Answer

Specifying spec.nodeSelector in the Pod spec.. Option B is correct because `spec.nodeSelector` is a simple, direct field in the Pod spec that constrains which nodes a Pod can be scheduled on based on node labels. When you specify a key-value pair in `nodeSelector`, the scheduler will only place the Pod on nodes that have that exact label, making it a valid method for restricting Pod placement.

Answer

Adding a toleration for a taint on the node.

Answer

Setting spec.nodeName to a node's name.

Answer

Using spec.affinity.podAffinity with requiredDuringScheduling.

Question 13

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?

Accepted Answer

Run kubeadm join with the --control-plane flag on the new node.. Option B is correct because 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.

Answer

Create a bootstrap token on the existing control plane node.

Answer

Run kubeadm init on the new node.

Answer

Take a snapshot of etcd using etcdctl.

Question 14

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

Accepted Answer

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

Answer

Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution for the GPU label.

Answer

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

Answer

Add a toleration for GPU node taints.

Question 15

An administrator notices that a pod using a PersistentVolumeClaim is stuck in 'Pending' state. The PVC is bound to a PV with the status 'Released'. What is the most likely cause?

Accepted Answer

The PV's reclaim policy is 'Retain' and the PV must be manually recycled.. A PVC stuck in 'Pending' means it cannot find a suitable PV to bind to. The PV is in 'Released' status, which indicates it was previously bound to a PVC that has since been deleted. With a 'Retain' reclaim policy, the PV is not automatically recycled or made available for reuse; the administrator must manually delete and recreate the PV to clear its claimRef and make it available again. This manual intervention is required because the 'Retain' policy preserves the underlying storage and its data, leaving the PV in a 'Released' state that cannot be bound to a new PVC.

Answer

The PV has a faulty disk and needs replacement.

Answer

The StorageClass has an incorrect provisioner.

Answer

The PV is not bound to any PVC.

Question 16

A Kubernetes cluster has three control plane nodes and five worker nodes. The kube-apiserver is failing to start on one control plane node with the error 'etcdserver: request timed out'. The etcd cluster is healthy with three members. Which of the following is the most likely cause?

Accepted Answer

A firewall is blocking traffic on port 2379 between the control plane and etcd. The error 'etcdserver: request timed out' indicates that the kube-apiserver cannot establish a TCP connection to the etcd cluster within the timeout period. Since the etcd cluster is healthy with three members and leader election is functioning, the most likely cause is a firewall blocking port 2379 (the etcd client port) between the control plane node and the etcd members. This prevents the kube-apiserver from communicating with etcd, even though the etcd cluster itself is operational.

Answer

The etcd cluster has a leader election issue

Answer

The kube-apiserver is using the wrong etcd client port (2380 instead of 2379)

Answer

The etcd client certificate is expired

Question 17

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

Accepted Answer

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

Answer

etcdctl endpoint health

Answer

etcdctl snapshot save backup.db

Answer

etcdctl snapshot status snapshot.db

Question 18

A Kubernetes cluster has a deployment with 3 replicas. After a node failure, you notice that only 2 pods are running, and the deployment has not rescheduled the missing pod. What is the most likely cause?

Accepted Answer

The node controller has not yet evicted the pod. When a node fails, the node controller marks the node as `NodeReady=False` and waits for a configurable timeout (`pod-eviction-timeout`, default 5 minutes) before evicting pods. Until eviction, the deployment's ReplicaSet sees the pod as still existing (though on an unreachable node) and does not create a replacement. Option C correctly identifies that the node controller has not yet evicted the pod, which is the default behavior.

Answer

The deployment has a resource quota that prevents new pods

Answer

The pod's terminationGracePeriodSeconds is set to 0

Answer

The deployment's replicas field is set to 2

Question 19

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

Accepted Answer

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

Answer

Random pods

Answer

Pods with the lowest ordinals (0 and 1)

Answer

Pods with the highest resource usage

Question 20

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

Accepted Answer

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

Answer

The pod has resource requests that exceed available capacity

Answer

The nodes are cordoned

Answer

The kube-scheduler is not running