CKA Practice Test 41 — 15 Questions

Question 1

Which component is responsible for assigning pods to nodes?

Accepted Answer

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

Answer

kubelet

Answer

kube-apiserver

Answer

kube-controller-manager

Question 2

A Job named 'data-processor' completes successfully. You want to run it again with the same configuration. What is the correct way to rerun the Job?

Accepted Answer

Delete the Job with 'kubectl delete job data-processor' and then recreate it.. A completed Job in Kubernetes is immutable and cannot be rerun by editing or restarting it. The only way to execute the same Job again is to delete the existing Job and recreate it with the same configuration, as Jobs are designed to run to completion and are not intended to be restarted like Deployments.

Answer

Edit the Job with 'kubectl edit job data-processor' and change the template.

Answer

Run 'kubectl rollout restart job data-processor'

Answer

Run 'kubectl rerun job data-processor'

Question 3

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?

Accepted Answer

The Pod uses hostNetwork and cannot resolve the ClusterIP due to DNS configuration. 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.

Answer

The kube-proxy is not running on the node

Answer

The Service is not defined correctly

Answer

The container image is missing networking tools

Question 4

You need to check the status of control plane components. Which TWO commands are appropriate?

Accepted Answer

kubectl get pods -n kube-system. To check the status of control plane components in a kubeadm-established cluster, use 'kubectl get pods -n kube-system' to inspect the static pods. 'kubectl get componentstatuses' (deprecated but still a valid status check) reports health of the control plane components. 'systemctl status kube-apiserver' is not appropriate because the API server runs as a static pod, not a systemd service.

Answer

systemctl status kube-apiserver

Answer

top -u kube

Answer

systemctl list-units --type=service

Question 5

A Kubernetes cluster uses Calico as the CNI plugin. Two pods on different nodes cannot communicate, but pods on the same node can. Network policies are not enforced. What is the most likely cause?

Accepted Answer

The nodes' firewalls are blocking required ports for Calico (e.g., BGP port 179 or VXLAN port 4789).. Calico relies on specific ports for inter-node communication. When using BGP (default), port 179 must be open; when using VXLAN overlay, port 4789 is required. If node firewalls block these ports, Calico cannot establish routes or encapsulate traffic between nodes, causing cross-node pod communication to fail while same-node communication (which uses the local bridge) remains unaffected.

Answer

Calico is not configured with an overlay network.

Answer

A NetworkPolicy is blocking inter-node traffic.

Answer

The pods are using different Service types.

Question 6

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 7

You are troubleshooting a pod that is in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 Insufficient memory, 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate'. Which TWO actions can resolve the issue?

Accepted Answer

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

Answer

Add a node selector to the pod spec to target a specific node

Answer

Increase the memory request to prioritize scheduling

Answer

Add resource limits without changing requests

Question 8

Which TWO of the following are valid reasons a pod might be stuck in 'Pending' state?

Accepted Answer

Not enough CPU or memory available on any node. Option C is correct because the Kubernetes scheduler cannot bind a pod to any node when no node has sufficient allocatable CPU or memory to satisfy the pod's resource requests, leaving the pod in Pending with a FailedScheduling event. Option E is correct because taints on nodes repel pods that lack a matching toleration, so the scheduler finds no feasible node and the pod remains Pending. Option A is wrong because OOM-killed containers occur after scheduling, producing CrashLoopBackOff or OOMKilled statuses on a running pod, not Pending. Option B is wrong because an image pull authentication failure happens on a node after the pod is already scheduled, resulting in ImagePullBackOff or ErrImagePull. Option D is wrong because rebooting a node affects already-running pods (e.g., eviction/rescheduling), not a pod that has never been scheduled.

Answer

Container is killed due to OOM

Answer

Container image pull fails because of authentication error

Answer

Node is rebooted

Question 9

A StatefulSet named 'mysql' manages 3 replicas. You need to scale it down to 1 replica. What happens to the PersistentVolumeClaims (PVCs) of the removed pods?

Accepted Answer

