CKA Practice Test 42 — 15 Questions

Question 1

Which THREE are valid steps when upgrading a Kubernetes cluster using kubeadm? (Select 3)

Accepted Answer

Upgrade kubelet and kubectl on the node.. After upgrading kubeadm on the control plane, you must upgrade kubelet and kubectl on each node to match the target Kubernetes version. The kubelet is the primary node agent that communicates with the control plane, and kubectl is the CLI tool used to interact with the cluster. Without upgrading these components, the node may fail to register or report an incompatible version, causing the node to be in a NotReady state.

Answer

Upgrade the container runtime to a compatible version.

Answer

Run 'kubeadm upgrade apply' on the worker node.

Question 2

A developer is creating a Pod with a single container that should restart only if the process exits with non-zero. Which restartPolicy should be used?

Accepted Answer

OnFailure. In Kubernetes, the `restartPolicy` for a Pod controls container restart behavior. The requirement is to restart only when the process exits with a non-zero code, which is exactly what `OnFailure` does. `Always` restarts on any exit (zero or non-zero), `Never` does not restart at all, and `UnlessStopped` is not a valid Kubernetes restart policy (it is a Docker restart policy). Note that while Pods and Jobs support `OnFailure`, workloads like Deployments, StatefulSets, and DaemonSets only support `Always`.

Answer

Never

Answer

Always

Answer

UnlessStopped

Question 3

Which THREE of the following are valid steps to troubleshoot a node that is in 'NotReady' state?

Accepted Answer

Check the kubelet status using 'systemctl status kubelet' on the node. Options A, B, and C are valid troubleshooting steps to investigate a NotReady node. Option A checks if kubelet is running, Option B examines kubelet logs for errors, and Option C shows node conditions. Option D (restarting kubelet) is a remediation action, not a troubleshooting step. Option E (deleting and rejoining) is a recovery step.

Answer

Restart the kubelet using 'systemctl restart kubelet'

Answer

Delete the node object and rejoin it to the cluster

Question 4

You run 'kubectl top nodes' and it returns an error: 'error: metrics not available yet'. What does this indicate?

Accepted Answer

The Metrics Server is not installed or not functioning.. The 'top' command relies on the metrics server to provide resource usage data. The error means the metrics server is not deployed or not ready.

Answer

The kubelet is not running on the nodes.

Answer

The cluster is using an older version of Kubernetes.

Answer

The nodes are under heavy load.

Question 5

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

Accepted Answer

Label SSD nodes with 'disk=ssd' and use nodeSelector in the Pod spec.. 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.

Answer

Use podAffinity to prefer nodes running other Pods.

Answer

Set spec.nodeName to an SSD node's name.

Answer

Add a taint to nodes without SSD and add a toleration to the Pod.

Question 6

You need to temporarily access a pod's HTTP endpoint on port 8080 from your local machine on port 8080. Which kubectl command should you use?

Accepted Answer

kubectl port-forward pod/my-pod 8080:8080. `kubectl port-forward` creates a direct tunnel from a local port to a specific pod, allowing you to access the pod's HTTP endpoint on port 8080 from your local machine on port 8080. This command targets the pod directly (`pod/my-pod`) and maps local port 8080 to the pod's port 8080, which is exactly what the question requires for temporary, ad-hoc access without creating a Service.

Answer

kubectl expose pod my-pod --port=8080

Answer

kubectl proxy --port=8080

Answer

kubectl port-forward service/my-service 8080:8080

Question 7

You see a pod in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 1 node(s) had taint(s) that the pod didn't tolerate, 3 Insufficient cpu'. What should you do?

Accepted Answer

Scale down other deployments to free CPU. The pod is pending due to two issues: taint on one node and insufficient CPU on three nodes. Scaling down other deployments frees CPU resources on nodes, allowing the pod to be scheduled on nodes with sufficient CPU, potentially avoiding the tainted node. Option A only removes the taint but does not solve the CPU shortage. Option C does not affect scheduling. Option D increases CPU requests, worsening the CPU shortage. Therefore, B is the correct action.

Answer

Delete the taint from the node

Answer

Increase the CPU limits only

Answer

Add the required toleration to the pod spec and increase CPU requests

Question 8

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

Accepted Answer

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

Answer

eBPF

Answer

userspace

Answer

kernelnet

Question 9

Which FOUR are correct ways to configure a default deny all ingress traffic NetworkPolicy? (Choose 4)

Accepted Answer

A NetworkPolicy with podSelector: {} and an ingress rule with from: []. Option C is correct because `podSelector: {}` selects all pods in the namespace and `ingress: []` defines an empty ingress rule set, which denies all ingress traffic to those pods. Option D is correct because a NetworkPolicy with `podSelector: {}` and no rules at all (only metadata and spec) has no ingress rules, so it isolates all selected pods and denies all ingress by default. Option E is correct because omitting the `ingress` field entirely is equivalent to having an empty ingress rule set, which denies all ingress traffic to the selected pods. Option A is also correct: an ingress rule with `from: []` contains an empty list of sources, which matches no sources and therefore allows no ingress traffic; the presence of the rule does not permit traffic because no source matches. Option B is incorrect because `from: [{}]` contains an empty object, which matches all sources and therefore allows all ingress traffic, the opposite of deny all.

