KCNA - Kubernetes Fundamentals (44% of the exam) - Section 1.6
Describe how kubectl and kubeconfig are used to interact with a cluster.
Contexts and clusters in kubeconfig, the common verbs (get, describe, apply, delete, logs), and how kubectl authenticates to the API server. KCNA tests understanding of what a command does, not command recall under time pressure.
A newcomer runs a command to list the Pods in a cluster and wants to understand what the kubectl tool fundamentally does when it executes that command. Which statement best describes how kubectl interacts with a Kubernetes cluster?
AIt sends HTTP requests to the cluster's API server, the front end of the control plane, and displays the returned response.check_circle Correct
BIt connects directly to the container runtime on each node and queries running containers without involving the control plane.
CIt reads the etcd key-value store directly to fetch cluster state, bypassing every intermediate control-plane component.
DIt carries out scheduling decisions locally and writes desired state onto worker nodes over SSH connections instead.
Understand that kubectl is an API client that communicates with a cluster through the Kubernetes API server. kubectl builds and sends REST calls to the API server over HTTPS; the API server is the single front end that validates requests and persists state to etcd, so every kubectl action is mediated by that server rather than by nodes, etcd, or SSH.
Why A is correct: Correct: kubectl is a client that issues requests to the Kubernetes API server, which authenticates them, reads or writes state, and returns the result that kubectl formats for the user.
Why B is wrong: Tempting because the output does describe containers, but kubectl never talks to node runtimes directly; it goes through the API server, which is the only supported entry point for cluster operations.
Why C is wrong: Tempting because etcd does hold cluster state, but only the API server is permitted to read and write etcd; clients such as kubectl never access etcd directly.
Why D is wrong: Tempting because kubectl manages workloads, but scheduling is done by the scheduler inside the control plane and kubectl uses the API, not SSH, to reach the cluster.
Answers that look right on this material and are not. Each one is a distractor from a different question in the KCNA bank for this domain.
It logs in to each node over SSH and edits the node's local files directly using the node's root key.
errorWhy it is wrong: Tempting because changes do reach the nodes eventually, but kubectl never touches nodes directly; it talks only to the API server, which drives the rest.
kubectl config set-cluster production, which records the API server address for that cluster
errorWhy it is wrong: Tempting because it names the production cluster and edits kubeconfig, but set-cluster only defines or updates a cluster's connection details; it does not change which context kubectl uses by default.
The server URL inside the cluster entry
errorWhy it is wrong: Tempting because it names a cluster, but the server URL only tells kubectl where a given cluster's API server lives; it does not select which cluster is active by default.