CKA Practice Test 32 — 15 Questions

Question 1

Which THREE of the following are true about the interaction between PersistentVolumeClaims and pods?

Accepted Answer

A PVC is namespace-scoped and can only be used by pods in the same namespace. Option A is correct because PersistentVolumeClaims are namespace-scoped API objects, so a pod can only reference a PVC that exists in its own namespace. Option D is correct because a pod that references a PVC requires that claim to exist and be bound (or bindable) before the pod can be successfully scheduled and started. Option E is correct because a PVC's access modes determine multi-pod use: ReadWriteMany or ReadOnlyMany allow multiple pods to mount the same claim, while ReadWriteOnce restricts it to a single node. Option B is wrong because a PVC can be shared by multiple pods when the access mode permits it, such as ReadWriteMany. Option C is wrong because deleting a pod does not delete its PVC; the claim persists until it is explicitly deleted, and its reclaim policy governs the underlying PersistentVolume.

Answer

A PVC can only be used by a single pod at a time

Answer

When a pod is deleted, its attached PVC is automatically deleted

Question 2

An administrator runs `kubectl port-forward service/my-svc 8080:80`. What does this command do?

Accepted Answer

Forwards local port 8080 to port 80 on the Service. `kubectl port-forward` creates a tunnel from a local port to a pod (or service) in the cluster. When targeting a Service, it selects one of the Service's endpoints (a pod) and forwards traffic from localhost:8080 to port 80 on that pod. This allows direct access to the Service without exposing it externally.

Answer

Creates a new Service with port mapping 8080:80

Answer

Forwards port 8080 from the Service to port 80 on the local machine

Answer

Forwards port 80 from the local machine to port 8080 on the Service

Question 3

You need to create a Kubernetes ServiceAccount named 'build-bot' and ensure that pods using this ServiceAccount can authenticate to the Kubernetes API using a long-lived token. Which TWO steps are necessary? (Choose TWO.)

Accepted Answer

Create a ServiceAccount object named 'build-bot'. Creating a ServiceAccount named 'build-bot' is the foundational step; without the ServiceAccount object, no pods can be assigned a service account identity. Option E is correct because a Secret of type 'kubernetes.io/service-account-token' with an annotation referencing the ServiceAccount causes the Kubernetes controller manager to automatically generate and populate a long-lived token, which pods can mount and use to authenticate to the API server.

Answer

Create a Secret of type 'Opaque' with the token data

Answer

Run 'kubectl create token build-bot'

Answer

Use the TokenRequest API to generate a token

Question 4

Which TWO of the following kubectl commands can be used to view the logs of a container in a pod? (Choose two.)

Accepted Answer

kubectl logs pod-name. Option B, `kubectl logs pod-name`, is correct because the `kubectl logs` command is the dedicated subcommand for retrieving the stdout/stderr output of a container in a pod, and with a single container it defaults to that container. Option E, `kubectl logs pod-name --previous`, is also correct because the `--previous` (or `-p`) flag retrieves the logs from the previous, terminated instance of the container in the pod, which is still a valid way to view container logs. Option A, `kubectl describe pod pod-name`, is not correct because describe shows pod metadata, events, and status, not the container's log stream. Option C, `kubectl exec pod-name -- logs`, is not correct because it attempts to run a `logs` binary inside the container rather than using the Kubernetes logs API. Option D, `kubectl get pod pod-name -o yaml`, is not correct because it only outputs the pod's YAML manifest/status, not its container logs.

Answer

kubectl describe pod pod-name

Answer

kubectl exec pod-name -- logs

Answer

kubectl get pod pod-name -o yaml

Question 5

You run 'kubectl get pods' and see that a pod named 'db' is in 'CrashLoopBackOff'. Which TWO commands are most useful for diagnosing the issue? (Choose two)

Accepted Answer

kubectl describe pod db. Option B, 'kubectl describe pod db', is correct because it surfaces the pod's Events section, which shows scheduling failures, image pull errors, container restarts, and the exit codes/reasons behind the CrashLoopBackOff. Option C, 'kubectl logs db', is correct because it retrieves the container's stdout/stderr, revealing the application-level error or stack trace that caused the process to exit and restart repeatedly. Together these two commands cover both the kubelet-side view (describe) and the application-side view (logs) of why the container keeps crashing. Option A, 'kubectl top pod db', only reports CPU/memory usage and cannot explain a crash loop, and it often fails anyway if the container isn't running. Option D, 'kubectl get pod db -o yaml', shows the pod spec and status but not the event history or application output needed to diagnose the crash. Option E, 'kubectl exec db -- /bin/sh', is not useful because the container is not staying up long enough to exec into, and it doesn't reveal the prior crash cause.

Answer

kubectl top pod db

Answer

kubectl get pod db -o yaml

Answer

kubectl exec db -- /bin/sh

Question 6

You are troubleshooting a pod that is in 'CrashLoopBackOff' state. You run 'kubectl logs mypod' and get no output. You then run 'kubectl logs mypod --previous' and see an error: 'Error: failed to start container: context deadline exceeded'. What is the MOST likely cause?

Accepted Answer

The container runtime is unable to start the container due to a timeout. The error 'failed to start container: context deadline exceeded' indicates the container runtime (containerd/CRI-O) could not start the container within the allotted timeout, typically due to image pull slowness, runtime hang, or resource pressure. Because kubectl logs with --previous shows this runtime-level error rather than an application stack trace, the root cause is the runtime failing to launch the container, not the app crashing.

