Certified Kubernetes Administrator CKA (CKA) — Questions 376–450

The Service must exist in the cluster because the cluster DNS system only creates DNS A/AAAA records for Service objects, not for individual pods or arbitrary endpoints. When a Service is created, the DNS controller registers a name in the form <service>.<namespace>.svc.<cluster-domain>, and without that object there is no record for the resolver to return. This is a prerequisite independent of the DNS server itself or the pod's resolver configuration: even a healthy CoreDNS and correctly set resolv.conf cannot resolve a Service name that was never defined.

Ingress is the standard Kubernetes API resource designed specifically to manage external access to services, typically via HTTP and HTTPS. It allows administrators to define routing rules based on hostnames (Layer 7 domain names) and URL paths, enabling a single external IP address to expose multiple backend services.

A Kubernetes Secret, including one used for image pull credentials, must reside in the same namespace as the Pod that attempts to consume it. While this is a fundamental requirement for secret access, the primary issue indicated by the correct answer is that the ServiceAccount itself isn't configured to *use* any image pull secret. Therefore, the error would not specifically point to a cross-namespace secret issue, but rather a lack of credentials being presented at all.

This is the correct behavior of the command. It binds to port 8080 on the local loopback interface and securely tunnels any connection made to localhost:8080 through the API server to port 80 of the specified Service, which then routes it to the backing Pods.

Creating a PriorityClass with a high integer value and assigning it to the 'payment-processor' Deployment is the most effective solution. Pods with higher priority are preferentially scheduled by the kube-scheduler. Crucially, if a high-priority 'payment-processor' pod cannot be scheduled due to insufficient resources on any node, the scheduler will attempt to preempt (evict) lower-priority pods on suitable nodes to free up the necessary resources, thereby ensuring the critical workload runs.

The legacy Endpoints API stores every IP address for a Service in a single object, which becomes extremely large and causes every node's kube-proxy to be notified on any change. EndpointSlices partition that data into multiple, smaller objects that default to a maximum of 100 endpoints each, so scaling to thousands of pods does not create a single massive, frequently updated resource. This dramatically reduces the update blast radius and improves overall cluster performance.

This is the most effective command because `kubectl exec` runs `curl` directly within the network namespace of `pod-a`, simulating the exact origin of the communication. By targeting `http://service-b:80`, it simultaneously tests DNS resolution of the service name, the ability to establish a TCP connection to the service's ClusterIP on port 80, and the application's responsiveness. This provides a comprehensive end-to-end test from the perspective of the source pod.

StatefulSets are designed to provide a stable, unique identity to each pod they manage, which is crucial for stateful applications. This identity includes a stable network hostname, typically in the format `$(pod-name).$(headless-service-name)`, and persistent storage that remains associated with the pod's ordinal index even if the pod is rescheduled to a different node. This ensures data integrity and consistent application behavior across pod lifecycle events.

kubectl config current-context is the dedicated subcommand that reads the kubeconfig file and prints the name of the currently active context to standard output. It returns exactly one line—the context name—with no additional formatting, making it ideal for scripting and automation. This directly satisfies the admin's need to view the current context, so it is the correct command.

Kubernetes matches a PVC to a PV by comparing requested capacity and access modes; the selected PV must have at least the requested storage size and advertise access modes that satisfy the claim. The control plane performs this binding automatically, and when a match is found, the claim and volume are bound in a one-to-one relationship, meaning no other PVC can use that same PV until the bound is released. If no suitable PV exists, the claim stays in Pending, awaiting either an administrator-created PV or a dynamically provisioned volume from the named StorageClass.

A PersistentVolumeClaim configured with the ReadWriteMany (RWX) access mode allows a volume to be mounted as read-write by many nodes concurrently. This is the correct choice for enabling multiple pods distributed across different nodes in a cluster to simultaneously access and modify the same persistent storage backend.

This command correctly uses the `--from-file` flag, which instructs `kubectl` to read the entire content of the specified file, `config.properties`. It then creates a ConfigMap named `app-config` where the key for this entry defaults to the filename, `config.properties`, and its corresponding value is the complete textual content of that file. This is the standard and intended method for incorporating file contents directly into a ConfigMap.

