Certified Kubernetes Administrator CKA (CKA) — Questions 826–900

The 'NotReady' status indicates that the kubelet on the control plane node is running but cannot report readiness because the node's network is not configured. A CNI plugin (e.g., Calico, Flannel, Weave) must be installed to set up the pod network, which is required for the kubelet to register the node as 'Ready'. Without a CNI plugin, the node's network conditions remain unmet, and the control plane cannot function properly.

Option A is correct because `kubeadm token create --print-join-command` generates a new bootstrap token and immediately outputs the full `kubeadm join` command, including the token, control-plane endpoint, and discovery token CA cert hash. This is the recommended way to obtain a ready-to-use join command after initializing the cluster with `kubeadm init`.

Option D is correct because `kubectl config current-context` is the dedicated kubectl command that displays the name of the currently active context from the kubeconfig file. The active context determines which cluster, user, and namespace are used by default for kubectl commands, making this the precise way to identify the active context.

A policy with an empty podSelector that allows no ingress. Options with rules allow some traffic. Correct ways are those with no ingress rules.

kubectl logs --previous shows logs from the previous container instance.

Ingress has rules (host, paths, backend) and optionally TLS configuration. IngressClass defines which controller serves the Ingress. Service and Endpoints are separate resources.

Option D is correct because etcd v3 is the default and supported version in Kubernetes v1.29, and the `ETCDCTL_API=3` environment variable ensures the etcdctl client uses the v3 API, which provides the `snapshot save` command for creating consistent backups. The command `ETCDCTL_API=3 etcdctl snapshot save /backup/snapshot.db` correctly captures a point-in-time snapshot of the etcd data store, which is essential for disaster recovery.

Calico uses BGP to announce pod IP routes to the network, enabling direct routing between pods across nodes without overlays.

Option B is correct because `kubeadm certs check-expiration` is the dedicated kubeadm command to display expiration dates for all certificates managed by kubeadm in the cluster. This command reads the certificate files from the default kubeadm certificate directory (typically `/etc/kubernetes/pki`) and parses their `NotAfter` field to show remaining validity.

kubectl top pod shows CPU and memory metrics for pods.

Option B is correct because Kubernetes supports encrypting secrets and other resources at rest via an EncryptionConfiguration object, which is passed to the kube-apiserver using the --encryption-provider-config flag. This mechanism encrypts data before it is written to etcd, ensuring that even if the etcd storage is compromised, the data remains unreadable without the encryption key.

volumeClaimTemplates generate unique PVCs for each replica (A). The PVs are retained when scaling down (B). StatefulSet uses ordinal naming, and PVC names include the pod name (C). volumeClaimTemplates does not create a single shared PVC (D), and the reclaim policy is specified in the StorageClass or PV, not in the StatefulSet (E).

Headless Services are used for stateful applications like databases where each pod needs a unique network identity, often used with StatefulSets.

The kubelet service is stopped. The first step is to start it with 'systemctl start kubelet'. If it fails to start, further investigation with journalctl is needed.

The FQDN format is <service>.<namespace>.svc.cluster.local.

Option A is correct. kubectl logs with --previous retrieves logs from the previous container instance. Option B is also plausible but the question expects the most direct command with container name.

'kubectl get events --sort-by=.metadata.creationTimestamp' shows events sorted by creation time. Alternatively, 'kubectl get events -w' watches events but does not sort.

The kubelet is the primary node agent that runs on each worker node, not on the control plane. It is responsible for ensuring that containers are running in a Pod as expected by interacting with the container runtime (e.g., containerd or CRI-O). Control plane components are those that manage the cluster's state and scheduling decisions, which run on the control plane nodes.

kubectl port-forward forwards a local port to a pod port.

Option A is correct because a taint with effect NoExecute evicts existing pods that do not tolerate the taint, causing them to be rescheduled to a different node. This is a core Kubernetes scheduling behavior where the kubelet on the tainted node terminates the pod, and the scheduler then places it on a suitable node.

