CKA Practice Exam.
Free practice test — 35 verified questions, instant feedback.

Answer: A
kubeadm join uses a bootstrap token plus a CA certificate hash (discovery-token-ca-cert-hash) so the joining node can verify the API server and the API server can verify the joining node's TLS bootstrap request, after which the kubelet is issued a proper client certificate. SSH keys have nothing to do with Kubernetes API trust, basic-auth Secrets are not part of standard kubeadm bootstrap trust, and DNS records only route traffic, they do not establish cryptographic trust.

Answer: B
Kubernetes version skew policy requires kubelet to be no newer than kube-apiserver, and within the supported number of minor versions older, to guarantee API compatibility. Kubelets newer than the API server are unsupported, kube-proxy does not follow a fixed two-version offset rule, and etcd upgrades are governed by their own compatibility matrix independent of kubelet upgrade order.

Answer: B
etcd is the single source of truth for all cluster state (objects, secrets, configuration), so a consistent etcdctl snapshot save is what allows full cluster restoration. Worker node kubelet directories hold only local pod state, not cluster-wide objects; the apiserver image contains no cluster data; and a kubeconfig only holds client credentials and endpoint info, not cluster state.

Answer: B
Taints repel pods unless the pod spec declares a matching toleration (same key, matching operator/value, and effect such as NoSchedule); tolerations permit scheduling but do not force it. A nodeSelector only targets nodes by label and does nothing to overcome a taint, resource limits are unrelated to taint logic, and pods do not use ownerReferences to nodes for scheduling.

Answer: B
A namespaced Role paired with a RoleBinding is the correct RBAC primitive to grant permissions confined to a single namespace. A ClusterRole with a ClusterRoleBinding would grant the permission cluster-wide across all namespaces, PodSecurityPolicy (deprecated and unrelated to RBAC) governs pod security context rather than API verbs, and NetworkPolicy controls network traffic, not API authorization.

Answer: B
Mutating admission webhooks intercept object creation requests and can inject or modify fields such as tolerations and init containers before persistence, which is exactly the described use case. LimitRange only constrains resource requests/limits, ResourceQuota caps aggregate resource consumption, and a default StorageClass only affects unspecified PVC storage class selection — none of these mutate arbitrary pod fields.

Answer: B
Because kube-apiserver runs as a static pod, editing its manifest file in /etc/kubernetes/manifests triggers the local kubelet to detect the change and restart the pod with new flags — this is the supported way to change control plane component configuration in a kubeadm cluster. Changing --client-ca-file swaps the trusted CA rather than certificate validity duration, kube-apiserver is not a Deployment so 'kubectl edit deployment' would fail, and restarting worker kubelets has no effect on the control plane's static pod.

Answer: B
maxUnavailable and maxSurge bound how many pods can be down and how many extra can be created simultaneously during a rolling update, which is what enables zero-downtime updates for adequately replicated workloads. Simultaneous termination of all pods describes a Recreate strategy, not RollingUpdate; there is no built-in manual-approval pause without an external gate; and rolling updates do not depend on a separate Job resource for pod replacement.

Answer: B
CrashLoopBackOff is the kubelet's exponential backoff behavior for a container that repeatedly exits, increasing wait time between restarts up to a cap to avoid hammering the node. A liveness probe failure can trigger a restart but 'liveness probe failure escalation' is not the name of the backoff mechanism itself, node-pressure eviction removes pods rather than restarting containers in place, and preemption is about the scheduler removing lower-priority pods to fit a new one, unrelated to container crash restarts.

Answer: B
A DaemonSet ensures exactly one pod copy runs on each (matching) node and automatically extends to newly added nodes, which is exactly the stated requirement. A Deployment with a fixed replica count does not track node count changes and provides no per-node guarantee, StatefulSet is designed for stable identity and storage for stateful apps rather than per-node placement, and a Job runs pods to completion rather than as continuously running per-node daemons.

Answer: B
ConfigMaps externalize non-sensitive configuration from the image and can be referenced by Pods via env vars or volume mounts, letting the same image be reused across environments by swapping the ConfigMap. Hardcoding in the image defeats the goal of environment independence and requires rebuilds, Secrets are meant for sensitive data (base64 is encoding, not the defining reason to use a Secret) so using one for a non-sensitive hostname is not best practice, and kubectl apply flags don't persist as part of a Pod's declarative config.

Answer: B
CPU requests inform scheduling placement (finding a node with enough allocatable capacity) while CPU limits are enforced via CFS throttling rather than termination, since CPU is a compressible resource. There is no requirement to use at least the request amount, OOMKill applies to memory limit violations (an incompressible resource) not CPU, and CPU requests/limits are fully valid and commonly used fields, not memory-only.

Answer: B
With completions and parallelism both set, the Job controller keeps at most 'parallelism' pods running concurrently while working toward the total 'completions' successful pod completions, replacing failed pods as needed. Running all 5 concurrently would ignore the parallelism cap, treating the Job as complete after only 2 successes would ignore the completions field, and parallelism is not ignored — it directly bounds concurrency.