Kubernetes authenticates users via X.509 client certificates presented during the TLS handshake. The certificate's Common Name (CN) is mapped to the username, and organization fields become groups. This is a primary method for external users and components like the kubelet to authenticate to the API server.

Executing `kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local` is the most direct and effective method for debugging DNS resolution issues from within a specific pod. This command leverages `kubectl exec` to run `nslookup` directly inside `my-pod`, utilizing that pod's `/etc/resolv.conf` and its configured DNS server. It precisely tests whether the pod itself can successfully resolve the fully qualified domain name (FQDN) of the `kubernetes` service, providing immediate insight into its DNS capabilities.

IPVS (IP Virtual Server) is a kernel-level transport-layer load balancer that exposes multiple scheduling algorithms, including round-robin (rr), least-connections (lc), destination hashing (dh), and source hashing (sh). kube-proxy in IPVS mode programs these algorithms into the kernel, allowing operators to select a traffic distribution strategy that best fits their workload instead of being limited to iptables' simple random or default behavior.

The `kubectl expose deployment web --port=80 --target-port=8080 --type=NodePort` command creates a Service of type NodePort, which allocates a high port (30000–32767) on every cluster node and forwards traffic from that port to port 8080 on the pods selected by the `web` deployment. This satisfies the requirement to expose the deployment externally without a cloud load balancer, using each node’s IP address as the access point.

kubectl logs api-6f4d7b9d4c-abcde -n production --previous is the correct command because it fetches the stdout/stderr from the previous, now-terminated container instance in the pod. In a CrashLoopBackOff, the currently restarted container usually has no useful logs — it may not have started, or it immediately restarted before writing anything — while the last crashed instance carries the actual error that triggered the restart. This gives you the application-level failure message (e.g., uncaught exception, missing config, listen EADDRINUSE) needed to fix the root cause; pair it with kubectl describe pod to see the last exit code and restart count.

The scheduler reports Insufficient memory, meaning no node has enough allocatable memory for the pod's request. Lowering the container's memory request brings it within available capacity, allowing the scheduler to bind the pod to a suitable node.

In Kubernetes, Ingress resources can only reference TLS Secret objects that reside within the exact same namespace. If the Secret containing the TLS certificate and private key is deployed in a different namespace, the Ingress controller will fail to locate it, resulting in TLS handshake failures or fallback to a default self-signed certificate.

The scheduler cannot bind the pod to any node because every candidate lacks sufficient allocatable CPU or memory. Unschedulable resource requests leave the pod without a node assignment, so it remains Pending until capacity frees up or the pod's requests are reduced.

When the kubelet or volume manager attempts to attach or mount a CSI volume, it communicates with the CSI driver via gRPC. If the driver fails to respond within the designated timeout period, the operation fails with a timeout error in the pod events, indicating the driver is unresponsive or overloaded.

When a node becomes unreachable or experiences network partition issues, the node controller automatically applies the node.kubernetes.io/unreachable taint to it. Because the pending pod does not possess a matching toleration for this specific taint, the Kubernetes scheduler cannot assign the pod to any of these affected nodes, leaving it stuck in the Pending state.

The admin.conf file holds the cluster's certificate authority data and admin credentials, so copying it into the regular user's $HOME/.kube/config gives kubectl the endpoint and authentication it needs. This satisfies the requirement to let kubectl communicate with the freshly initialised cluster.

NodePort is the correct service type because it reserves a static port from a default range (30000-32767) across all cluster nodes. This allows external clients to access the service by targeting any node's IP address combined with the designated static port, satisfying the requirement directly without external dependencies.

The `kubectl top nodes` command retrieves resource usage data from the Metrics API, which is typically backed by a metrics-server that collects node-level metrics from kubelets. It reports current CPU and memory consumption in both absolute units (e.g., millicores and MiB) and as percentages of node allocatable resources. This is exactly the command needed to answer the question about node resource usage.

This is the correct command to renew all control plane certificates managed by kubeadm at once. It automatically regenerates the certificates under the PKI directory and updates the embedded client certificates within the administrative kubeconfig files.

After restoring a snapshot to a new directory, you must point etcd at that directory by modifying the --data-dir flag or the corresponding etcd manifest environment variable. If you omit this step, etcd will start using its original data directory and the restored data will be ignored. Additionally, you may need to update the --initial-cluster and --initial-cluster-token to match the restore's --name and new cluster ID to avoid conflicts.