Answer

The container image is missing the entrypoint

Answer

The application inside the container is crashing immediately

Answer

The container command is incorrectly specified

Question 7

You have a service 'my-svc' of type ClusterIP with no selector defined. You manually create an Endpoints object with the same name. Which statement is true?

Accepted Answer

The service will route traffic to the IPs defined in the Endpoints object.. A Kubernetes Service without a selector relies on a manually created Endpoints object to define the backend targets. The Service's ClusterIP will route traffic to the IP addresses and ports specified in the Endpoints object, as long as the Endpoints object has the same name as the Service and the Service's ports match the Endpoints' ports. This is a common pattern for routing traffic to external resources or services not managed by Kubernetes.

Answer

The service will automatically create an Endpoints object based on the service ports.

Answer

The Endpoints object must have the same labels as the service.

Answer

The service must be of type ExternalName to use manually created Endpoints.

Question 8

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

Accepted Answer

Mount a ConfigMap as a volume.. 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).

Answer

Use a Secret as a ConfigMap data source.

Answer

Use 'kubectl inject configmap' to inject data at runtime.

Question 9

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'?

Accepted Answer

Yes, because the new policy allows traffic to pods with label 'app: web'. 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.

Answer

No, because the new policy's empty podSelector selects all pods but does not specify a source

Answer

Yes, because the default-deny policy is ignored when a new policy exists

Answer

No, because the default-deny policy takes precedence

Question 10

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.. 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 11

A NetworkPolicy allows ingress traffic from pods with label 'app: frontend' in any namespace. Which selector is used?

Accepted Answer

spec.ingress[0].from[0].namespaceSelector: {} and spec.ingress[0].from[0].podSelector: { matchLabels: { app: frontend } }. To allow ingress traffic from pods with label 'app: frontend' in any namespace, you must combine an empty namespaceSelector (which selects all namespaces) with a podSelector that matches the pod label. This combination tells Kubernetes to allow traffic from any pod matching the label, regardless of which namespace it resides in. Without the namespaceSelector, the podSelector would only apply to pods in the same namespace as the NetworkPolicy.

Answer

spec.ingress[0].from[0].podSelector: { matchLabels: { app: frontend } }

Answer

spec.ingress[0].from[0].ipBlock: { cidr: 0.0.0.0/0 }

Answer

spec.ingress[0].from[0].namespaceSelector: { matchLabels: { app: frontend } }

Question 12

A pod is in 'ImagePullBackOff' state. Which of the following is NOT a common cause?

Accepted Answer

The container requires more memory than the limit allows. ImagePullBackOff means the kubelet repeatedly failed to pull the container image and is backing off before retrying. Memory limits are enforced at container runtime after the image is pulled and the container starts, so an insufficient memory limit would cause OOMKilled or scheduling failures — not an image pull error. Therefore, 'requires more memory than the limit allows' is NOT a common cause of ImagePullBackOff.

Answer

The image registry requires authentication and no imagePullSecrets are configured

Answer

The image tag does not exist

Answer

The image name is misspelled

Question 13

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

Accepted Answer

Node has insufficient CPU or memory resources. Option A is correct because when a node lacks sufficient allocatable CPU or memory, the kube-scheduler cannot find a feasible node and leaves the pod in Pending with a FailedScheduling event. Option C is correct because a pod that references a PersistentVolumeClaim that is not yet Bound (for example, waiting on a dynamic provisioner or a matching PersistentVolume) will remain Pending until the PVC binds. Option B is incorrect because a non-zero container exit code indicates a runtime failure after the container started, producing CrashLoopBackOff or Error, not Pending. Option D is incorrect because OOMKilled occurs when a running container exceeds its memory limit, resulting in a terminated container rather than a Pending pod. Option E is incorrect because a misspelled image name causes an ImagePullBackOff/ErrImagePull status once the kubelet attempts to pull the image, not a Pending phase.

Answer

Container exited with non-zero exit code

Answer

Container was killed due to OOM

Answer

Image name is misspelled

Question 14

You have a Pod that is stuck in Pending state. Running 'kubectl describe pod' shows events: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, 3 node(s) had taint {key: value}, that the pod didn't tolerate.' How can you resolve this issue?

Accepted Answer

Add appropriate tolerations to the Pod's spec. The Pod is stuck in Pending because none of the nodes can schedule it due to taints that the Pod does not tolerate. Option D is correct because adding the appropriate tolerations to the Pod's spec tells the scheduler that the Pod can tolerate those taints, allowing it to be scheduled on the tainted nodes. This directly addresses the mismatch between node taints and Pod tolerations. A common misconception in the CKA exam is that removing taints from nodes is the only fix, but the correct Kubernetes approach is to add tolerations to the Pod spec, preserving node isolation for other workloads.

Answer

Increase the Pod's resource requests

Answer

Remove the taints from all nodes using 'kubectl taint nodes --all key:value-'

Answer

Delete the Pod and recreate it with a different name

Question 15

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?

Accepted Answer

Install a pod network add-on such as Flannel.. 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.

Answer

Increase the apiserver-advertise-address to match the node's external IP.

Answer

Run kubeadm join on the control plane node.

Answer

Restart the kubelet service on all nodes.