CKA Timed Hard Questions — 25 Difficult 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

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 3

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.

Question 4

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?

Accepted Answer

Run 'kubeadm reset' to clean up the previous installation and then re-run kubeadm init.. When `kubeadm init` fails on a machine that previously hosted a Kubernetes cluster, it is typically because residual configuration files, certificates, and control plane static pod manifests from the prior installation conflict with the new initialization. Running `kubeadm reset` is the official cleanup command that removes these artifacts (e.g., `/etc/kubernetes/`, CNI configurations, and iptables rules), restoring the node to a pre-init state so that `kubeadm init` can succeed cleanly.

Answer

Manually delete the /etc/kubernetes/manifests/kube-apiserver.yaml file and kill the process using port 6443.

Answer

Use a different port for the API server by specifying --apiserver-bind-port.

Answer

Run kubeadm init with --force flag to override the errors.

Question 5

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?

Accepted Answer

db-service.backend.svc.cluster.local. Option D is correct because Kubernetes DNS resolves services using the format `..svc.cluster.local`. Since the pod is in the 'frontend' namespace and needs to reach 'db-service' in the 'backend' namespace, the fully qualified domain name (FQDN) must include the namespace and the 'svc' subdomain to be resolved by the cluster DNS (CoreDNS).

Answer

db-service.svc.cluster.local

Answer

db-service

Answer

db-service.backend.cluster.local

Question 6

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?

Accepted Answer

Run 'kubeadm certs renew kubelet-client'. The `kubeadm certs renew kubelet-client` command is the correct way to renew only the kubelet client certificate without affecting other certificates. This targeted renewal is appropriate when only the kubelet client certificate is expiring, as it avoids unnecessary disruption to other components. The command regenerates the certificate using the existing CA, and the kubelet will automatically reload it.

Answer

Run 'kubeadm init phase certs kubelet-client'

Answer

Renew all certificates using 'kubeadm certs renew all'

Answer

Delete the old certificate and restart kubelet

Question 7

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?

Accepted Answer

The nodes' firewalls are blocking required ports for Calico (e.g., BGP port 179 or VXLAN port 4789).. Option D is correct because Calico relies on specific ports for inter-node communication. When using BGP (default), port 179 must be open; when using VXLAN overlay, port 4789 is required. If node firewalls block these ports, Calico cannot establish routes or encapsulate traffic between nodes, causing cross-node pod communication to fail while same-node communication (which uses the local bridge) remains unaffected.

Answer

Calico is not configured with an overlay network.

Answer

A NetworkPolicy is blocking inter-node traffic.

Answer

The pods are using different Service types.

Question 8

A team observes that a Deployment's Pods are being scheduled on nodes with different architectures (amd64 and arm64). The Deployment does not specify nodeSelector or affinity. The cluster has a mix of node pools. What is the best practice to ensure Pods only run on amd64 nodes?

Accepted Answer

Add a label 'kubernetes.io/arch: amd64' to all amd64 nodes and use nodeSelector.. Option B is correct because the recommended way to constrain Pods to nodes with a specific architecture is to label those nodes (e.g., with `kubernetes.io/arch: amd64`) and then use `nodeSelector` in the Pod spec. This ensures the scheduler only places Pods on nodes matching the label, which is a simple, declarative, and Kubernetes-native approach. The Deployment does not specify any scheduling constraints, so adding `nodeSelector` is the best practice to enforce architecture-specific placement.

Answer

Add a toleration for 'arch=amd64:NoSchedule' to the Pod.

Answer

Use podAntiAffinity to avoid scheduling on arm64 nodes.

Answer

Set a runtimeClassName for amd64 in the Pod spec.

Question 9

Which THREE of the following are true about Network Policies in Kubernetes?

Accepted Answer

They are namespaced resources.. Network Policies are namespaced resources in Kubernetes, meaning they are defined within a specific namespace and only apply to pods in that namespace. This is confirmed by the Kubernetes API, where NetworkPolicy is a namespaced resource under the networking.k8s.io/v1 API group, and it cannot be applied cluster-wide without additional tooling like a cluster-scoped policy engine.

