Certified Kubernetes Administrator (CKA) — All Questions

In a standard Kubernetes control plane, which component is the only one that clients and other components talk to directly to read or change cluster state?

• a.kube-scheduler
• b.kube-apiserver✓
• c.kube-controller-manager
• d.kubelet

The kube-apiserver is the front end of the control plane and the single entry point for all REST operations against cluster state. All other components, including the scheduler and controller manager, communicate through the API server rather than with etcd directly. Only the API server reads and writes etcd.

Where does a Kubernetes cluster persistently store all of its object data, such as Pods, Secrets, and ConfigMaps?

• a.In a MySQL database on each worker node
• b.In the kubelet's local cache
• c.In etcd, a distributed key-value store✓
• d.In the container runtime's image store

etcd is the consistent, distributed key-value store that serves as the backing store for all cluster data. Protecting and regularly backing up etcd is critical because losing it means losing the entire cluster state. The API server is the only component that talks to etcd.

You are performing a maintenance backup of a cluster's state. Which tool and data source should you use to capture the authoritative cluster state?

• a.etcdctl snapshot save against the etcd datastore✓
• b.kubectl cp of the /var/lib/kubelet directory
• c.docker commit of the API server container
• d.tar of each node's /etc/kubernetes/manifests directory

The authoritative record of cluster state lives in etcd, so a proper backup is taken with etcdctl snapshot save (supplying the endpoints and TLS certificates). Copying kubelet directories or static manifests does not capture object state such as Deployments, Secrets, or RBAC bindings stored in etcd.

Which mechanism is the recommended way to grant a user permission to list Pods only within a single namespace?

• a.A ClusterRole bound with a ClusterRoleBinding
• b.Adding the user to the system:masters group
• c.Editing the kube-apiserver static Pod manifest
• d.A Role bound with a RoleBinding in that namespace✓

A Role is namespaced and defines permissions within one namespace; binding it with a RoleBinding grants those permissions to a subject in that namespace only. ClusterRoles and ClusterRoleBindings apply cluster-wide, and system:masters grants full admin access, so neither fits a least-privilege, single-namespace requirement.

A control-plane component is deployed as a static Pod. Which statement about static Pods is correct?

• a.They are scheduled by kube-scheduler like normal Pods
• b.They are managed directly by the kubelet from a manifest directory on the node✓
• c.They can only be created through the Kubernetes Dashboard
• d.They are stored exclusively in etcd and have no local definition

Static Pods are managed directly by the kubelet, which watches a configured manifest directory (commonly /etc/kubernetes/manifests) and runs any Pod defined there. The API server shows a read-only mirror Pod for visibility, but the scheduler is not involved. This is how kubeadm runs core control-plane components.