Answer: A
ClusterIP is the default Service type providing a stable internal virtual IP and DNS name that load-balances across matching Pods, visible only within the cluster. NodePort additionally exposes a port on every node (external reachability), LoadBalancer provisions an external cloud load balancer, and ExternalName simply creates a DNS CNAME to an external name with no proxying or selector-based backend at all.

Answer: B
Kubernetes populates each Pod's /etc/resolv.conf with search domains (namespace.svc.cluster.local, svc.cluster.local, cluster.local) so short names are expanded and resolved via CoreDNS, the cluster's DNS provider. kube-proxy handles Service IP load-balancing via iptables/IPVS rules, not DNS or hosts files; container images don't ship cluster DNS zone data; and NetworkPolicy only controls allowed traffic, it has no role in name resolution.

Answer: B
Kubernetes' default networking model is flat and permissive: without any NetworkPolicy resources selecting a Pod, all ingress and egress traffic is allowed, and policies exist to progressively restrict this. The 'deny by default' behavior only appears once a NetworkPolicy selects a Pod for a given direction; there's no default same-Deployment or same-service-account isolation built into core networking.

Answer: A
Once any NetworkPolicy selects a Pod for the ingress direction, that direction becomes default-deny except for what the rules explicitly allow — here, only app=frontend on port 8080. Egress is a separate direction and is unaffected unless the policy also includes egress rules; policies apply independently per Pod selector, so a matching egress policy on the frontend side is not required for this ingress rule to take effect; and NetworkPolicies are inherently restrictive/allow-list based once applied, not purely additive to an already-open default.

Answer: B
NodePort opens the same port on every node; kube-proxy's rules (iptables/IPVS) forward incoming connections to any healthy matching Pod cluster-wide, regardless of which node it lives on. kube-scheduler is only involved in placing Pods, not in the data path of live traffic; NodePort does not require the traffic's destination Pod to reside on the contacted node; and NodePort works independently of any Ingress controller — Ingress is a separate, optional layer for HTTP(S) routing.

Answer: A
The Ingress resource is only a routing specification; an Ingress controller (e.g., an nginx or cloud-provider controller) must be running and configured to watch and act on Ingress objects, or no traffic is ever routed. Ingress and Service are distinct resource types serving different purposes, so 'recreating as a NodePort' misunderstands the model; TLS is optional on Ingress and unrelated to whether routing occurs; and DNS records pointing to the ingress load balancer typically must be configured separately (or via external-dns), they are not automatically created by the Ingress API itself.

Answer: A
The binding process matches PVCs to PVs based on storage class, sufficient capacity, compatible access modes, and any selector/label constraints; the control loop picks the smallest suitable PV meeting these criteria. Creation order alone doesn't govern binding when multiple criteria must match; PersistentVolumes are cluster-scoped (not namespaced) so 'same namespace as the PV' is a category error; and statically provisioned PVs can bind with an empty or matching storageClassName without any provisioner being involved, since no dynamic provisioning happens in that path.

Answer: A
With reclaimPolicy Delete, removing the PVC triggers deletion of both the PV object and its backing storage resource (e.g., the cloud disk), which is the default for most dynamically provisioned classes. 'Retain' is the policy that preserves the PV (and requires manual cleanup) after PVC deletion, not 'Delete'; the 'Recycle' reclaim policy is deprecated/removed in current Kubernetes and was never the default; and claiming PVC deletion never affects the PV contradicts the entire purpose of reclaim policies.

