Sample questions
Certified Kubernetes Administrator CKA practice questions
Which TWO of the following are valid ways to ensure that a Pod runs on a node that has a GPU? (Choose TWO.)
Trap 1: Set resource requests for 'gpu' in the container spec.
GPUs are not standard resources; they are extended resources and must be requested with their specific name (e.g., nvidia.com/gpu).
Trap 2: Set nodeName to the name of a specific GPU node.
nodeName is too rigid and does not leverage node capabilities; it also does not check for GPU availability.
Trap 3: Add a toleration for a taint that GPU nodes have.
Tolerations allow scheduling on tainted nodes but do not guarantee the node has a GPU.
- A
Set resource requests for 'gpu' in the container spec.
Why wrong: GPUs are not standard resources; they are extended resources and must be requested with their specific name (e.g., nvidia.com/gpu).
- B
Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution matching a label that identifies GPU nodes.
Node affinity can force scheduling on nodes with a specific label, such as 'gpu=true'.
- C
Set nodeName to the name of a specific GPU node.
Why wrong: nodeName is too rigid and does not leverage node capabilities; it also does not check for GPU availability.
- D
Add a toleration for a taint that GPU nodes have.
Why wrong: Tolerations allow scheduling on tainted nodes but do not guarantee the node has a GPU.
- E
Set resource requests for 'nvidia.com/gpu' in the container spec and ensure the node has that resource.
This is the standard way to request GPU resources via extended resources.
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?
Trap 1: Upgrade kubelet, upgrade kubeadm, drain node, uncordon node.
kubelet upgrade before kubeadm can cause version mismatch.
Trap 2: Upgrade kubeadm, drain node, upgrade kubelet, uncordon node.
Upgrading kubeadm before draining is acceptable but not best practice; however, the order of kubelet and uncordon is wrong.
Trap 3: Upgrade kubeadm, upgrade kubelet, drain node, uncordon node.
Draining should happen before any upgrade to prevent disruption.
- A
Upgrade kubelet, upgrade kubeadm, drain node, uncordon node.
Why wrong: kubelet upgrade before kubeadm can cause version mismatch.
- B
Drain node, upgrade kubeadm, upgrade kubelet, uncordon node.
Draining first ensures no workloads are disrupted.
- C
Upgrade kubeadm, drain node, upgrade kubelet, uncordon node.
Why wrong: Upgrading kubeadm before draining is acceptable but not best practice; however, the order of kubelet and uncordon is wrong.
- D
Upgrade kubeadm, upgrade kubelet, drain node, uncordon node.
Why wrong: Draining should happen before any upgrade to prevent disruption.
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?
Trap 1: --cloud-controller-manager
This is not a valid flag; cloud controller manager is a separate component.
Trap 2: --configure-cloud-routes
This is for route configuration, not enabling cloud provider.
Trap 3: --cloud-config
This specifies the cloud config file, but the main flag is --cloud-provider.
- A
--cloud-provider
This flag enables the cloud provider integration.
- B
--cloud-controller-manager
Why wrong: This is not a valid flag; cloud controller manager is a separate component.
- C
--configure-cloud-routes
Why wrong: This is for route configuration, not enabling cloud provider.
- D
--cloud-config
Why wrong: This specifies the cloud config file, but the main flag is --cloud-provider.
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?
Trap 1: The Service port name does not match the container port name.
Port names are optional; if not used, matching is by port number.
Trap 2: The Service type is ClusterIP.
ClusterIP Services can have endpoints.
Trap 3: The Service targetPort is not specified.
If targetPort is omitted, it defaults to the same as port.
- A
The Service port name does not match the container port name.
Why wrong: Port names are optional; if not used, matching is by port number.
- B
The Service type is ClusterIP.
Why wrong: ClusterIP Services can have endpoints.
- C
The Service targetPort is not specified.
Why wrong: If targetPort is omitted, it defaults to the same as port.
- D
The pods are not in Ready state (e.g., failing readiness probes).
Only Ready pods are included as endpoints.
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.
Trap 1: kubeadm upgrade node
This is used for upgrading worker nodes, not control plane.
Trap 2: kubeadm upgrade plan v1.23.0
'plan' does not take a version argument; it shows available upgrades.
Trap 3: kubeadm upgrade diff
This command does not exist.
- A
kubeadm upgrade apply v1.23.0
This applies the upgrade to the specified version.
- B
kubeadm upgrade node
Why wrong: This is used for upgrading worker nodes, not control plane.
- C
kubeadm upgrade plan v1.23.0
Why wrong: 'plan' does not take a version argument; it shows available upgrades.
- D
kubeadm upgrade plan
This shows the available versions and upgrade steps.
- E
kubeadm upgrade diff
Why wrong: This command does not exist.
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?
Exhibit
Refer to the exhibit. Error from server: error when creating "pod.yaml": pods "my-pod" is forbidden: exceeded quota: compute-quota, requested: limits.cpu=2, used: limits.cpu=1, limited: limits.cpu=2
Trap 1: The pod is requesting 2 CPUs as a request, but the quota limits…
The error says limits.cpu.
Trap 2: The pod is being created in the wrong namespace.
The error does not indicate a namespace mismatch.
Trap 3: The pod is trying to use more CPU than the node capacity.
The error is about ResourceQuota, not node capacity.
- A
The pod is requesting 2 CPUs as a request, but the quota limits requests.
Why wrong: The error says limits.cpu.
- B
The pod is being created in the wrong namespace.
Why wrong: The error does not indicate a namespace mismatch.
- C
The pod is trying to use more CPU than the node capacity.
Why wrong: The error is about ResourceQuota, not node capacity.
- D
The current total CPU limit usage in the namespace is 1, and adding a pod with limit 2 would exceed the quota of 2.
The quota allows a total of 2, and 1 is already used, leaving only 1 available.
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?
Trap 1: The node's DNS server (8.8.8.8)
The pod does not directly use the node's resolv.conf; it uses the cluster DNS.
Trap 2: There is no DNS resolution; the pod cannot resolve external names…
External resolution works via cluster DNS forwarding.
Trap 3: The pod's own /etc/resolv.conf which contains the node's DNS
The pod's resolv.conf is set by kubelet to point to cluster DNS.
- A
The node's DNS server (8.8.8.8)
Why wrong: The pod does not directly use the node's resolv.conf; it uses the cluster DNS.
- B
There is no DNS resolution; the pod cannot resolve external names by default
Why wrong: External resolution works via cluster DNS forwarding.
- C
The cluster DNS service (10.96.0.10)
Default policy sends queries to the cluster DNS first.
- D
The pod's own /etc/resolv.conf which contains the node's DNS
Why wrong: The pod's resolv.conf is set by kubelet to point to cluster DNS.
A cluster uses etcd with TLS encryption. Which THREE of the following are valid etcd client certificate authentication flags?
Trap 1: --client-cert-auth
This flag enables client certificate authentication, but is not a certificate file flag.
Trap 2: --peer-cert-file
This is for peer communication, not client authentication.
- A
--client-cert-auth
Why wrong: This flag enables client certificate authentication, but is not a certificate file flag.
- B
--trusted-ca-file
Specifies the trusted CA certificate for verifying client certificates.
- C
--cert-file
Specifies the client certificate for etcd.
- D
--key-file
Specifies the client key file.
- E
--peer-cert-file
Why wrong: This is for peer communication, not client authentication.
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?
Trap 1: ExternalName Service
ExternalName is used to alias an external DNS name, not for internal pods.
Trap 2: NodePort Service
NodePort exposes on each node's port but does not provide per-pod DNS.
Trap 3: ClusterIP with a regular Service
Regular ClusterIP Service provides a single virtual IP, not per-pod DNS.
- A
ExternalName Service
Why wrong: ExternalName is used to alias an external DNS name, not for internal pods.
- B
NodePort Service
Why wrong: NodePort exposes on each node's port but does not provide per-pod DNS.
- C
ClusterIP with a regular Service
Why wrong: Regular ClusterIP Service provides a single virtual IP, not per-pod DNS.
- D
Headless Service (ClusterIP: None)
Headless Service returns individual pod IPs via DNS, suitable for stateful apps.
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?
Trap 1: Change the Service type to NodePort to bypass the Ingress.
Changing Service type does not affect endpoint creation; the root cause is missing endpoints.
Trap 2: Update the Ingress to use a different backend service.
The Ingress is correctly configured; the issue is with the Service itself.
Trap 3: Modify the Service selector to match the pod labels exactly.
The selector already matches 'app: web'; this would not change anything.
- A
Change the Service type to NodePort to bypass the Ingress.
Why wrong: Changing Service type does not affect endpoint creation; the root cause is missing endpoints.
- B
Update the Ingress to use a different backend service.
Why wrong: The Ingress is correctly configured; the issue is with the Service itself.
- C
Check the container port and readiness probe configuration; the pods may not be listening on the expected port or the readiness probe is failing.
Empty endpoints indicate no ready pods matching the selector; despite 'Ready' status, the readiness probe might be failing if not configured, or the container might not be listening on 3000.
- D
Modify the Service selector to match the pod labels exactly.
Why wrong: The selector already matches 'app: web'; this would not change anything.
An administrator runs 'kubeadm init' on a machine that previously had a Kubernetes cluster. The command fails with the above errors. What is the best course of action?
Trap 1: Manually delete the /etc/kubernetes/manifests/kube-apiserver.yaml…
This is not the recommended approach; kubeadm reset is safer.
Trap 2: Use a different port for the API server by specifying…
This would workaround but not clean up the existing cluster state.
Trap 3: Run kubeadm init with --force flag to override the errors.
There is no --force flag for kubeadm init.
- A
Run 'kubeadm reset' to clean up the previous installation and then re-run kubeadm init.
kubeadm reset removes the cluster state and configuration.
- B
Manually delete the /etc/kubernetes/manifests/kube-apiserver.yaml file and kill the process using port 6443.
Why wrong: This is not the recommended approach; kubeadm reset is safer.
- C
Use a different port for the API server by specifying --apiserver-bind-port.
Why wrong: This would workaround but not clean up the existing cluster state.
- D
Run kubeadm init with --force flag to override the errors.
Why wrong: There is no --force flag for kubeadm init.
A developer created a Deployment with 3 replicas and a ClusterIP Service named 'app-service' on port 80 targeting port 8080 on the pods. Pod logs show that the container is listening on 8080, but curl from another pod in the same namespace to http://app-service:80 fails with 'Connection refused'. What is the most likely cause?
Trap 1: The container port is 8080 but the Service targetPort is 80.
The Service targetPort is 8080, which matches the container port.
Trap 2: The Service type should be NodePort for inter-pod communication.
ClusterIP is sufficient for inter-pod communication within the cluster.
Trap 3: The DNS resolution for 'app-service' is failing.
DNS resolution would result in a different error (name resolution failure).
- A
The Service selector does not match the pod labels.
If labels don't match, the Service has no endpoints, causing connection refused.
- B
The container port is 8080 but the Service targetPort is 80.
Why wrong: The Service targetPort is 8080, which matches the container port.
- C
The Service type should be NodePort for inter-pod communication.
Why wrong: ClusterIP is sufficient for inter-pod communication within the cluster.
- D
The DNS resolution for 'app-service' is failing.
Why wrong: DNS resolution would result in a different error (name resolution failure).
A cluster has multiple namespaces: 'frontend', 'backend', and 'monitoring'. A pod in the 'frontend' namespace needs to reach a Service named 'db-service' in the 'backend' namespace. The 'db-service' Service is of type ClusterIP. Which DNS name should the pod use?
Trap 1: db-service.svc.cluster.local
Missing the namespace component.
Trap 2: db-service
This only works if the Service is in the same namespace.
Trap 3: db-service.backend.cluster.local
Incorrect domain; should be 'svc.cluster.local'.
- A
db-service.svc.cluster.local
Why wrong: Missing the namespace component.
- B
db-service
Why wrong: This only works if the Service is in the same namespace.
- C
db-service.backend.cluster.local
Why wrong: Incorrect domain; should be 'svc.cluster.local'.
- D
db-service.backend.svc.cluster.local
This is the correct FQDN for cross-namespace access.
A node named 'node1' is having issues. You want to prevent any new pods from being scheduled onto it without affecting running pods. Which command should you use?
Trap 1: kubectl drain node1
Drain evicts pods, which you don't want.
Trap 2: kubectl taint nodes node1 key=value:NoSchedule
Taint prevents scheduling but also affects tolerations; cordon is simpler.
Trap 3: kubectl delete node node1
Deletes the node object.
- A
kubectl drain node1
Why wrong: Drain evicts pods, which you don't want.
- B
kubectl cordon node1
Correct: cordon marks node unschedulable.
- C
kubectl taint nodes node1 key=value:NoSchedule
Why wrong: Taint prevents scheduling but also affects tolerations; cordon is simpler.
- D
kubectl delete node node1
Why wrong: Deletes the node object.
An administrator runs 'kubeadm certs check-expiration' and sees that the kubelet client certificate expires in 7 days. What is the correct way to renew it?
Trap 1: Run 'kubeadm init phase certs kubelet-client'
This command does not exist; certs are renewed with 'kubeadm certs renew'.
Trap 2: Renew all certificates using 'kubeadm certs renew all'
This renews all, but the question asks for the kubelet client certificate specifically.
Trap 3: Delete the old certificate and restart kubelet
Not a best practice; kubeadm provides renewal commands.
- A
Run 'kubeadm init phase certs kubelet-client'
Why wrong: This command does not exist; certs are renewed with 'kubeadm certs renew'.
- B
Renew all certificates using 'kubeadm certs renew all'
Why wrong: This renews all, but the question asks for the kubelet client certificate specifically.
- C
Run 'kubeadm certs renew kubelet-client'
Correct: renews the kubelet client certificate.
- D
Delete the old certificate and restart kubelet
Why wrong: Not a best practice; kubeadm provides renewal commands.
You want to grant a user read-only access to all pods in the 'development' namespace. Which RBAC resource should you create?
Trap 1: ClusterRoleBinding with get, list, watch on pods
ClusterRoleBinding grants cluster-wide access.
Trap 2: ClusterRole with get, list, watch on pods
ClusterRole grants access across all namespaces unless bound with RoleBinding.
Trap 3: RoleBinding referencing a ClusterRole that has get, list, watch on…
This would also grant access but requires extra steps; a Role is simpler and more direct.
- A
ClusterRoleBinding with get, list, watch on pods
Why wrong: ClusterRoleBinding grants cluster-wide access.
- B
Role in the development namespace with get, list, watch on pods
Correct: Role scoped to namespace.
- C
ClusterRole with get, list, watch on pods
Why wrong: ClusterRole grants access across all namespaces unless bound with RoleBinding.
- D
RoleBinding referencing a ClusterRole that has get, list, watch on pods
Why wrong: This would also grant access but requires extra steps; a Role is simpler and more direct.
A pod in the same namespace tries to reach 'my-service' on port 80, but gets 'Connection refused'. The pod's labels are 'app: my-app'. What is the most likely cause?
Exhibit
Refer to the exhibit. ``` $ kubectl describe svc my-service Name: my-service Namespace: default Labels: <none> Annotations: <none> Selector: app=my-app Type: ClusterIP IP Family Policy: SingleStack IP Families: IPv4 IP: 10.96.100.10 IPs: 10.96.100.10 Port: http 80/TCP TargetPort: 8080/TCP Endpoints: <none> ```
Trap 1: The Service type is ClusterIP, which cannot be accessed from within…
ClusterIP is designed for internal access.
Trap 2: The port name 'http' is invalid.
Port names are optional and 'http' is valid.
Trap 3: The targetPort is 8080, but the container port is not 8080.
The exhibit does not show container ports, but if it were wrong, endpoints would still exist but traffic would fail.
- A
The Service type is ClusterIP, which cannot be accessed from within the cluster.
Why wrong: ClusterIP is designed for internal access.
- B
No pods match the selector or the matching pods are not ready.
Endpoints are empty, so no ready pods are available.
- C
The port name 'http' is invalid.
Why wrong: Port names are optional and 'http' is valid.
- D
The targetPort is 8080, but the container port is not 8080.
Why wrong: The exhibit does not show container ports, but if it were wrong, endpoints would still exist but traffic would fail.
Which TWO of the following are valid ways to expose a Kubernetes Service to external traffic?
Trap 1: ClusterIP
ClusterIP is only reachable within the cluster.
Trap 2: ExternalName
ExternalName maps to an external DNS name, not exposing a service.
Trap 3: Headless
Headless services are used for stateful workloads; they don't expose external traffic.
- A
LoadBalancer
LoadBalancer provisions an external load balancer from the cloud provider.
- B
ClusterIP
Why wrong: ClusterIP is only reachable within the cluster.
- C
ExternalName
Why wrong: ExternalName maps to an external DNS name, not exposing a service.
- D
NodePort
NodePort exposes the service on a static port on each node, allowing external traffic.
- E
Headless
Why wrong: Headless services are used for stateful workloads; they don't expose external traffic.
An administrator is tasked with setting up a new Kubernetes cluster using kubeadm. They have two nodes: one control plane and one worker. After initializing the control plane with 'kubeadm init', the worker node fails to join with the error 'error execution phase preflight: [preflight] Some fatal errors occurred: [ERROR CRI]: container runtime is not running'. What should the administrator check first?
Trap 1: Verify that the control plane node is healthy.
The error is on the worker node.
Trap 2: Check if the join token has expired.
Token expiry would give a different error.
Trap 3: Install a network plugin like Calico on the control plane.
Network plugin is not related to CRI error.
- A
Ensure that containerd is installed and running on the worker node.
The CRI error indicates the runtime is not running.
- B
Verify that the control plane node is healthy.
Why wrong: The error is on the worker node.
- C
Check if the join token has expired.
Why wrong: Token expiry would give a different error.
- D
Install a network plugin like Calico on the control plane.
Why wrong: Network plugin is not related to CRI error.
A Node is reporting DiskPressure condition. Which action is most appropriate to resolve this without losing data?
Trap 1: kubectl delete node <node-name>
Deleting the node removes it from cluster; does not fix disk pressure.
Trap 2: kubectl drain <node-name> --ignore-daemonsets
Drain evicts pods but does not free disk space; disk pressure persists.
Trap 3: Restart the kubelet service
Restarting kubelet does not free disk space; pressure will remain.
- A
kubectl delete node <node-name>
Why wrong: Deleting the node removes it from cluster; does not fix disk pressure.
- C
kubectl drain <node-name> --ignore-daemonsets
Why wrong: Drain evicts pods but does not free disk space; disk pressure persists.
- D
Restart the kubelet service
Why wrong: Restarting kubelet does not free disk space; pressure will remain.
Which of the following are valid methods to debug a failing CoreDNS pod? (Select TWO)
Trap 1: kubectl delete pod -n kube-system -l k8s-app=kube-dns
Deleting a pod is a fix, not a debug method.
Trap 2: kubectl scale deployment coredns --replicas=2
Scaling is a fix, not debugging.
Trap 3: kubectl run -it --rm test --image=busybox -- nslookup…
This tests DNS resolution, not debugging CoreDNS pod itself.
- B
kubectl delete pod -n kube-system -l k8s-app=kube-dns
Why wrong: Deleting a pod is a fix, not a debug method.
- D
kubectl scale deployment coredns --replicas=2
Why wrong: Scaling is a fix, not debugging.
- E
kubectl run -it --rm test --image=busybox -- nslookup kubernetes.default
Why wrong: This tests DNS resolution, not debugging CoreDNS pod itself.
A Pod in a Deployment is CrashLoopBackOff. 'kubectl logs' shows the application exits with code 1 after printing one line. The Pod has a liveness probe that checks an HTTP endpoint. What should be checked first?
Trap 1: Check if the liveness probe's initialDelaySeconds is too short.
The application crashes regardless of the probe; the probe is not the cause.
Trap 2: Check if the liveness probe endpoint is correctly configured.
The application exits before the probe would matter.
Trap 3: Check if the container has insufficient memory limits.
Memory issues typically cause OOMKilled, not exit code 1.
- A
Check the application logs and configuration that causes the exit code 1.
The application is crashing due to its own logic; logs should indicate the error.
- B
Check if the liveness probe's initialDelaySeconds is too short.
Why wrong: The application crashes regardless of the probe; the probe is not the cause.
- C
Check if the liveness probe endpoint is correctly configured.
Why wrong: The application exits before the probe would matter.
- D
Check if the container has insufficient memory limits.
Why wrong: Memory issues typically cause OOMKilled, not exit code 1.
During a 'kubeadm init', the administrator sees the message 'Your Kubernetes control-plane has been initialized successfully!' but the 'kubectl get nodes' shows the control plane node as 'NotReady'. What is the most likely missing step?
Trap 1: Generate a join token for worker nodes.
Join tokens are for adding nodes, not making the control plane ready.
Trap 2: Copy the kubeconfig to the user's home directory.
kubeconfig allows kubectl to communicate with the cluster, but does not affect node readiness.
Trap 3: Check that the kubelet is running on the control plane node.
kubelet is running; it would show NotReady if network plugin missing.
- A
Generate a join token for worker nodes.
Why wrong: Join tokens are for adding nodes, not making the control plane ready.
- B
Install a CNI plugin such as Calico or Flannel.
Without a CNI plugin, node condition stays NotReady.
- C
Copy the kubeconfig to the user's home directory.
Why wrong: kubeconfig allows kubectl to communicate with the cluster, but does not affect node readiness.
- D
Check that the kubelet is running on the control plane node.
Why wrong: kubelet is running; it would show NotReady if network plugin missing.
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?
Trap 1: Calico is not configured with an overlay network.
Calico can work without an overlay using BGP; lack of overlay is not the issue.
Trap 2: A NetworkPolicy is blocking inter-node traffic.
The scenario says network policies are not enforced.
Trap 3: The pods are using different Service types.
Service type does not affect pod-to-pod communication.
- A
Calico is not configured with an overlay network.
Why wrong: Calico can work without an overlay using BGP; lack of overlay is not the issue.
- B
A NetworkPolicy is blocking inter-node traffic.
Why wrong: The scenario says network policies are not enforced.
- C
The pods are using different Service types.
Why wrong: Service type does not affect pod-to-pod communication.
- D
The nodes' firewalls are blocking required ports for Calico (e.g., BGP port 179 or VXLAN port 4789).
Calico needs inter-node communication; firewall blocking can prevent pod-to-pod across nodes.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.