Option A is correct because a Job with `completions=3` and `parallelism=2` is considered complete when the required number of successful pod completions (3) is reached. Since two pods have already completed and the third is still running, once it finishes successfully, the total successful completions will equal the `completions` value, and the Job controller will mark the Job as Complete. The Job does not require all pods to run concurrently or finish simultaneously.

The kubelet is responsible for node status. On the node, you can check its logs with journalctl.

'kubectl exec' allows running commands inside a container, such as ping or curl to test connectivity.

Option D is correct because `kubeadm certs check-expiration` is the dedicated kubeadm command to display expiration dates for all PKI certificates in the cluster, including the client certificate used by the user's kubeconfig. This command parses the certificates directly from the `/etc/kubernetes/pki` directory and shows remaining validity, making it the precise tool for this scenario.

Option C is correct because `etcdctl endpoint health --cluster` queries the health status of all etcd endpoints in the cluster, which directly reveals if any node is unreachable or unhealthy—a common symptom of leader election issues. Option E is correct because `etcdctl member list` displays the current cluster membership, including each member's ID, name, peer URLs, and client URLs, allowing you to verify that all expected control plane nodes are properly joined and that no split-brain or quorum loss has occurred.

The service exists but DNS resolution fails, often because the service is in a different namespace and the DNS query uses only the bare name.

The command 'kubectl get endpointslices -l kubernetes.io/service-name=my-svc -n default' lists EndpointSlices for that Service. EndpointSlices are labeled with the Service name.

A is correct because 'kubectl describe pod <pod-name>' displays the Events section, which includes detailed reasons for a pod being stuck in Pending state, such as insufficient CPU/memory, persistent volume claims not binding, or node selector mismatches. This is the primary diagnostic command for understanding scheduling failures.

Option C is correct. 'kubectl rollout undo deployment myapp' reverts to the previous revision. Option A is incorrect because --to-revision=1 would roll back to the first revision, not the previous one.

The DNS name for a Service is <service>.<namespace>.svc.cluster.local. So my-svc.my-ns.svc.cluster.local.