Answer

They can block traffic at the node level.

Answer

They can modify packet contents.

Question 10

After applying this NetworkPolicy, a pod in the default namespace tries to curl an external website (e.g., google.com) and fails. What is the reason?

Accepted Answer

The Egress rule is defined but has no allow rules, so all egress is denied.. Option A is correct because the NetworkPolicy defines an Egress rule with an empty `rules` array, which means no egress traffic is explicitly allowed. In Kubernetes, when a NetworkPolicy selects a pod, it defaults to denying all traffic of the specified direction unless explicitly allowed. Since the Egress rule has no allow rules, all outbound traffic from the selected pods, including HTTP/HTTPS requests to external websites like google.com, is blocked by the policy.

Answer

The Ingress rule blocks all incoming traffic, preventing DNS responses.

Answer

The policy is applied to all namespaces, causing a conflict.

Answer

The policy only applies to pods with specific labels.

Question 11

A cluster administrator notices that nodes are not joining the cluster after a kubeadm init. The kubelet logs show: 'failed to run Kubelet: could not init service: open /var/lib/kubelet/config.yaml: permission denied'. What is the most likely cause?

Accepted Answer

The kubelet configuration file has incorrect ownership or permissions.. The error message 'open /var/lib/kubelet/config.yaml: permission denied' indicates that the kubelet process does not have the necessary read permissions to access its configuration file. This is typically caused by incorrect file ownership (e.g., owned by root instead of the kubelet user) or restrictive file permissions (e.g., 600 instead of 644). Since kubelet runs as a systemd service, it requires appropriate access to this file to initialize properly.

Answer

The kubelet is running out of disk space.

Answer

The kubelet is not able to reach the API server.

Answer

The kubelet binary is missing.

Question 12

Which THREE of the following are valid steps to enable audit logging in a Kubernetes cluster?

Accepted Answer

Create an audit policy file defining what events to log.. Option B is correct because audit logging in Kubernetes requires an audit policy file that defines which events (e.g., RequestResponse, Metadata) should be logged. This policy file must be created and then passed to the kube-apiserver via the --audit-policy-file flag. Without a policy file, the apiserver will not know what to log, even if other flags are set.

Answer

Store the audit policy in a ConfigMap and reference it via --audit-policy-configmap.

Answer

Restart the kubelet on the control plane node.

Question 13

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.. Option B is correct because 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 14

A Kubernetes cluster has been running for months. Recently, some pods are reporting 'FailedScheduling' due to insufficient memory. The administrator wants to add a new node with 32GB RAM. However, after joining the node, the new node shows 'NotReady' and the kubelet logs indicate 'Failed to update node status: context deadline exceeded'. What is the most likely cause?

Accepted Answer

There is a network connectivity issue between the new node and the control plane.. The 'context deadline exceeded' error in the kubelet logs indicates that the kubelet on the new node is unable to communicate with the API server within the expected timeout. This is typically caused by network connectivity issues between the node and the control plane, such as firewall rules, incorrect DNS resolution, or a broken CNI plugin. Without successful node-to-API-server communication, the kubelet cannot post its status, leaving the node in 'NotReady' state.

Answer

The kubelet is not configured with the correct node IP.

Answer

The new node does not have enough disk space for container images.

Answer

The API server is overloaded and cannot handle the node update request.

Question 15

A DevOps engineer notices that the kubelet on a node is unable to register with the Kubernetes API server. The kubelet logs show 'Failed to get bootstrap CA certificate' and the node is not yet part of the cluster. What is the most likely cause?

Accepted Answer

The bootstrap token used for TLS bootstrapping has expired.. The bootstrap token used for TLS bootstrapping has expired. During the TLS bootstrap process, the kubelet uses a limited-time bootstrap token to authenticate with the API server and request a client certificate. If the token expires before the kubelet completes registration, the kubelet will fail to obtain the bootstrap CA certificate and cannot join the cluster, as indicated by the error 'Failed to get bootstrap CA certificate'.

