CKA Practice Question: Cluster Architecture, Installation & Configuration
Exhibit
``` $ kubectl get csr NAME AGE SIGNERNAME REQUESTOR REQUESTDURATION CONDITION csr-node2 10m kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap <none> Pending $ kubectl describe csr csr-node2 Name: csr-node2 Labels: <none> Annotations: <none> CreationTimestamp: Mon, 01 Jan 2024 12:00:00 +0000 Requesting User: kubelet-bootstrap Signer: kubernetes.io/kube-apiserver-client-kubelet Status: Pending Subject: Common Name: system:node:node2 Organization: system:nodes Groups: system:nodes system:authenticated $ kubectl get nodes NAME STATUS ROLES AGE VERSION master Ready control-plane,master 10d v1.28.0 node1 Ready <none> 10d v1.28.0 node2 NotReady <none> 1m v1.28.0 ```
Refer to the exhibit. A new worker node (node2) has been added to the cluster. It shows NotReady status, and a CertificateSigningRequest (CSR) is pending. What step must the cluster administrator take to make node2 ready?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Approve the pending CSR using 'kubectl certificate approve csr-node2'.
When a new node joins, the kubelet creates a CSR for its client certificate. The CSR must be approved by an administrator (or automatically via a controller). Until approved, the node cannot authenticate and remains NotReady.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Approve the pending CSR using 'kubectl certificate approve csr-node2'.
Why this is correct
The kubelet on node2 generated its own private key and submitted a CertificateSigningRequest (CSR) to the Kubernetes API server during the kubeadm join process. The cluster requires administrative approval before the kube-controller-manager can sign that CSR, which would give the node its client certificate for authenticating against the API server. Running 'kubectl certificate approve csr-node2' explicitly approves the pending request, triggering the signer to issue the certificate. Without this approval, the kubelet cannot complete its TLS bootstrapping and the node remains NotReady.
- ✗
Run 'kubeadm join' again with the correct token.
Why it's wrong here
Running 'kubeadm join' again with a new or correct token is not the right fix because the original join command already executed successfully enough for node2's kubelet to start and generate the pending CSR. The presence of a pending CSR indicates that the bootstrap token phase worked; what is missing is the certificate approval step, not the token. Re-running join would not approve the existing CSR, and it may fail if the node is already partially registered or cause a duplicate join attempt. The correct action is to approve the pending CSR, not to re-initiate the join procedure.
- ✗
Add the node's IP to the API server's TLS certificate.
Why it's wrong here
The API server's TLS certificate is used to prove the API server's identity to clients, and it should contain the DNS names or IP addresses that clients (including kubectl, kubelets, and the API server itself) will use to connect to it. Worker node IPs are not required in the API server certificate because the kubelet on node2 uses its own client certificate—issued from the CSR—to authenticate to the API server. Modifying the API server certificate would not affect whether node2's CSR is approved; that CSR is for node2's client identity, not for the API server's serving identity. This option confuses server-side TLS with client-side TLS and is unnecessary for fixing the pending CSR.
- ✗
Restart the kubelet on node2.
Why it's wrong here
Restarting the kubelet on node2 will cause it to re-read its configuration and re-submit its certificate signing request, but a restart does not and cannot approve the pending CSR—approval is an administrative action performed through the Kubernetes API. The current issue is not that the kubelet is malfunctioning or missing a state; it simply has a CSR stuck in the 'Pending' phase because no approver has signed it. Restarting will just produce a new or renewed request for the same certificate, and the node will remain NotReady until someone runs 'kubectl certificate approve'. This option attempts to solve a permission approval problem with a process-level action, which is ineffective.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKA question from scratch — 726 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.