Answer

A NetworkPolicy with podSelector: {} and an ingress rule with from: [{}]

Question 10

Which THREE components are part of the Gateway API?

Accepted Answer

Gateway. The Gateway API is a Kubernetes SIG-Network set of role-oriented, portable, and expressive routing resources, and its core object model consists of GatewayClass, Gateway, and route resources such as HTTPRoute. Option A, Gateway, is correct because it represents a deployed instance of a gateway (a data-plane load balancer/proxy) that listeners and routes attach to. Option D, HTTPRoute, is correct because it is one of the standard route types that defines HTTP/HTTPS routing rules and binds to a Gateway listener. Option E, GatewayClass, is correct because it is the cluster-scoped template that defines the controller implementation and configuration for Gateways, analogous to IngressClass. Option B, Service, is not part of the Gateway API itself; it is a core Kubernetes resource used for exposing pods and may be referenced as a backend, but it is not a Gateway API component. Option C, Ingress, is not part of the Gateway API; it is the older, separate Kubernetes Ingress resource that the Gateway API is intended to supersede.

Answer

Service

Answer

Ingress

Question 11

A cluster administrator creates a PersistentVolume with the following YAML:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /data/pv

A user creates a PersistentVolumeClaim requesting 500Mi with access mode ReadWriteOnce and no storage class. The PVC remains in Pending state. What is the most likely cause?

Accepted Answer

The cluster has a default StorageClass defined, causing the PVC to attempt dynamic provisioning instead of binding to this static PV.. When a default StorageClass exists in the cluster, a PVC with no storage class name specified will automatically trigger dynamic provisioning via that default StorageClass, rather than attempting to bind to an existing static PV. This causes the PVC to remain in Pending state if the dynamic provisioner cannot fulfill the request (e.g., due to missing CSI driver or cloud provider configuration). The static PV pv-example is ignored because the PVC's provisioning mechanism is overridden by the default StorageClass.

Answer

The PV's reclaim policy is Retain, so it is in Released state and cannot be bound to a new PVC.

Answer

The hostPath path /data/pv does not exist on any node in the cluster.

Answer

The PVC requests 500Mi, but the PV has 1Gi capacity, which is larger than requested, so the PVC cannot bind to it.

Question 12

A Kubernetes cluster has a Service of type ClusterIP named 'my-svc' in the 'default' namespace. You deploy a pod and want it to resolve the service's cluster IP using DNS. What FQDN should the pod use?

Accepted Answer

my-svc.default.svc.cluster.local. The standard FQDN for a Kubernetes Service is `..svc.cluster.local`. This DNS record resolves to the ClusterIP of the Service, allowing pods to reach it via DNS. The `svc` subdomain is a fixed part of the cluster domain, distinguishing Service records from pod records.

Answer

my-svc.default.pods.cluster.local

Answer

my-svc.cluster.local

Answer

my-svc.default.svc.cluster.com

Question 13

You have a Service 'my-svc' with ClusterIP None (headless). You create a StatefulSet with 3 replicas and a headless Service. How do you reach individual pods?

Accepted Answer

Use the pod DNS name: .my-svc..svc.cluster.local. In a headless Service (ClusterIP: None), Kubernetes creates DNS A/AAAA records for each pod in a StatefulSet using the pattern ...svc.cluster.local. This allows direct, stable network identity for each pod, which is essential for stateful applications like databases that require consistent hostnames.

Answer

Use the Service name 'my-svc' which will round-robin between pods

Answer

Use the Service's ClusterIP (None) to reach all pods

Answer

You cannot reach individual pods directly; you must use the Service name

Question 14

A team is configuring etcd for a multi-node Kubernetes cluster. They want to ensure that etcd data is encrypted at rest. Which approach should they use?

Accepted Answer

Create an EncryptionConfiguration resource specifying a provider like 'aescbc' and configure the kube-apiserver with --encryption-provider-config.. Kubernetes supports encrypting secrets and other resources at rest via an EncryptionConfiguration object, which is passed to the kube-apiserver using the --encryption-provider-config flag. This mechanism encrypts data before it is written to etcd, ensuring that even if the etcd storage is compromised, the data remains unreadable without the encryption key.

Answer

Use LUKS to encrypt the disk partition where etcd data is stored.

Answer

Use TLS certificates to encrypt communication between etcd and the API server.

Answer

Configure etcd to use encryption at rest by setting --experimental-encryption-provider.

Question 15

To view the logs of a specific container in a multi-container pod named 'web-pod', which command is correct?

Accepted Answer

kubectl logs web-pod --container app-container. The correct command is 'kubectl logs web-pod -c app-container'. The -c flag specifies the container name.

Answer

kubectl logs web-pod --all-containers

Answer

kubectl logs app-container -p web-pod

Answer

kubectl logs -c web-pod app-container