Answer: B
ReadWriteOnce restricts the volume to being mounted read-write by a single node at a time (and, depending on CSI driver/Kubernetes version nuances, effectively one Pod's node), so a second Pod scheduled to a different node will fail to attach/mount it. RWO is not a read-only-for-others mode; Kubernetes never silently upgrades a volume's access mode to RWX; and there is no mechanism that lets writes be silently discarded as a 'feature' of access mode conflicts — the mount attempt fails instead.

Answer: B
emptyDir is created when a Pod is assigned to a node, is shared across all containers in that Pod, and is deleted permanently when the Pod is removed, matching exactly the described transient shared-storage need with no external backend. A PVC implies persistence beyond the Pod's lifetime and requires a storage backend, hostPath ties data to a specific node's filesystem which breaks if the Pod reschedules and isn't meant for inter-container sharing per se, and a ConfigMap volume is for injecting configuration data, not for writable shared scratch space.

Answer: B
kubectl describe pod surfaces the Events section, which records scheduler messages such as insufficient resources or unmatched node affinity/taints — the direct reason a Pod remains Pending. kubectl logs only returns container stdout/stderr, which doesn't exist yet for a Pod that hasn't been scheduled and started; kubectl get nodes shows node status but not why this specific Pod was rejected; and kubectl top requires the metrics server and pod to be running, neither of which applies to a Pending pod.

Answer: A
A liveness probe failure with an HTTP 500 means the kubelet successfully connected to the container's probe endpoint but the application returned a server error, causing the kubelet to consider the container unhealthy and restart it. This is unrelated to node reachability (that would show as NotReady node status, a different signal), unrelated to image pull errors (which would show as ImagePullBackOff/ErrImagePull events instead), and a NetworkPolicy blocking traffic would typically manifest as a connection timeout/refused rather than a completed HTTP request returning status 500.

Answer: B
NotReady typically indicates the kubelet on that node has stopped reporting status (crashed, lost API connectivity, or a failed health check), so checking the kubelet's live service status and logs directly identifies the cause. Deleting the node object doesn't fix the underlying host issue and can cause unnecessary pod rescheduling churn; scaling an unrelated Deployment doesn't address node health; and manually tainting the node NoExecute before diagnosis needlessly evicts workloads that might otherwise still be running fine.

Answer: B
An 'unauthorized' error while pulling an image means the node lacks valid credentials for the private registry, so the fix is to supply correct imagePullSecrets on the Pod or its service account. Memory limits are unrelated to registry authentication, tolerations address scheduling onto tainted nodes rather than image pull auth, and changing restartPolicy affects what happens after container exit, not the ability to pull the image in the first place.

Answer: B
Since IP-based connectivity works but name resolution doesn't, the fault is isolated to DNS: check that CoreDNS Pods are running and healthy, and confirm the Pod's resolv.conf has correct nameserver and search entries. kube-scheduler is unrelated to runtime networking or DNS; etcd disk latency would affect API server responsiveness broadly, not selectively break DNS while ClusterIP routing works; and CPU limits on the application container wouldn't selectively break only name resolution while raw IP connectivity succeeds.

Answer: A
kubectl rollout undo reverts a Deployment to its prior ReplicaSet revision using the retained rollout history, restoring known-good Pods quickly without hand-authoring new manifests. Deleting the Deployment loses its rollout history and management, and manually created Pods via kubectl run lose Deployment-level self-healing and rollout tracking; scaling to zero removes service entirely rather than restoring it; and repointing a Service's selector to a nonexistent ReplicaSet provides no functioning backend at all.

Answer: B
A stuck PVC is a storage/provisioning-layer problem: for static provisioning, verify a compatible PV exists; for dynamic provisioning, verify the StorageClass's provisioner and the underlying CSI driver are healthy, and read 'kubectl describe pvc' Events for explicit error messages. The Pod's image tag is unrelated to volume binding, which happens independently of Pod scheduling; PVCs are cluster-scoped-claim objects tied to namespaces, not to any particular node's kubelet; and scheduler leader election is unrelated to storage provisioning entirely.

Answer: B
kubectl drain uses the Eviction API, which respects PodDisruptionBudgets: an eviction is refused if it would violate minAvailable, forcing the drain to wait or retry until it's safe. PDBs are enforced specifically through the Eviction API (which drain uses), not bypassed for it; as long as other replicas remain available elsewhere satisfying minAvailable, the eviction can proceed rather than blocking forever; and PDBs apply to any pod-controller-managed workload matching their selector, including Deployments, not just StatefulSets.

Answer: B
'Preferred' (soft) node affinity expresses a scheduling preference that the scheduler tries to honor via weighted scoring but does not require, allowing the Pod to still land elsewhere if no matching node exists. A plain nodeSelector is a hard requirement — the Pod stays Pending if no matching node exists; tainting non-SSD nodes would need pods to carry a toleration and still doesn't express a 'nice-to-have' preference model as flexibly; and ResourceQuota governs aggregate resource consumption per namespace, not node placement.

Answer: A
StatefulSets assign stable ordinal-based names (e.g., db-0, db-1, db-2) and, combined with a headless Service, stable per-Pod DNS records that persist across restarts/rescheduling — unlike Deployment Pods, which get random hash-suffixed names with no such per-Pod DNS guarantee. Pods never share a single IP; each Pod retains its own IP address; StatefulSet Pods are in fact addressable individually via DNS (that's the point of the headless Service), so 'cannot be addressed via DNS' is false; and the naming convention is deliberately different from and more predictable than Deployment Pod naming, not identical.

Answer: B
Init containers run one at a time, in order, to successful completion before any app container in the Pod starts; a failing init container causes the Pod to retry that init container per the restartPolicy, blocking the main container's start until it succeeds (or the Pod is deemed failed for policies that don't retry). They do not run concurrently with the main container — that would defeat their purpose of guaranteeing pre-conditions; failures are not silently ignored; and init containers can share volumes with app containers (a common pattern for pre-populating a shared volume), so 'no shared filesystem' is incorrect.

Answer: A
The Kubernetes networking model mandates that Pods can reach each other directly by IP across the whole cluster without NAT, and CNI plugins implement this by giving every Pod a unique, routable IP from the cluster's Pod CIDR. NodePort is for external-to-cluster access, not Pod-to-Pod communication; the flat, no-NAT model is explicitly designed to allow cross-node Pod communication (not just same-node); and Pods use their own network namespace by default (isolated from the host's), which is precisely what the CNI plugin's IP assignment supports rather than contradicts.