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.

You need to ensure exactly one copy of a logging agent Pod runs on every node, including new nodes as they join. Which workload resource fits best?

• a.Deployment
• b.StatefulSet
• c.DaemonSet✓
• d.Job

A DaemonSet ensures a copy of a Pod runs on all (or selected) nodes and automatically adds the Pod to new nodes as they join. Deployments and StatefulSets manage a fixed or scaled replica count rather than one-per-node, and Jobs run to completion. DaemonSets are the standard choice for node-level agents such as log collectors.

A node has a taint of key=value:NoSchedule. What must a Pod have to be scheduled onto that node?

• a.A matching toleration for that taint✓
• b.A nodeSelector that names the node
• c.A higher priorityClassName
• d.An init container that removes the taint

Taints repel Pods unless the Pod carries a matching toleration. NodeSelectors and affinity express a Pod's preference for nodes but do not overcome a NoSchedule taint. Priority affects preemption ordering, not taint tolerance, and containers cannot remove node taints.

You want to perform a controlled rolling update of a Deployment and be able to undo it if the new version misbehaves. Which command reverts to the previous revision?

• a.kubectl delete deployment then recreate it
• b.kubectl scale deployment --replicas=0
• c.kubectl edit deployment and change the name
• d.kubectl rollout undo deployment/<name>✓

kubectl rollout undo reverts a Deployment to its previous revision using the revision history Kubernetes maintains. Scaling to zero only stops Pods, and deleting and recreating loses the managed rollout state. Rollout status and history commands complement undo for safe releases.

A container specifies a CPU request of 250m and a CPU limit of 500m. What does the request value primarily influence?

• a.The maximum CPU the container can ever burst to
• b.How the scheduler decides which node has enough capacity for the Pod✓
• c.The container's restart policy on CPU pressure
• d.Whether the container image is pulled with high priority

The request is what the scheduler uses to find a node with enough allocatable CPU, and it guarantees that minimum share under contention. The limit (500m) caps how much CPU the container may use. Requests do not affect image pulls or restart policy directly.

Which Service type exposes an application on a static port on every node's IP so external traffic can reach it without a cloud load balancer?

• a.ClusterIP
• b.ExternalName
• c.NodePort✓
• d.Headless

A NodePort Service opens the same port on every node and forwards traffic to the Service's Pods, making the app reachable via <NodeIP>:<NodePort>. ClusterIP is internal-only, ExternalName maps to a DNS name, and a headless Service returns Pod IPs directly with no proxying.

In-cluster DNS lets Pods resolve a Service by name. What is the fully qualified DNS name for a Service named db in the namespace prod using the default cluster domain?

• a.db.prod.svc.cluster.local✓
• b.prod.db.cluster.local.svc
• c.db.cluster.local.prod.svc
• d.svc.db.prod.cluster.local

Kubernetes Service DNS follows the pattern <service>.<namespace>.svc.<cluster-domain>, so db in prod resolves to db.prod.svc.cluster.local. Pods in the same namespace can use the short name db. Understanding this pattern is essential for troubleshooting cross-namespace connectivity.

By default, how do Pods in a Kubernetes cluster communicate with each other across nodes before any NetworkPolicy is applied?

• a.All cross-node Pod traffic is blocked until a Service is created
• b.Every Pod can reach every other Pod directly, because the network model is flat and non-isolated by default✓
• c.Pods can only talk to Pods on the same node
• d.Traffic must be routed through the API server

Kubernetes assumes a flat network where every Pod can reach every other Pod across nodes without NAT, and all Pods are non-isolated until a NetworkPolicy selects them. NetworkPolicies (enforced by a supporting CNI plugin) are what restrict traffic. The API server is not in the data path for Pod-to-Pod traffic.

You want to route external HTTP traffic to different Services based on the URL path (for example /api and /web). Which resource is designed for this Layer 7 routing?

• a.A NodePort Service
• b.A NetworkPolicy
• c.A headless Service
• d.An Ingress with an Ingress controller✓

An Ingress defines HTTP and HTTPS routing rules, including host- and path-based routing, and is realized by an Ingress controller running in the cluster. NodePort Services expose a single port with no path awareness, NetworkPolicies control access rather than routing, and headless Services do not proxy traffic.

A NetworkPolicy is applied that selects a set of Pods and defines only an ingress rule allowing traffic from one label-selected source. What is the effect on other incoming traffic to those Pods?

• a.All other ingress traffic to the selected Pods is denied✓
• b.All ingress traffic is still allowed because policies are additive only
• c.Egress traffic from the Pods is also blocked
• d.The policy has no effect until a matching egress policy exists

