CKA Practice Test 2 — 30 Questions

Question 1

You run 'kubectl get events --sort-by=.lastTimestamp' and see the following events for a pod: 'Warning FailedScheduling 0/3 nodes are available: 3 Insufficient cpu'. What is the most likely solution?

Accepted Answer

Reduce the CPU request for the pod or remove other workloads to free CPU. The event '0/3 nodes are available: 3 Insufficient cpu' indicates that all three nodes in the cluster lack sufficient allocatable CPU to satisfy the pod's CPU request. The most direct solution is to either reduce the pod's CPU request (so it fits on an existing node) or remove other workloads to free up CPU capacity. This aligns with Kubernetes resource scheduling, where the scheduler only considers requests (not limits) when placing pods.

Answer

Change the scheduler to a different one

Answer

Increase the CPU limit for the pod

Answer

Add more nodes to the cluster

Question 2

Which access mode allows a PersistentVolume to be mounted as read-write by multiple pods across different nodes?

Accepted Answer

ReadWriteMany (RWX). ReadWriteMany (RWX) is the correct access mode because it allows a PersistentVolume to be mounted as read-write by multiple pods simultaneously, even when those pods are scheduled on different nodes. This is the only access mode that supports concurrent read-write access across nodes, which is essential for shared storage solutions like NFS, GlusterFS, or CephFS.

Answer

ReadWriteOnce (RWO)

Answer

ReadWriteOncePod (RWOP)

Answer

ReadOnlyMany (ROX)

Question 3

A Deployment's pod is stuck in Pending state. 'kubectl describe pod' shows Events: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient memory'. What is the likely fix?

Accepted Answer

Increase the memory limit of the pod or add more worker nodes. The error '3 Insufficient memory' indicates that three worker nodes lack the required memory to schedule the pod. Increasing the pod's memory limit (if it's set too high) or adding more worker nodes directly addresses the resource shortage. The control-plane node's taint is irrelevant because the pod is not trying to schedule there; the issue is insufficient memory on the available worker nodes.

Answer

Remove the taint from the control-plane node

Answer

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

Answer

Set nodeSelector to schedule on control-plane nodes

Question 4

An Ingress resource is created with the following spec:

spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

The backend service 'api-service' is in the same namespace as the Ingress. What must be true for the Ingress to route traffic to the service?

Accepted Answer

The service 'api-service' must have a valid ClusterIP and at least one endpoint.. For an Ingress to route traffic to a backend service, the service must have a valid ClusterIP (so the Ingress controller can reach it via the cluster network) and at least one healthy endpoint (i.e., pods matching the service’s selector must be running and ready). The Ingress controller forwards traffic to the service’s ClusterIP on the specified port, not directly to pods, so a ClusterIP and endpoints are essential.

Answer

The Ingress controller must be configured to use the NodePort of the service.

Answer

The service 'api-service' must be of type NodePort.

Answer

The Ingress must have an IngressClass annotation.

Question 5

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

Accepted Answer

A taint on the node that the pod does not tolerate. 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.

Answer

The service account does not exist

Answer

The pod's liveness probe is failing

Answer

The pod's container image does not exist

Question 6

You run 'kubectl get pods' and see a pod with status 'Init:CrashLoopBackOff'. What does this indicate?

Accepted Answer

An init container in the pod is failing and restarting. The status 'Init:CrashLoopBackOff' indicates that an init container within the pod is failing and being repeatedly restarted by Kubernetes. Init containers run sequentially before any main containers start, and if one exits with a non-zero exit code, Kubernetes retries it with an exponential backoff delay, leading to the CrashLoopBackOff state. This is distinct from a main container crash, which would show 'CrashLoopBackOff' without the 'Init:' prefix.

Answer

The pod's init container ran successfully but the main container has not started yet

Answer

The pod is still initializing but will eventually run

Answer

The main container is crashing and the pod is restarting

Question 7

A pod has been restarted multiple times. You want to see the logs from the previous (terminated) container instance. Which command should you use?

Accepted Answer

kubectl logs my-pod -p. The `kubectl logs` command retrieves logs for a container in a pod. To view the logs of a previously terminated container instance, you must use either the `--previous` or `-p` flag. To ensure there is only one correct option, we will change Option D to use an invalid flag (`--past`), leaving Option C (`-p`) as the sole correct answer.

Answer

kubectl logs my-pod -c --previous

Answer

kubectl logs my-pod --tail=100

Answer

kubectl logs my-pod --past

Question 8

You are applying the following RBAC manifest:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Which TWO statements are true about this Role? (Choose TWO.)

Accepted Answer

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

Answer

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

Answer

It grants permissions across all namespaces

Answer

It allows creating pods in the 'development' namespace

Question 9

Which THREE of the following are valid methods to authenticate to the Kubernetes API server? (Select 3)

Accepted Answer

Service account bearer tokens. Service account bearer tokens are a valid authentication method to the Kubernetes API server. When a pod is associated with a service account, Kubernetes automatically mounts a token into the pod at /var/run/secrets/kubernetes.io/serviceaccount/token. This token is a signed JWT that the API server validates against the TokenReview API, allowing the pod to authenticate as that service account.

Answer

Anonymous requests

Answer

Password file with usernames and passwords

Question 10

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

Accepted Answer

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

Answer

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

Answer

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

Answer

The DaemonSet's update strategy is set to OnDelete

Question 11

Which TWO of the following are valid methods to diagnose why a node is in 'NotReady' state?

Accepted Answer