The PVCs are retained to preserve data.. When a StatefulSet is scaled down, the PersistentVolumeClaims (PVCs) associated with the removed pods are retained by default. This is because StatefulSets are designed for stateful workloads where data persistence is critical; the PVCs remain to preserve data in case the pod is recreated or the StatefulSet is scaled up again. Kubernetes does not automatically delete PVCs when a StatefulSet pod is removed, as PVC lifecycle is independent of pod lifecycle.

Answer

The PVCs are automatically backed up before deletion.

Answer

The PVCs are retained only if the pod with the highest ordinal is removed first.

Answer

The PVCs are automatically deleted along with the pods.

Question 10

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

Accepted Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: deployer
  namespace: app
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
  namespace: app
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
  namespace: app
subjects:
- kind: ServiceAccount
  name: deployer
  namespace: app
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io. It creates a ServiceAccount named 'deployer' in the 'app' namespace, a Role in the same namespace with rules allowing 'create' on 'deployments' (which belong to the 'apps' API group), and a RoleBinding that binds the ServiceAccount to that Role. This grants the ServiceAccount permission to create Deployments only within the 'app' namespace, which is the required scope.

Answer

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

Answer

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

Answer

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

Question 11

A Deployment 'web' has replicas=3 and update strategy RollingUpdate with maxSurge=50% and maxUnavailable=0. You update the container image. During the rollout, what is the maximum number of pods that can be running simultaneously?

Accepted Answer

5. With maxSurge=50% and maxUnavailable=0, the Deployment can create up to ceil(50% of 3) = ceil(1.5) = 2 extra pods above the desired 3 during a rolling update. Therefore, the maximum number of pods running simultaneously is 3 + 2 = 5.

Answer

4

Answer

3

Answer

6

Question 12

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

Accepted Answer

Modify the pod's anti-affinity rules or remove the conflicting pod on the third node. The pod is unschedulable because one node has a pod anti-affinity rule conflict, and the other two nodes have a control-plane taint. The best action is to modify the pod's anti-affinity rules (e.g., relax the requiredDuringSchedulingIgnoredDuringExecution constraint) or remove the conflicting pod on the third node, as this directly resolves the scheduling conflict without affecting the control-plane taint or replicas.

Answer

Increase the number of replicas

Answer

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

Answer

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

Question 13

You are tasked with troubleshooting a web application that is deployed in a Kubernetes cluster. The application consists of a Deployment named 'web-app' with 3 replicas, each running a container that listens on port 3000. A Service named 'web-service' of type ClusterIP with selector 'app: web' and port 80 targeting port 3000 has been created. Additionally, an Ingress resource named 'web-ingress' is configured with a host rule for 'example.com' and backend service 'web-service' on port 80. Users report that accessing http://example.com results in a 503 Service Unavailable error. You verify that all pods are running, but kubectl get pods shows the READY column as 0/1 for each pod. The Ingress controller logs show 'upstream connect error or disconnect/reset before headers'. You check the endpoints: 'kubectl get endpoints web-service' shows no endpoints. The pods have the label 'app: web'. What should you do to resolve the issue?

Accepted Answer

Check the container port and readiness probe configuration; the pods may not be listening on the expected port or the readiness probe is failing.. Although the Service's selector 'app: web' matches the pod labels, the absence of endpoints indicates that the pods are not being considered ready by the Service. Since `kubectl get pods` shows the READY column as '0/1', the readiness probes are failing or the container is not successfully listening on the expected port. This prevents the endpoints controller from adding the pod IPs to the Service's Endpoints list. Checking the container port and readiness probe configuration is the correct troubleshooting step.

Answer

Change the Service type to NodePort to bypass the Ingress.

Answer

Update the Ingress to use a different backend service.

Answer

Modify the Service selector to match the pod labels exactly.

Question 14

A pod in the 'production' namespace is in CrashLoopBackOff state. Running 'kubectl describe pod web-app -n production' shows the event 'OOMKilled'. What is the most appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the container spec. OOMKilled means the container exceeded its memory limit. Increasing the memory limit is the correct fix.

Answer

Increase the CPU request for the container

Answer

Delete the namespace and redeploy

Answer

Delete and recreate the pod

Question 15

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

Accepted Answer

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

Answer

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

Answer

Add the ServiceAccount to the cluster-admin group

Answer

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