Certified Kubernetes Administrator CKA (CKA) — Questions 451–525

With OrderedReady pod management, StatefulSet deletion proceeds in reverse ordinal order, waiting for each pod to terminate before moving to the next. So it deletes db-2, then db-1, and stops at 1 replica (db-0 remains).

PriorityClass with value 1000000 is extremely high (the default max is 1 billion). When a pod with this PriorityClass is submitted and the cluster has limited resources, the Kubernetes scheduler may preempt (evict) lower-priority pods to free resources and schedule this high-priority pod. This is the core behavior of PriorityClass and preemption in Kubernetes.

The liveness probe is failing with 503, meaning the application is not ready or healthy. Fixes include correcting the probe endpoint, adjusting probe parameters, or fixing the application.

kubectl get events with --watch or sorting by lastTimestamp. The simplest is 'kubectl get events --sort-by=.metadata.creationTimestamp'.

Option C (kubectl uncordon) is correct because it marks a node as schedulable, allowing new pods to be placed on it. Option E (kubectl cordon) is correct because it marks a node as unschedulable, preventing new pods from being scheduled while leaving existing pods running. Both commands directly manage the node's schedulability status by toggling the `spec.unschedulable` field.

Bearer tokens, such as those used by service accounts, are a valid authentication method for the Kubernetes API server. The API server validates the token against the token authentication file or, for service accounts, against the TokenReview API, which verifies the token's validity and associated identity.

Option C is correct because `kubectl rollout undo deployment/web-app --to-revision=1` explicitly rolls back the Deployment to revision 1, which is the desired state. The `--to-revision` flag targets a specific revision from the rollout history, ensuring the Deployment's Pod template is reverted to the exact configuration of revision 1.

If a service has no endpoints, it means no pods matching the service's selector are running and ready.

Kubernetes DNS names follow the format <service>.<namespace>.svc.cluster.local.

Tolerations allow pods to be scheduled on tainted nodes. Adding a toleration that matches the taint permits scheduling.

When no external load balancer is provisioned, the EXTERNAL-IP remains <pending> indefinitely.

The `kubectl drain` command is the correct tool for safely evicting all pods from a node before maintenance. It marks the node as unschedulable (similar to `cordon`) and then gracefully terminates pods, respecting PodDisruptionBudgets, ensuring workloads are rescheduled to other nodes without disruption.

PriorityClass in Kubernetes is used to assign a priority value to pods, which the scheduler uses to determine scheduling order and, critically, to enable preemption. When the cluster is under resource pressure, the scheduler can preempt (evict) lower-priority pods to make room for higher-priority pods that cannot be scheduled. This ensures that critical workloads can run even when resources are scarce, which is the core purpose of PriorityClass.

Option D is correct because the ResourceQuota 'compute-quota' sets a hard limit of 2 CPUs for all pods in the namespace. If the current total CPU limit usage is already 1, adding a new pod with a limit of 2 would bring the total to 3, exceeding the quota. Kubernetes enforces ResourceQuota at admission time, rejecting the pod creation to prevent the namespace from exceeding its configured limits.

Exit code 137 means the container was killed by SIGKILL (128 + 9). This is often due to being OOM-killed when it exceeds its memory limit.

kubeadm is the correct choice because it is the official Kubernetes tool for bootstrapping production-grade clusters on bare-metal servers, supporting high availability (HA) for the control plane via stacked or external etcd topologies. It integrates with etcd operators (e.g., etcdadm or the etcd-operator project) for cluster management, allowing automated etcd cluster lifecycle operations. Other tools either lack HA control plane support, are not designed for bare-metal, or do not use etcd operators.

Option A is correct because draining the control plane node before upgrading it ensures that all workloads are evicted and rescheduled to other nodes, preventing service disruption. This is a standard Kubernetes procedure where 'kubectl drain' marks the node as unschedulable and evicts pods, respecting PodDisruptionBudgets.

Option C is correct because the absence of endpoints for the Service indicates that the Service's selector is not matching any pods, or the pods are not listening on the correct port. Since the pods have the label 'app: web' and the Service uses 'app: web', the issue is likely that the container port (3000) is misconfigured or the readiness probe is failing, causing the pods to be removed from the Service's endpoints. The Ingress controller's 'upstream connect error' confirms that traffic cannot reach the pods, which aligns with the missing endpoints.

Network Policies are namespaced resources in Kubernetes, meaning they are defined within a specific namespace and only apply to pods in that namespace. This is confirmed by the Kubernetes API, where NetworkPolicy is a namespaced resource under the networking.k8s.io/v1 API group, and it cannot be applied cluster-wide without additional tooling like a cluster-scoped policy engine.

A persistent volume claim in Pending state can prevent a pod from starting if the pod uses a PVC that is not bound.

Option A is correct because it uses the `secret` volume type with the `secretName` field to reference a Kubernetes Secret object. This is the standard syntax for mounting a Secret as a volume in a Pod, allowing the Secret's data to be exposed as files in the container's filesystem.