Check the kubelet service logs using 'journalctl -u kubelet'. Checking kubelet logs (journalctl) and verifying the network plugin are both standard troubleshooting steps. Option C (checking API server) is not node-level. Option D (checking kube-proxy) is for service connectivity, not node readiness. Option A (restarting all containers) is not relevant.

Answer

Restart all containers on the node

Answer

Check the kube-apiserver logs on the control plane

Answer

Check kube-proxy configuration

Question 12

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

Accepted Answer

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

Answer

500 megabytes of memory

Answer

50% of the node's CPU capacity

Answer

A limit of 500,000 CPU seconds per day

Question 13

A cluster has a PersistentVolumeClaim (PVC) named 'data-claim' bound to a PersistentVolume (PV) with reclaim policy 'Retain'. The PVC is deleted. The PV now shows status 'Released'. What must be done so that the PV can be reused by a new PVC?

Accepted Answer

Delete and recreate the PersistentVolume.. When a PVC is deleted and the PV has a reclaim policy of 'Retain', the PV enters a 'Released' state, meaning it still contains the data but is no longer bound to the original PVC. The PV cannot be directly reused by a new PVC because its claim reference is still set to the deleted PVC's UID. To make the PV available again, you must manually delete and recreate the PV (or at least delete it and re-create it with a clean claimRef), which resets its status to 'Available'.

Answer

Nothing; the PV will automatically become Available after some time.

Answer

Create a new PVC with the same name.

Answer

Change the reclaim policy to Delete.

Question 14

You are troubleshooting a node that is 'NotReady'. Which THREE of the following are possible causes? (Choose three.)

Accepted Answer

The kubelet cannot contact the API server. The kubelet is the primary node agent that communicates with the API server to report node status, heartbeats, and pod lifecycle events. If the kubelet cannot reach the API server (e.g., due to network partition, TLS certificate issues, or API server downtime), it cannot send the periodic NodeStatus updates, and the control plane marks the node as 'NotReady' after the `node-monitor-grace-period` (default 40 seconds) expires.

Answer

The node has disk pressure

Answer

A pod on the node is consuming excessive memory

Question 15

A NetworkPolicy with podSelector: {} and policyTypes: [Ingress] is applied to a namespace. What is the effect on pods in that namespace?

Accepted Answer

All ingress traffic is denied unless explicitly allowed by another policy.. A NetworkPolicy with `podSelector: {}` selects all pods in the namespace. When `policyTypes: [Ingress]` is set without any ingress rules, it defaults to denying all ingress traffic that is not explicitly allowed by another policy. This is because Kubernetes NetworkPolicy implements an implicit deny for the specified traffic direction when no rules are provided, effectively isolating the pods from inbound connections.

Answer

The policy has no effect because no rules are defined.

Answer

All ingress traffic is allowed.

Answer

All egress traffic is denied.

Question 16

You have a pod that is in CrashLoopBackOff. Which two troubleshooting steps should you take first? (Choose two.)

Accepted Answer

kubectl describe pod pod-name. `kubectl describe pod pod-name` provides detailed information about the pod's current state, including recent events, container restart counts, and the reason for the CrashLoopBackOff (e.g., exit code 137 from OOMKill or 1 from application error). This is the first step to understand the root cause of the crash loop.

Answer

kubectl delete pod pod-name

Answer

kubectl exec -it pod-name -- sh

Answer

kubectl rollout restart deployment

Question 17

A node is in 'NotReady' state. Which TWO of the following are common causes? (Select 2)

Accepted Answer

The kubelet service has stopped on the node. Options C and E are correct. A node becomes 'NotReady' when the kubelet stops reporting its status (C) or when the network plugin (e.g., Calico, Flannel) fails, preventing pod networking (E). Option A (ImagePullBackOff) is a pod-level issue and does not affect node status. Option B (insufficient memory) leads to pod eviction but the node remains Ready if kubelet is healthy. Option D (API server down) affects the entire cluster, but nodes may still show Ready if kubelet is functioning.

Answer

A pod on the node is in ImagePullBackOff

Answer

The node has insufficient memory

Answer

The Kubernetes API server is down

Question 18

You want to check the status of the kube-apiserver on a control plane node. Which commands should you use? (Select the best option)

Accepted Answer

systemctl status kube-apiserver or crictl ps | grep kube-apiserver. On a control plane node, the kube-apiserver runs either as a systemd service or as a static pod managed by the kubelet. If it runs as a systemd service, you check its status using 'systemctl status kube-apiserver'. If it runs as a static pod (as in kubeadm-based clusters), you must inspect the container runtime directly using 'crictl ps | grep kube-apiserver' (or 'docker ps' on older clusters) because 'kubectl' commands will fail if the API server is unresponsive.

Answer

journalctl -u kubelet

Answer

ps aux | grep kube-apiserver

Answer

docker ps | grep kube-apiserver

Question 19

Which access mode allows multiple pods to read and write to a PersistentVolume simultaneously when all pods are on the same node?

Accepted Answer

ReadWriteOnce. ReadWriteOnce (RWO) allows a PersistentVolume to be mounted as read-write by a single node, but multiple pods on that same node can all access the volume simultaneously. This is because the access mode restriction is per node, not per pod, so all pods scheduled on the same node share the same mount and can read and write concurrently.

Answer

ReadOnlyMany

Answer

ReadWriteMany

Answer

ReadWriteOncePod

Question 20

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

Accepted Answer

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

Answer

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

Answer

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

Answer

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