Once a NetworkPolicy with an ingress section selects a Pod, that Pod becomes isolated for ingress and only the explicitly allowed sources can reach it; everything else is denied. Defining ingress rules does not restrict egress. This default-deny-once-selected behavior is a common exam point.

A Pod needs durable storage that survives Pod restarts and rescheduling. Which pair of objects does a Pod use to consume such storage?

• a.A ConfigMap referenced by a Secret
• b.A PersistentVolumeClaim that binds to a PersistentVolume✓
• c.An emptyDir volume mounted from the node
• d.A hostPath referenced by a DaemonSet

A Pod requests durable storage through a PersistentVolumeClaim (PVC), which binds to a PersistentVolume (PV) that represents the actual storage. emptyDir is ephemeral and tied to the Pod's lifetime, and hostPath ties data to a specific node. The PVC/PV abstraction decouples Pods from storage details.

What does a StorageClass primarily enable in a Kubernetes cluster?

• a.Encryption of etcd at rest
• b.Automatic garbage collection of unused images
• c.Dynamic provisioning of PersistentVolumes on demand✓
• d.Scheduling Pods based on disk speed labels

A StorageClass defines a provisioner and parameters that allow PersistentVolumes to be created automatically when a PersistentVolumeClaim requests that class, rather than an admin pre-creating each PV. This dynamic provisioning is the standard way to supply storage in most clusters.

A PersistentVolume has a reclaim policy of Retain. What happens to the underlying storage when its bound PersistentVolumeClaim is deleted?

• a.The PV and its data are kept and must be reclaimed manually by an administrator✓
• b.The PV and its data are immediately deleted
• c.The PV is automatically rebound to the next PVC that appears
• d.The Pod using it is prevented from terminating

With the Retain reclaim policy, deleting the PVC leaves the PV and its data intact in a Released state; an administrator must manually clean up or reuse it. Delete would remove the underlying storage, and Recycle (deprecated) scrubbed and reused it. Retain protects important data from accidental loss.

A Pod is stuck in the Pending state and never starts. Which command gives the most direct clue about why the scheduler cannot place it?

• a.kubectl logs <pod>
• b.kubectl exec -it <pod> -- sh
• c.kubectl top pod <pod>
• d.kubectl describe pod <pod>✓

kubectl describe pod shows the Events section, which typically reports scheduling failures such as insufficient CPU or memory, unsatisfied node selectors, or untolerated taints. Logs and exec require a running container, and top requires metrics and a scheduled Pod, so they cannot explain a Pending state.

A container repeatedly restarts with status CrashLoopBackOff. Which action most directly reveals why the previous container instance failed?

• a.kubectl get pods -o wide
• b.kubectl logs <pod> --previous✓
• c.kubectl scale the Deployment up
• d.kubectl cordon the node

CrashLoopBackOff means the container starts and exits repeatedly. kubectl logs --previous shows the logs from the last terminated instance, which usually contains the error that caused the crash. Scaling or cordoning does not surface the application-level failure reason.

kubectl commands begin failing with connection-refused errors to the API server on a kubeadm cluster. Which node-level check is most relevant first?

• a.Check the kubelet status and the API server static Pod and its container logs on the control-plane node✓
• b.Delete all worker nodes and re-add them
• c.Rotate every Secret in the cluster
• d.Increase the replica count of every Deployment

On a kubeadm control-plane node, the API server runs as a static Pod managed by the kubelet, so checking kubelet status (systemctl status kubelet) and the API server container logs (via crictl) is the correct first step. The other actions are disruptive and unrelated to why the API server is unreachable.

A worker node shows status NotReady. Which component running on that node is most directly responsible for reporting node health to the control plane?

• a.kube-proxy
• b.kube-scheduler
• c.kubelet✓
• d.etcd

The kubelet on each node registers the node and continually reports its status to the API server; a NotReady node usually means the kubelet is down or cannot reach the API server. kube-proxy handles Service networking, the scheduler runs on the control plane, and etcd is the datastore, not a node health reporter.

Before draining a node for maintenance so that Pods are safely rescheduled elsewhere, which command marks the node unschedulable and evicts its Pods respecting disruption budgets?

• a.kubectl taint node <node> maintenance=true:NoExecute
• b.kubectl drain <node> --ignore-daemonsets✓
• c.kubectl delete node <node>
• d.kubectl label node <node> unschedulable=true

kubectl drain cordons the node (marking it unschedulable) and gracefully evicts its Pods, honoring PodDisruptionBudgets, with --ignore-daemonsets to skip DaemonSet-managed Pods that cannot be evicted. Deleting the node removes it abruptly, and a plain label does not trigger eviction.