CKA Quick Quiz — 10 Questions

Question 1

Which TWO of the following are valid ways to ensure that a Pod runs on a node that has a GPU? (Choose TWO.)

Accepted Answer

Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution matching a label that identifies GPU nodes.. Option B is correct because nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution allows you to schedule a Pod only onto nodes that match specific labels, such as a label like 'gpu=true' that identifies GPU-equipped nodes. This ensures the Pod is placed on a node with a GPU without relying on resource requests or taints.

Answer

Set resource requests for 'gpu' in the container spec.

Answer

Set nodeName to the name of a specific GPU node.

Answer

Add a toleration for a taint that GPU nodes have.

Question 2

An administrator needs to upgrade the kube-apiserver on a control plane node from version 1.22.0 to 1.23.0. Which of the following is the correct order of steps?

Accepted Answer

Drain node, upgrade kubeadm, upgrade kubelet, uncordon node.. Option B is correct because when upgrading the kube-apiserver, the standard workflow is to first drain the node to evict pods, then upgrade kubeadm (which manages the control plane components), then upgrade kubelet (which runs on the node), and finally uncordon the node to make it schedulable again. This sequence ensures that the node is safely taken out of service before any changes are made, and that the upgrade tools are updated before the components they manage.

Answer

Upgrade kubelet, upgrade kubeadm, drain node, uncordon node.

Answer

Upgrade kubeadm, drain node, upgrade kubelet, uncordon node.

Answer

Upgrade kubeadm, upgrade kubelet, drain node, uncordon node.

Question 3

A cluster is running on a cloud provider that supports load balancers. An administrator needs to expose a service externally using a cloud load balancer. However, the service remains in 'Pending' state. The cloud provider requires the cluster to be configured with the correct cloud provider flag. Which kube-controller-manager flag is required for this integration?

Accepted Answer

--cloud-provider. The `--cloud-provider` flag on the kube-controller-manager tells Kubernetes which cloud provider integration to use (e.g., `aws`, `gce`, `azure`). Without this flag set to the correct provider, the cloud controller manager cannot provision a load balancer for a Service of type LoadBalancer, leaving it in 'Pending' state because the external IP allocation never completes.

Answer

--cloud-controller-manager

Answer

--configure-cloud-routes

Answer

--cloud-config

Question 4

An administrator notices that traffic to a Service is not being forwarded to any pod. The Service has selector 'app: web' and there are pods with that label. However, 'kubectl get endpoints' shows no endpoints. What is the most likely cause?

Accepted Answer

The pods are not in Ready state (e.g., failing readiness probes).. The most likely cause is that the pods are not in Ready state, often due to failing readiness probes. Kubernetes endpoints are only populated for pods that pass their readiness checks; if a pod is not Ready, it is removed from the Service's endpoint list, even if it is running and has the correct labels.

Answer

The Service port name does not match the container port name.

Answer

The Service type is ClusterIP.

Answer

The Service targetPort is not specified.

Question 5

Which TWO of the following are valid commands to upgrade a kubeadm cluster from version 1.22.x to 1.23.x on the control plane node? Assume the node is already drained.

Accepted Answer

kubeadm upgrade apply v1.23.0. Option A is correct because `kubeadm upgrade apply v1.23.0` is the explicit command to upgrade the control plane to a specific version (v1.23.0) in a kubeadm cluster. It validates the upgrade path, uploads the new configuration, and applies the upgrade to the control plane components. The node is already drained, so this command proceeds directly with the upgrade.

Answer

kubeadm upgrade node

Answer

kubeadm upgrade plan v1.23.0

Answer

kubeadm upgrade diff

Question 6

A user tries to create a pod with the YAML file that requests 2 CPUs as a limit. The cluster has a ResourceQuota named 'compute-quota' with limits.cpu: 2. The user sees the above error. What is the likely issue?

Accepted Answer

The current total CPU limit usage in the namespace is 1, and adding a pod with limit 2 would exceed the quota of 2.. Option D is correct because the ResourceQuota 'compute-quota' sets a hard limit of 2 CPUs for all pods in the namespace. If the current total CPU limit usage is already 1, adding a new pod with a limit of 2 would bring the total to 3, exceeding the quota. Kubernetes enforces ResourceQuota at admission time, rejecting the pod creation to prevent the namespace from exceeding its configured limits.

Answer

The pod is requesting 2 CPUs as a request, but the quota limits requests.

Answer

The pod is being created in the wrong namespace.

Answer

The pod is trying to use more CPU than the node capacity.

Question 7

A pod is running with the default DNS policy. The cluster DNS service is at 10.96.0.10. The node's /etc/resolv.conf has nameserver 8.8.8.8. When the pod tries to resolve an external hostname like 'example.com', which DNS server will it query first?

Accepted Answer

The cluster DNS service (10.96.0.10). With the default DNS policy (ClusterFirst), pods are configured to use the cluster DNS service (10.96.0.10) as the first nameserver in their /etc/resolv.conf. This is achieved by kubelet injecting the cluster DNS IP and a search domain into the pod's resolv.conf. Therefore, the pod will query the cluster DNS service first for any hostname resolution, including external names like 'example.com'.

Answer

The node's DNS server (8.8.8.8)

Answer

There is no DNS resolution; the pod cannot resolve external names by default

Answer

The pod's own /etc/resolv.conf which contains the node's DNS

Question 8

A cluster uses etcd with TLS encryption. Which THREE of the following are valid etcd client certificate authentication flags?

Accepted Answer

--trusted-ca-file. Option B is correct because `--trusted-ca-file` specifies the CA certificate used to validate client certificates when client certificate authentication is enabled. This flag is required for etcd to trust incoming client connections that present a certificate signed by the specified CA, forming the basis of mutual TLS (mTLS) authentication.

Answer

--client-cert-auth

Answer

--peer-cert-file

Question 9

An administrator needs to expose a set of pods running a stateful application that require stable network identities. The pods must be reachable from outside the cluster via a DNS name that resolves to individual pod IPs. Which Service type should be used?

Accepted Answer

Headless Service (ClusterIP: None). A Headless Service (ClusterIP: None) is correct because it allows clients to discover individual pod IPs via DNS lookups, returning A/AAAA records for each pod rather than a single ClusterIP. This provides stable network identities for stateful pods, as each pod gets a unique DNS name (e.g., pod-name.service-name.namespace.svc.cluster.local) that resolves directly to its IP, enabling external access through a DNS-based discovery mechanism.

Answer

ExternalName Service

Answer

NodePort Service

Answer

ClusterIP with a regular Service

Question 10

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 and ready (kubectl get pods shows 3/3 ready). 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.. Option C is correct because the absence of endpoints for the Service indicates that the Service's selector is not matching any pods, or the pods are not listening on the correct port. Since the pods have the label 'app: web' and the Service uses 'app: web', the issue is likely that the container port (3000) is misconfigured or the readiness probe is failing, causing the pods to be removed from the Service's endpoints. The Ingress controller's 'upstream connect error' confirms that traffic cannot reach the pods, which aligns with the missing endpoints.

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.