During a Kubernetes cluster upgrade, the control plane components must be upgraded in a specific order to maintain cluster stability and API availability. etcd, as the cluster's backing store, should be upgraded first because all other control plane components (kube-apiserver, kube-scheduler, kube-controller-manager) depend on it for reading and writing cluster state. Upgrading etcd first ensures that the data store is compatible with the new version before the API server and other controllers are updated.

Intermittent connectivity issues with multiple replicas often stem from requests being distributed across different pods, which can break session state if the application is not stateless. Setting `service.spec.sessionAffinity` to `ClientIP` ensures that all requests from a given client IP are routed to the same pod, providing stable connectivity for stateful sessions without changing the service type or removing the ClusterIP.

kubectl describe pod shows events including the exact error message from the kubelet when pulling the image.

Option C is correct because `kubeadm init` is the official Kubernetes command to bootstrap a control-plane node and initialize a new cluster. It performs preflight checks, generates certificates, creates the static Pod manifests for core components (etcd, API server, controller manager, scheduler), and configures the admin kubeconfig file.

kubectl rollout history deployment web shows the revision history of the deployment.

The event indicates that all nodes have taints that the pod does not tolerate. This can happen if the nodes are NotReady or unreachable, often due to a network plugin issue or kubelet failure.

etcd is the distributed key-value store that serves as the single source of truth for the entire cluster, storing all cluster state data such as configurations, secrets, service endpoints, and resource specifications. The kube-apiserver reads from and writes to etcd exclusively, making it the only component that directly persists the cluster's desired and current state.

LimitRange applies default resource requests and limits to pods that do not specify them. The pod gets request=0.5, limit=1.

The init container runs a `wget` command to download a file. The pod transitions from `Init:0/1` to `PodInitializing` (indicating the init container started) and then to `Init:Error`, which means the init container exited with a non-zero exit code. Since the image is `busybox` (which includes `wget`), the most likely cause is that the `wget` command itself failed — e.g., due to a network issue, a bad URL, or a timeout — not an image pull failure or resource limit.

PathType Prefix matches URLs that have the path as a prefix. /api matches /api, /api/v1, /api/v1/users, etc. ImplementationSpecific is not standard; Exact would require exact match.

kubectl exec allows running commands inside a container; curl is a common tool to test HTTP connectivity.

Option D is correct because Kubernetes DNS resolves services using the format `<service>.<namespace>.svc.cluster.local`. Since the pod is in the 'frontend' namespace and needs to reach 'db-service' in the 'backend' namespace, the fully qualified domain name (FQDN) must include the namespace and the 'svc' subdomain to be resolved by the cluster DNS (CoreDNS).

kubectl exec lets you run commands inside a pod (e.g., ping, curl). kubectl run creates a temporary pod for testing. kubectl logs and edit are not network debugging tools.

The kubelet is the primary node agent that runs on every node and is responsible for registering the node with the cluster and maintaining pod lifecycle. After 'kubeadm init', if the control-plane node shows 'NotReady', it almost always indicates that the kubelet is not running or is failing to communicate with the control plane, often due to missing or misconfigured container runtime (e.g., containerd, CRI-O) or network plugin (CNI).

The correct command to back up etcd is `etcdctl snapshot save`, which creates a point-in-time snapshot of the etcd key-value store. This is the officially recommended method for backing up etcd data in Kubernetes clusters, as it captures the entire database state consistently.

Option A is correct because 'etcdctl snapshot restore' is the command used to restore an etcd cluster from a snapshot. You must specify a new data directory (e.g., --data-dir=/var/lib/etcd-restored) to avoid overwriting existing data and to allow the restored snapshot to be used as a fresh data source for the etcd member.

Option B is correct because a NetworkPolicy can explicitly deny ingress traffic to a pod even when the service endpoints are correctly populated. Since the endpoints list shows the pod's IP, the service and pod are communicating at the network layer, but a NetworkPolicy with an ingress rule that does not allow traffic from the source pod's labels or CIDR will cause the packet to be dropped by the node's iptables or eBPF rules, resulting in a connection timeout or reset from the client pod.

Using kubectl exec to curl the other pod's IP (B) or service name (D) are direct methods. 'kubectl logs' (A) shows logs but does not test connectivity. 'kubectl port-forward' (C) is for local access. 'kubectl run' (E) can be used to create a temporary pod for testing, but the question asks for approaches to test connectivity between existing pods, so exec is more direct.

OOMKilled means the container exceeded its memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Pod anti-affinity rules prevent the pod from being scheduled on nodes that already have pods matching certain labels. The error indicates that all nodes are excluded due to anti-affinity constraints.

A pod stuck in 'Pending' state means it has not been scheduled to a node yet. The `kubectl describe pod` command provides detailed event logs, scheduler decisions, and resource constraints (e.g., insufficient CPU/memory, persistent volume claims not bound, node selector mismatches) that reveal why scheduling failed. This is the first diagnostic step because it surfaces the root cause without requiring the pod to be running.

When a node is cordoned using `kubectl cordon <node>`, it is marked as unschedulable by setting the `spec.unschedulable` field to `true`. This prevents new pods from being scheduled onto the node, but existing pods continue to run normally. The kubelet remains active, and the node stays in the cluster.