Option C is correct because it uses the etcdctl v3 API with the required authentication flags (--cacert, --cert, --key) and the correct endpoint (https://127.0.0.1:2379) to connect to the etcd server running as a static pod. This ensures a consistent snapshot is taken over the secure gRPC connection, which is mandatory when etcd is configured with TLS.

Node taints affect scheduling, not image pulling. ImagePullBackOff is related to the container image.

Option D is correct because `kubectl config use-context` is the command specifically designed to switch the current context in a kubeconfig file. It updates the `current-context` field in the kubeconfig to point to the specified context, which then determines which cluster, user, and namespace are used by default for subsequent `kubectl` commands.

If nslookup hangs, it suggests the DNS server is not responding, typically a CoreDNS issue.

Option A is correct because if the kube-apiserver pod fails to start after a kubeadm upgrade, a clean re-application of the upgrade using 'kubeadm upgrade apply v1.29.0' after resetting the node with 'kubeadm reset' can resolve corrupted or mismatched configuration files, certificates, or static pod manifests. This process reinitializes the control plane components from scratch while preserving the target version, ensuring all manifests and certificates are regenerated correctly.

Option A is correct because `kubectl rollout undo deployment/<name>` reverts the Deployment to the previous revision by default. This command uses the rollout history stored in the Deployment's annotations (specifically `deployment.kubernetes.io/revision`) to restore the prior ReplicaSet's pod template, effectively undoing the failed image update.

Option A is correct because podAffinity with requiredDuringSchedulingIgnoredDuringExecution forces the scheduler to co-locate all Pods with the same app label on the same node. This directly overrides the default anti-affinity behavior that spreads Pods across nodes, ensuring low-latency inter-Pod communication by placing all replicas on a single node if possible.

To allow ingress from pods in any namespace, use a namespaceSelector: {} (empty) to select all namespaces, and a podSelector to select pods with label 'app: frontend'.

An Ingress resource with a TLS certificate is the correct choice because it provides a stable IP address (via the underlying LoadBalancer or NodePort Service) and terminates TLS at the ingress controller, allowing the web application to serve HTTPS traffic without modifying the Deployment. This meets the requirements of exposing the application externally with a fixed IP and TLS termination.

Option B is correct because the Kubernetes scheduler uses resource requests (CPU and memory) to determine node suitability for a Pod. The scheduler checks if the sum of requests for all Pods on a node, plus the new Pod's requests, is less than or equal to the node's allocatable capacity. Limits are not used for scheduling decisions.

kubectl port-forward pod/web-pod 8080:80 forwards local port 8080 to pod port 80.

The kubelet service is stopped or dead, which would cause the node to be NotReady.

Option D is correct because a Role in the 'monitoring' namespace with 'get' and 'list' verbs on pods, combined with a RoleBinding in the same namespace to the 'monitor-sa' ServiceAccount, grants the exact permissions required within the scope of that namespace. This follows the principle of least privilege by scoping permissions to the specific namespace where the pods reside.

The provisioner 'kubernetes.io/no-provisioner' is used for static provisioning, meaning no dynamic provisioning occurs. The StorageClass is used only to match PVs with the same storage class name. Since no PV with storage class 'fast' exists, the PVC will remain Pending until a matching PV is created manually.

systemctl status shows the current state of a systemd service.

kubectl run with --expose creates a Deployment (or Pod depending on version) and a Service.

A DaemonSet ensures that a copy of a pod runs on all (or a subset of) nodes. When a new node is added, the DaemonSet controller automatically schedules a pod on it unless the node has a taint that the pod does not tolerate. By default, the new node may have a taint (e.g., `node.kubernetes.io/unschedulable` or a custom taint) that prevents the DaemonSet pod from being scheduled unless the pod's spec includes a matching toleration.

kube-proxy supports userspace (deprecated), iptables, and ipvs modes. userspace is deprecated, but still a mode. The question asks for TWO valid modes. iptables and ipvs are both currently supported. userspace is deprecated but still valid? Typically in exam context, they consider iptables and ipvs as the main modes. I'll go with iptables and ipvs.

The `kubectl describe node <node-name>` command provides detailed information about a node, including its status, capacity, allocatable resources, and a list of conditions (e.g., DiskPressure, MemoryPressure, PIDPressure, Ready). This is the standard way to inspect the exact reason and timestamps for a DiskPressure condition, as well as related metrics like disk usage and inode consumption.

nodeSelector and requiredDuringSchedulingIgnoredDuringExecution node affinity both enforce scheduling on nodes matching label criteria.

The liveness probe is failing externally but the endpoint works internally. This suggests the probe is hitting the wrong port or the network path is different. The most likely cause is that the livenessProbe is configured with a wrong port number.

The command creates a Service named web-svc of type LoadBalancer that forwards traffic from port 80 on the Service to port 8080 on the selected pods. The Service selects pods based on the labels from the deployment 'web'.

The Ingress rule must specify the podSelector (or empty to select all pods in the namespace) with a namespaceSelector to match 'app' and a podSelector to match 'role: frontend'.

Option D is correct because an emptyDir volume with `medium: Memory` creates a tmpfs filesystem that uses the node's RAM, but it does not impose any inherent limit on how much memory the container can consume via that volume. Since the pod has no memory limit set (no `resources.limits.memory`), the container can write up to the node's available memory (4 GB) without being throttled or killed, as long as the node has sufficient free RAM.

EndpointSlices are more scalable and support dual-stack, and are the default since v1.21.

An empty string for storageClassName means that the PVC will only bind to pre-existing PVs that also have storageClassName: "" (i.e., no StorageClass). It disables dynamic provisioning.

These commands are essential for daily cluster management.

In Kubernetes, CPU resources are measured in millicores, where 1000m equals 1 full CPU core (vCPU or hyperthread). The '500m' in a resource request means the pod is guaranteed at least 500 millicores, or 0.5 CPU core, from the node's 2-core capacity. This is a standard unit used by the kubelet for CPU scheduling and the Completely Fair Scheduler (CFS) quota enforcement.