For a ClusterIP service without a selector, Kubernetes relies on a manually created Endpoints resource sharing the same name. kube-proxy will configure the data plane (such as iptables or IPVS) to intercept traffic sent to the Service's ClusterIP and route it directly to the target IP addresses and ports defined in that Endpoints object.

DNS resolution of svc.ns2.svc.cluster.local requires a Service named svc in namespace ns2; CoreDNS returns NXDOMAIN when that Service is absent. Since the pod's own namespace is irrelevant to a fully qualified cross-namespace lookup, a missing Service in ns2 is the most likely cause.

Running `kubectl exec` into a pod and curling the Service's ClusterIP directly tests the Service's virtual IP from inside the cluster network namespace. This validates the entire data path: the pod's routing, kube-proxy or iptables/ipvs rules, and backend endpoint selection. It is especially useful because the ClusterIP is only reachable from within the cluster, so a successful curl proves the kube-proxy rules are installing correctly and that at least one healthy backend is receiving traffic. A failed curl with a timeout, rather than a connection refused, also gives a specific hint about whether packets are being silently dropped.

If a container demands more memory than its limit allows, the image has already been successfully pulled and the container has started, so the failure mode is OOMKilled or an overloaded kubelet eviction, not ImagePullBackOff. ImagePullBackOff is exclusively a pre-start image acquisition failure, making this the one option that could never produce that state.

The `kubectl describe pod` command is the correct diagnostic because it aggregates the pod's status conditions, container states, and, crucially, the recent Events list from the kubelet and the image puller. For an `ImagePullBackOff`, the events will contain a specific reason such as `ErrImagePull`, `ImagePullBackOff`, `Failed to pull image`, or a registry authentication/not found error with the exact HTTP status. This detailed output is exactly what you need to pinpoint whether the problem is a typo in the image tag, missing credentials, or network connectivity to the registry.

The exhibit's event message contains the exact Kubernetes error string: the secret `my-secret` could not be found in the pod's namespace, so the kubelet is unable to inject the environment variable or volume content required by the container spec. Every Secret reference is namespaced, and the kubelet queries the API server for the secret exactly as it appears in the pod manifest; any typo, wrong namespace, or omitted resource will immediately produce this failure. Because the error is explicit and points to a missing API object, the most likely cause is that `my-secret` simply does not exist in the namespace where the Pod is running.

When a PersistentVolumeClaim references a non-existent or misconfigured StorageClass, the dynamic volume provisioner cannot fulfill the request. Consequently, the PVC remains stuck in a Pending state indefinitely. Because the Pod's volume mount depends on a successfully bound PVC, the Kubernetes scheduler cannot assign the Pod to a node, preventing it from starting.

This is the canonical way to specify resource requirements in Kubernetes: each container has a `resources` field containing `requests` and `limits`. The `cpu` value `"500m"` means 500 milliCPUs (half a core), and `"1"` means one full core; memory uses binary suffixes, with `"512Mi"` and `"1Gi"` being valid mebibyte units. These strings are parsed by Kubernetes quantity format, and this structure is accepted by the API server while satisfying both scheduling and kubelet constraints.

kubectl config current-context is the dedicated kubectl subcommand that prints exactly the name of the context currently selected for use, reading the current-context field from your kubeconfig. It is the most direct, script-friendly way to determine which cluster and user your kubectl commands will target, and it returns a nonzero exit status if no current context is set.

NodePort is a highly reliable, built-in method that allocates a static port (typically in the 30000-32767 range) across all cluster nodes. External traffic hitting any node's IP address on this designated port is automatically routed to the underlying target pods, making it a universally supported way to expose services.