Answer

The kubelet configuration file has incorrect node IP.

Answer

The node's RBAC permissions are misconfigured.

Answer

The API server is not running.

Question 16

A pod with priorityClassName: high is pending. You describe the pod and see the event: '0/3 nodes are available: 3 node(s) didn't match pod affinity/anti-affinity, 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' The pod has required anti-affinity to avoid co-location with pods from the same app. How can you get the pod scheduled?

Accepted Answer

Change the anti-affinity rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution.. The pod is pending because its required anti-affinity rule cannot be satisfied on any node: all 3 nodes either have a control-plane taint (which the pod doesn't tolerate) or already host pods from the same app, violating the anti-affinity. Changing the rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution makes the anti-affinity a soft constraint, allowing the scheduler to place the pod on a node even if it means co-locating with same-app pods, thus resolving the scheduling conflict.

Answer

Add a toleration for the control-plane taint.

Answer

Increase the number of replicas of the app to spread the pods.

Answer

Delete the existing pods of the same app to free up nodes.

Question 17

Which THREE of the following are valid taint effects that can be applied to a node? (Select 3)

Accepted Answer

NoSchedule. Taint effects in Kubernetes control pod scheduling onto nodes. `NoSchedule` (C) prevents pods that do not tolerate the taint from being scheduled on the node, making it a valid taint effect.

Answer

NeverSchedule

Answer

PreferSchedule

Question 18

Which THREE of the following are valid considerations when using resource requests and limits? (Select 3)

Accepted Answer

Requests are used by the scheduler to decide which node can accommodate the Pod.. Option B is correct because the Kubernetes scheduler uses resource requests (CPU and memory) to determine node suitability for a Pod. The scheduler checks if the sum of requests for all Pods on a node, plus the new Pod's requests, is less than or equal to the node's allocatable capacity. Limits are not used for scheduling decisions.

Answer

Limits must be equal to requests for a Pod to be scheduled.

Answer

CPU limits guarantee the Pod will get that amount of CPU.

Question 19

A cluster administrator wants to ensure that a set of batch processing Pods are preemptible and should not cause disruption to other critical workloads. Which combination of scheduling features should be used?

Accepted Answer

Assign a low priority class to the batch Pods and set a PodDisruptionBudget for critical workloads.. Option B is correct because assigning a low priority class to batch Pods ensures they are preempted by higher-priority critical workloads when resources are scarce, while a PodDisruptionBudget (PDB) for critical workloads guarantees that a minimum number of those Pods remain available during voluntary disruptions (e.g., node drains). This combination allows batch Pods to be preemptible without causing disruption to critical workloads, aligning with the requirement.

Answer

Taint all worker nodes with a custom taint and add tolerations to batch Pods.

Answer

Use nodeAffinity to schedule batch Pods on dedicated nodes.

Answer

Use resource quotas to limit the batch Pods' resource consumption.

Question 20

A Kubernetes cluster has a node pool with GPU nodes labeled 'accelerator=nvidia-tesla'. A Pod requires a GPU. Which configuration is necessary?

Accepted Answer

Set nodeSelector to 'accelerator=nvidia-tesla' and request 'nvidia.com/gpu' in resources.. Option C is correct because a Pod that requires a GPU must both be scheduled onto a node with the appropriate GPU label and explicitly request the GPU resource. The `nodeSelector` ensures the Pod lands on a node labeled `accelerator=nvidia-tesla`, and requesting `nvidia.com/gpu` in `resources.requests` or `resources.limits` (typically limits) tells the kubelet to allocate a GPU device to the container. Without the resource request, the scheduler has no way to account for GPU capacity, and without the nodeSelector, the Pod might be scheduled on a non-GPU node.

Answer

Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution for the GPU label.

Answer

Set resources.limits for 'nvidia.com/gpu' only.

Answer

Add a toleration for GPU node taints.