The batch/v2alpha1 API version for CronJobs was deprecated in Kubernetes 1.21 and removed entirely in 1.29. Since the cluster was upgraded from 1.28 to 1.29, the custom controller can no longer use this API version because the API server no longer serves it. Controllers must migrate to the stable batch/v1 API version to function correctly.

The Gateway API includes GatewayClass, Gateway, HTTPRoute, and other route types. Service and Ingress are not part of the Gateway API; Ingress is a separate API.

When a container exceeds its memory limit, the kernel OOM killer terminates it. The container will be restarted (depending on restartPolicy).

Option C is correct because a Headless Service (with `clusterIP: None`) does not provide a single stable IP or load balancing. Instead, it returns DNS A/AAAA records for all pod IPs that match the service's selector. This is essential for StatefulSets, where each pod has a unique identity and clients need to discover and connect to specific pods directly, such as in a database cluster.

`kubeadm reset` is designed to revert any changes made by `kubeadm init` or `kubeadm join` on a node, effectively cleaning up the node's local state (e.g., removing CNI configurations, etcd member data, and kubelet certificates) so it can be safely removed from the cluster or reinitialized. Option C correctly identifies this as removing the node from the cluster and cleaning up, which is the primary purpose of the command.

Option D is correct because `kubectl config get-contexts` lists all contexts defined in the kubeconfig file, showing their names, clusters, and users. Option E is correct because `kubectl config view` displays the entire merged kubeconfig file content, including clusters, users, and contexts, in YAML or JSON format.

The Ingress controller must be running and the IngressClass must be defined, but the most direct requirement is that the backend service exists and has endpoints.

The tag '1.21' does not exist in the registry. Use a valid tag like '1.21.6' or 'latest'.

kubectl port-forward allows forwarding local ports to pods.

Option C is correct because `kubectl get events --all-namespaces --sort-by='.lastTimestamp'` retrieves events from all namespaces and sorts them by the `lastTimestamp` field in ascending order, which effectively displays the newest events last. To show newest first, you would typically add `--sort-by='.lastTimestamp'` and reverse the output, but among the given options, this is the only one that uses the correct field for sorting by time and includes all namespaces, which is necessary for cluster-wide events.

RWO allows only one node to mount the volume as read-write. If a second pod on a different node tries to use the same PVC, it will fail because the volume is already attached to node A.

kube-proxy is the component responsible for managing network rules and forwarding traffic on each node. It implements the Kubernetes Service concept by maintaining iptables or IPVS rules that route packets to the correct backend pods, handling load balancing and service discovery at the network layer.

Option B is correct because a NetworkPolicy in the 'db' namespace with an empty podSelector: {} selects all pods in that namespace, and the ingress rule from namespace 'app' with an empty podSelector: {} allows traffic from any pod in the 'app' namespace. This configuration restricts inbound traffic to the database pods exclusively to pods from the 'app' namespace, meeting the requirement.

Option C is correct because `etcdctl snapshot save` is the command used to create a point-in-time backup of etcd data. This command captures the entire key-value store and writes it to a specified file path, which is essential for disaster recovery in Kubernetes clusters that use etcd as their backing store.

When a node is in NotReady state, the first diagnostic step is to gather information about the node's current status, conditions, and recent events using `kubectl describe node <node>`. This command reveals the node's conditions (e.g., Ready, DiskPressure, MemoryPressure), the last heartbeat timestamp, and any relevant events that may indicate the root cause, such as network issues or kubelet failures. It provides a high-level overview without requiring direct node access, making it the most efficient initial action.

Option B is correct because `spec.nodeSelector` is a simple, direct field in the Pod spec that constrains which nodes a Pod can be scheduled on based on node labels. When you specify a key-value pair in `nodeSelector`, the scheduler will only place the Pod on nodes that have that exact label, making it a valid method for restricting Pod placement.

To troubleshoot DNS, you can check the DNS pod logs, test resolution from a pod, and verify the DNS service endpoints.

An Ingress rule has a 'host' field and a 'http' path with a backend service. The backend specifies the service name and port.

ipvs mode supports more scheduling algorithms (e.g., rr, lc, dh) and scales better than iptables. iptables is linear, while ipvs uses efficient hash tables.

DNS resolution requires kubelet to configure the pod's DNS (A), CoreDNS to serve DNS records (B), and the Service to exist (C). kube-proxy handles traffic, not DNS (D). CNI plugin handles networking but not DNS resolution (E).

Ingress is the Kubernetes resource that provides HTTP/HTTPS routing, TLS termination, and name-based virtual hosting.

Option C is correct because simply associating a ServiceAccount with a Pod does not automatically inject its imagePullSecrets into the Pod's spec. The ServiceAccount must explicitly have the imagePullSecrets field configured (e.g., `imagePullSecrets: - name: my-secret`) for the secret to be used when pulling images. Without this field, the Pod will not inherit the secret, leading to authentication failures and ImagePullBackOff.