etcdctl snapshot save <filename> is the canonical etcd backup operation: it connects to the etcd endpoint (default https://127.0.0.1:2379), takes a consistent point-in-time snapshot of the keyspace, and writes it to the specified file. The resulting snapshot is the input used by etcdctl snapshot restore to rebuild a cluster, and it should be created with endpoint, CA, cert, and key flags when TLS is enabled.

This is correct. The EndpointSlice controller runs inside the kube-controller-manager and automatically watches Services with selectors and the Pods that match those selectors. Whenever a matching Pod is created, updated, or removed, the controller creates, updates, or deletes the appropriate EndpointSlice objects. This automation means administrators never manually create EndpointSlices; they are entirely controller-managed.

`kubectl describe pod pod-name` is a correct first step because it shows container states (Waiting, Running, Terminated) with detailed reason and message fields—for example, `CrashLoopBackOff`, `ImagePullBackOff`, or `OOMKilled`. It also lists recent events specific to that pod, such as failed volume mounts or failed liveness probes, which directly explain why a container may have never produced logs or why its log stream was cut short. When `kubectl logs` returns nothing, this command reveals whether the container even started, and if it did, what caused it to terminate or restart, making it an essential troubleshooting action.

When an Ingress controller loads a TLS secret, it does not validate the expiration date of the certificate during the configuration phase. It will successfully bind the certificate to the listener and complete the TLS handshake with clients. However, because the certificate's validity period has passed, the client's browser or TLS library will flag it as untrusted and display an expiration warning.

A DaemonSet creates exactly one Pod on each eligible node and automatically adds Pods when new nodes join the cluster, which matches the every-node requirement. Because tainted nodes would otherwise be skipped, the Pod template must include a matching toleration so the DaemonSet controller schedules onto those nodes as well. This combination satisfies both the coverage and the one-per-node constraints.

A Kubernetes Service only forwards traffic to Pod IPs listed in its Endpoints object, which are populated by the controller based on matching selectors and the readiness status of pods. If the selector matches no pods, or the pods are not Ready (e.g., failing readiness probes or CrashLoopBackOff), the Endpoints object is empty, so connections to the Service's ClusterIP are dropped or refused. Running 'kubectl get endpoints' is the quickest way to confirm whether the Service actually has healthy, Ready backends, directly exposing the most common cause of communication failure.

The kube-controller-manager runs core control loops, such as the Deployment and ReplicaSet controllers, which continuously monitor the cluster's actual state against the desired state declared in etcd. When discrepancies are detected, these controllers issue commands to make corrective changes, ensuring the cluster converges on the target configuration.

When a pod requests more CPU than any node can allocate, the kube-scheduler cannot find a feasible host and sets the pod to Pending, recording an event such as `Insufficient cpu`. CPU requests are guaranteed amounts that the scheduler sums across all existing pods and compares against a node's `allocatable` CPU (node capacity minus reserved system components). Until some running pods are terminated or a node with more free CPU joins the cluster, the pod will remain Pending, which exactly matches the given event.

When sessionAffinity is set to ClientIP, kube-proxy implements client IP-based session affinity, directing all requests from a given client IP to the same backend pod for the configured timeout (default 3 hours). This exactly matches the scenario where a single client pod's requests all go to pod A. It is a common configuration for stateful applications.

kubectl describe pod <pod> is correct because it renders the pod's full status section, including each container's current state (Waiting, reason, message), and appends pod Events. For an ImagePullBackOff, the Events show the exact registry error (e.g., unauthorized, manifest unknown, network timeout), and the container status shows the backoff reason, giving you the diagnostic detail needed to fix the image pull failure.

This is the correct Fully Qualified Domain Name (FQDN) for a Kubernetes service. It adheres to the standard format: `<service-name>.<namespace-name>.svc.<cluster-domain>`. Here, `my-service` is the service name, `ns1` is its namespace, `svc` denotes it as a service, and `cluster.local` is the default cluster domain. This FQDN provides an unambiguous and universally resolvable address for the service from any pod within the cluster, regardless of the querying pod's own namespace.

kubectl describe pod <pod-name> outputs a comprehensive summary of the pod's configuration and status, culminating in an Events section that chronologically lists recent events for that specific pod (e.g., successful pull, failed schedule, container started). These events often contain the direct cause of a pod problem, making this command one of the two candidates that actually surface events. However, it only shows events for the named pod, so its scope is limited to that Pod object.

`kubeadm certs check-expiration` is the dedicated subcommand that inspects certificates under /etc/kubernetes/pki and prints a table with each certificate's expiration date and time remaining before it expires. It also flags certificates that are externally managed and warns when renewal should happen. This read-only command is the standard way to verify certificate validity on a kubeadm-created cluster.

This is the correct command because it explicitly sets the environment variable to use the v3 API and specifies the snapshot save subcommand. It also correctly provides the secure loopback endpoint along with the mandatory CA certificate, client certificate, and private key required to authenticate against a TLS-secured etcd cluster.

The ReadWriteOnce (RWO) access mode permits a PersistentVolume to be mounted as read-write by a single node at any given time. Crucially, once mounted by that node, any number of pods scheduled onto that specific node can concurrently access the volume for both reading and writing operations. This perfectly satisfies the question's requirement for multiple pods to read and write, provided they are co-located on the same host.

The error 'no such file or directory' for /app/start.sh in the container logs directly indicates that the command or entrypoint defined in the pod spec references a script that does not exist within the container image. This typically happens when a Dockerfile fails to COPY the script into the image, or the image tag points to an older build without the file. Because the process cannot start, the container exits non-zero and Kubernetes enters CrashLoopBackOff.

The kube-proxy is the essential component on each worker node responsible for implementing the Kubernetes Service abstraction. It continuously watches the Kubernetes API server for Service and EndpointSlice objects and translates them into network rules, typically using iptables or IPVS, within the node's kernel. This ensures that requests directed to a Service IP are correctly routed and load-balanced to the healthy Pods backing that Service, effectively maintaining the data plane for cluster networking.

The kubeadm certs check-expiration command is specifically designed to scan the /etc/kubernetes/pki directory and the kubeconfig files in /etc/kubernetes to determine the validity and expiration dates of all control plane certificates. It displays a clear, tabular summary showing the residual lifetime, expiration date, and authority of each certificate. This is the standard, built-in tool for administrators to proactively manage cluster certificate lifecycles.

emptyDir is created when the Pod is assigned to a node and exists as long as that Pod is running. It is used for sharing data between containers and is deleted when the Pod is removed.

This is correct because when a high-priority Pod cannot be scheduled due to insufficient resources, the scheduler actively looks for nodes where evicting lower-priority pods can free up enough capacity. The scheduler will then preempt those lower-priority pods, allowing the high-priority Pod to be scheduled and run.

A required ConfigMap that does not exist causes the kubelet to fail when it tries to start the container, because it cannot retrieve the referenced keys for environment variables or volume mounts. The typical event is: "Error: configmap \"<name>\" not found" and the Pod status may be CreateContainerConfigError or ContainerCreating. This is exactly the scenario described: the Pod appears stuck, yet the underlying cause is a configuration object that is missing, not a scheduling or resource issue. Therefore, this is the correct answer.

systemctl status kubelet is the definitive, node-local command for inspecting the kubelet's systemd service state. It directly queries systemd's unit properties, showing whether the unit is active (running), failed, activating, or inactive, along with the main process ID (MainPID) and recent journal entries. This is the first step when the kubelet is suspected of malfunctioning because it immediately confirms whether the process is alive and healthy from the init system's perspective, without relying on the Kubernetes API or network latency. It also reveals the exit code or last status change, which is essential for diagnosing crashes or manual stops on the node itself.

When a PVC bound to a PV with a Retain reclaim policy is deleted, the PV is preserved to prevent data loss. Its status transitions to Released, indicating that the claim has been deleted but the volume still contains data and requires manual intervention by an administrator to be reclaimed or reused.

kubectl describe pod pod-name is correct for CrashLoopBackOff because it displays the pod's full lifecycle events, container states, restart counts, and the last reason/exit code from the previous terminated container. Those events often reveal the root cause, such as image pull failures, failed readiness/liveness probes, or OOMKilled. It also shows the current backoff state and timestamps, making it the first diagnostic command to run.

A NetworkPolicy with an empty `podSelector: {}` targets all pods within its namespace. When no `ingress` rules are explicitly defined, or an empty `ingress: []` array is present, and `policyTypes` implicitly defaults to `["Ingress"]`, the policy effectively denies all incoming network connections to these selected pods. This creates a secure-by-default posture for ingress traffic across the entire namespace, preventing any external or internal pod-to-pod communication unless explicitly allowed by another policy.

kubectl rollout history deployment web-app is correct because it is the dedicated kubectl subcommand for viewing the Deployment's rollout history. It lists all revisions with their change-cause annotations (if set), and can be combined with --revision to inspect a specific revision; this history is actually derived from the underlying ReplicaSets created for each change to the pod template.

The scheduler evaluates the pod's CPU request against the allocatable CPU on each node after reserving resources for existing pods and system components. If the requested CPU exceeds what any node can accommodate, the scheduler reports 'Insufficient cpu' and leaves the pod Pending. This is a resource-fit failure, not an API or runtime error, so checking the pod's resources.requests is the first diagnostic.

The new pod's resource requests are 1 CPU and 2Gi memory. When combined with the existing pods' total requests of 3 CPU and 5Gi memory, the cumulative resource consumption becomes 4 CPU and 7Gi memory. Since the ResourceQuota specifies hard limits of 4 CPU and 8Gi memory for requests, both the CPU and memory totals remain at or below their respective quotas. Therefore, the admission controller allows the pod to be created without any quota violations.

A NoSchedule taint on a node instructs the Kubernetes scheduler to exclude any Pod that does not have a matching toleration from being placed onto that node. It is a hard scheduling constraint: the scheduler will not assign new Pods to that node unless the Pod's toleration matches the taint's key, value, and effect. However, Pods already running on the node are not evicted by this effect, so it is useful for cordoning off nodes for maintenance without disrupting workloads.

If the cluster lacks nodes with enough allocatable CPU or memory to satisfy the pod's resource requests, the Kubernetes scheduler cannot assign the pod to any node and leaves it in Pending. The scheduler only considers unreserved resources calculated as capacity minus requests from existing pods; a node with insufficient free capacity or failing a node selector will keep the pod unschedulable. The scheduler emits events like '0/3 nodes are available: insufficient cpu' to point you to this condition.

Deleting and recreating the PersistentVolume resource is a standard and clean way to make the underlying storage available for new claims. Because the reclaim policy is Retain, deleting the Kubernetes PV object does not destroy the actual data on the external storage provider. Recreating the PV with the same storage details allows a new PVC to bind to it successfully.

The correct answer is the CNI plugin. The Container Network Interface plugin manages pod networking and, depending on the implementation (e.g., Calico, Cilium, Weave, or Antrea), also enforces NetworkPolicy by programming dataplane rules. When a NetworkPolicy is created or updated, the CNI plugin receives the pod metadata and translates the allow/deny rules into iptables, eBPF, or other forwarding constructs. Without a CNI plugin that supports NetworkPolicy, the rules are stored by the API server but have no effect on traffic.

Scaling down other Deployments reduces the total CPU requests reported against those nodes, which is exactly what the scheduler uses to compute resource availability. When the request sums drop below a node's allocatable capacity, the pending pod's request can fit, enabling successful placement. This resolves the root cause of the pending state without altering the pod's toleration settings or risking node stability, and it is a common operational remedy for clusters experiencing CPU exhaustion.

If one or more nodes have taints (e.g., node-role.kubernetes.io/control-plane:NoSchedule) and the pod spec lacks matching tolerations, the scheduler will exclude those nodes from feasible candidates. As a result, the pod remains in Pending because no node can satisfy both taint/toleration rules and other scheduling predicates. This is a common cause of Pending, especially in single-node clusters or clusters with specialized node pools.

etcd is a distributed, strongly consistent key-value store that holds the authoritative state of the entire Kubernetes cluster, including all objects, configs, and secrets. It is a foundational control plane component because every API read/write is persisted there, and control plane controllers rely on its data. Without a healthy etcd quorum, the cluster cannot function correctly.

The kubelet is the primary node agent that runs on every node and is responsible for ensuring that containers described in PodSpecs are running and healthy. It registers the worker node with the cluster API server and continuously monitors the status of Pods, executing actions such as starting, stopping, or restarting containers as needed. It directly manages the container runtime (like containerd) and enforces resource limits and probes.

`kubectl logs` captures the container's stdout/stderr, so a database connection failure (e.g., "connection refused" or "dial tcp: lookup db-service") is exactly what appears. This is a typical application-level startup error that causes the process to exit, triggering the kubelet's restart backoff. Probe failures or OOM would not produce this specific log content, making this the most plausible direct cause.