CKA Exam Questions and Answers

etcd

etcd is a distributed, consistent, and highly available key-value store that serves as Kubernetes' backing store for all cluster data. It persistently stores the entire cluster state, including configuration data, metadata for all Kubernetes objects like Pods, Deployments, and Services, and the desired state of the system. Its robust consistency model is critical for ensuring that all control plane components operate on a single, unified source of truth.

SSH into the worker node and run 'kubeadm upgrade node', then upgrade kubelet and kubectl, then restart kubelet.

This is the standard procedure for upgrading a worker node with kubeadm.

kubelet

The kubelet is the Kubernetes node agent that runs on every node, including control-plane nodes. It registers the node with the API server, watches for Pod objects bound to that node, and continually drives the actual state of containers toward the desired PodSpec. It performs liveness, readiness, and startup probes and reports pod/node status back to the API server. Because it is the component that owns the pod lifecycle on a node, it is the only component in this list that is a required Kubernetes component on every node.

kubeadm certs check-expiration

This subcommand is the authoritative way to inspect the lifetimes of all certificates managed by kubeadm, including the CA, apiserver, controller-manager, scheduler, kubelet, and the client certificate embedded in admin.conf. It prints a table showing the expiration date and remaining days for each component, giving immediate insight into whether certificate expiry is causing authentication problems. For kubeadm-based clusters, this is the correct first tool for diagnosing certificate-related authentication issues.

The node is under memory pressure and cannot admit the pod.

Memory pressure prevents the scheduler from placing the pod on that node.

kubectl config set-credentials

This is the correct command because it creates or updates the user entry in the kubeconfig with the necessary authentication credentials, such as --client-certificate, --client-key, --token, or --username/--password. Running this command ensures that a named user with valid credentials is available for contexts to reference. Without it, you only have cluster and context definitions but no authenticated identity to actually connect to the API server.

NodePort

NodePort exposes the service on a static port on each node's IP address.

my-service.ns1.svc.cluster.local

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.

The service 'api-service' must have a valid ClusterIP and at least one endpoint.

The Ingress controller forwards traffic to the service's ClusterIP, and endpoints must exist for the service to forward to pods.

The CoreDNS ConfigMap does not have the correct cluster domain.

CoreDNS's kubernetes plugin reads a ConfigMap (typically named 'coredns' in the kube-system namespace) to determine the cluster domain, usually 'cluster.local.' If the 'kubernetes' block in that ConfigMap specifies a mismatched or missing domain, CoreDNS will not append the correct search domain, so fully qualified service names like 'my-svc.my-ns.svc.cluster.local' will fail to resolve. Since the pod is running, a static misconfiguration in the ConfigMap is a primary suspect and directly explains the symptom.

A list of A records for each pod matching the service selector.

A headless Service with a selector creates Endpoints (or EndpointSlices) from the ready pods that match the labels. When a client looks up this Service name, CoreDNS returns one A record for each such pod IP, allowing direct pod discovery. This behavior is fundamental to StatefulSets, where each pod gets its own DNS name from this list.

The service endpoints include only the two healthy pods

The Endpoints object for a Service contains only the IP addresses of Pods that are currently Ready — that is, passing their readiness probes. Since two of the three Pods are healthy, the Service's Endpoints (or EndpointSlices) list exactly those two Pod IPs, and the ClusterIP load balances only to them.

Increase the memory limit in the pod's container resource specification

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

kubectl rollout history deployment web-app

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.

StatefulSets maintain a sticky identity for each pod, including stable hostnames and persistent storage

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.

500 millicores (0.5 CPU core)

In Kubernetes, CPU resources are specified in millicores, where 'm' is the unit suffix. A value of 500m precisely denotes 500 millicores, which is equivalent to 0.5 of a full CPU core. This is the standard, absolute measure for CPU requests and limits, ensuring consistent resource allocation across nodes.

Pod B will be preempted (evicted) to allow pod A to be scheduled on the node

This is the correct behavior. When Pod A, possessing a higher priority, cannot find a node with sufficient available resources, the kube-scheduler will identify a node where Pod B (a lower-priority pod) is running and whose eviction would free up the necessary resources. The scheduler then initiates the preemption process, which involves evicting Pod B from that node. This action frees up the required resources, allowing Pod A to be successfully scheduled and started on the now-available node.

Using envFrom with configMapRef

Using envFrom with configMapRef is a valid and straightforward way to expose all key-value pairs from a ConfigMap as environment variables. The configMapRef field inside envFrom specifies a source ConfigMap by name, and Kubernetes populates every entry from that ConfigMap into the container's environment. This is ideal when you want to inject multiple variables without listing each key individually, though you may still override specific keys using the env field.

Using env field with valueFrom and configMapKeyRef

The env field with valueFrom and configMapKeyRef is a valid way to expose a specific key from a ConfigMap as an environment variable. The valueFrom wrapper indicates that the variable's value should be sourced from an external reference, and configMapKeyRef specifies the ConfigMap name and the key to extract. This allows you to cherry-pick individual entries and optionally give the environment variable a different name than the ConfigMap key.

The CSI driver is not installed or malfunctioning.

The StorageClass references a CSI provisioner (e.g., csi.contoso.com), and Kubernetes relies on the external-provisioner sidecar to send CreateVolume RPCs to the CSI driver controller. If that driver controller is not installed, the DaemonSet pods are CrashLooping, or the CSI socket is unavailable, the provisioner cannot create the backend volume, so no PV is bound and the PVC remains Pending with events like 'Failed to provision volume with storage class'. Inspecting the csi-controller logs and the driver DaemonSet status will confirm the malfunction.

Use the 'items' field in the ConfigMap volume definition to specify which keys to include.

The `items` field within a ConfigMap volume definition is the precise and recommended method for selectively exposing specific keys as files inside a container. By specifying `key` and `path` for each desired entry, only the relevant data from the ConfigMap is mounted into the pod's filesystem, preventing unnecessary data exposure. This approach ensures minimal resource usage and adheres to the principle of least privilege by only providing what is strictly required. For example, `items: [{key: "app-config.yaml", path: "config.yaml"}]` mounts only the `app-config.yaml` key as `config.yaml`.

Retain: The PV remains in the cluster and must be manually reclaimed.

Retain is correct because the PersistentVolume object remains in the cluster after its PVC is released, transitioning to the Released phase rather than being automatically removed. The underlying storage asset is preserved intact, and an administrator must manually reclaim it, typically by deleting the PV or clearing the claimRef so the volume can be reused under a new claim.

Delete: The PV and the associated storage asset are automatically deleted.

Delete correctly describes the policy where both the PersistentVolume object and its associated cloud storage asset are automatically removed once the PVC is deleted. This is the default for many dynamic provisioners, such as AWS EBS or GCE PD, and helps ensure that orphaned volumes do not incur ongoing costs.

A PersistentVolume with access mode ReadWriteMany

A PersistentVolume with access mode ReadWriteMany allows multiple pods across different nodes to simultaneously read and write to the same storage volume, satisfying the stem’s requirement for concurrent access from pods scheduled on distinct nodes. This access mode directly addresses the constraint of multi-node, multi-pod stateful workloads, whereas ReadWriteOnce would restrict access to a single node.

The PV that should bind to the PVC has a nodeAffinity that does not match any available node.

When a PersistentVolumeClaim (PVC) uses the WaitForFirstConsumer binding mode, the selection or provisioning of a PersistentVolume (PV) is delayed until a pod requiring that PVC is scheduled. If the selected PV has nodeAffinity rules that do not match the node where pod-2 was scheduled, the volume attachment will fail. This mismatch prevents the volume from being mounted, causing pod-2 to remain in a Pending state, unable to start its containers.

The PV pv-data enters the Released state and is not deleted.

With the Retain reclaim policy configured, deleting the bound PVC causes the PV to enter the Released state rather than being deleted or recycled. This means the PV still exists and its underlying storage resources—such as disk data—remain intact, but it is no longer bound to any claim. The PV will remain in Released status until an administrator manually intervenes, typically by deleting the PV and recreating it or by editing its claimRef to allow rebinding. This preserves data for recovery but leaves the PV unused until explicit manual action is taken.

kubectl logs api-6f4d7b9d4c-abcde -n production --previous

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 pods have label 'app: payment-service' instead of 'app: payment', so the service selector does not match.

A Service's spec.selector uses exact key-value matching to choose backing pods. If the selector is app: payment and the pods are labeled app: payment-service, the values are different, so the Endpoints controller does not add any pod IP to the Service's backend. Label matching is exact, not substring-based, so the Service will have no endpoints and in-cluster clients cannot connect to it.

The Secret 'my-secret' does not exist in the namespace.

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.

An init container failed

When an init container exits with a non-zero exit code, the pod status transitions to Init:Error (or Init:CrashLoopBackOff if it keeps failing). Kubernetes treats init containers as mandatory prerequisites: they run sequentially to completion before any regular containers start. The failing init container can be identified with kubectl describe pod, which shows the last exit code and reason, and its logs are available via kubectl logs <pod> -c <init-container-name>. This directly matches the init error status shown in the question stem.

A NetworkPolicy is blocking the traffic

NetworkPolicy is a namespace-scoped firewall that can restrict egress traffic from a specific pod (via podSelector) to a destination service's backing pod IP or CIDR. Even if the Service object and endpoints are intact, a NetworkPolicy denying egress from the source pod to the backend pod's IP or port will silently drop the packets, making the Service unreachable only for the affected pod(s).

kube-proxy is not running on the node.

The container is listening on a different port than the Service targetPort.

The bootstrap token used for TLS bootstrapping has expired.

Bootstrap tokens used in TLS bootstrapping are intentionally short-lived and can expire, especially if they were created for a one-time node registration. When a token expires, the API server rejects the kubelet's authentication attempt, returning a 401 Unauthorized, and the kubelet cannot complete the bootstrap sequence or download the CA certificate. This precisely matches the observed symptom of a bootstrap CA retrieval failure, making it the correct root cause.

Ensure that containerd is installed and running on the worker node.

The kubelet on the worker node communicates with the container runtime through the Container Runtime Interface (CRI), typically over a Unix socket such as /run/containerd/containerd.sock. If containerd is not installed, the service is stopped, or the socket is missing, kubelet will fail with a CRI connection error and never start pods. Run `systemctl status containerd` and check the socket path configured in kubelet (--container-runtime-endpoint) to confirm the runtime is active.

Create an EncryptionConfiguration resource specifying a provider like 'aescbc' and configure the kube-apiserver with --encryption-provider-config.

An EncryptionConfiguration resource defines the order and type of providers (such as aescbc, aesgcm, secretbox, or kms) for protecting specific API resource types. The kube-apiserver must be started with --encryption-provider-config=/path/to/encryption-config.yaml, and when it writes data like Secrets to etcd it encrypts that data using the chosen provider (aescbc uses AES-CBC with a randomly generated IV and a 32-byte key). This is the canonical, Kubernetes-native mechanism for encryption at rest and is exactly what the CKA objectives expect.

Run kubeadm join with the --control-plane flag on the new node.

To expand a single control plane Kubernetes cluster into a highly available multi-control plane setup, the `kubeadm join` command is the correct utility. Specifically, including the `--control-plane` flag instructs `kubeadm` to not only join the new node to the cluster but also to install and configure all necessary control plane components (API server, scheduler, controller-manager, etcd member) on that node. This command orchestrates the secure integration and replication of critical cluster services, ensuring the new node can participate as a full control plane member.

Deploy etcd on dedicated nodes with SSD storage.

Deploying etcd on dedicated nodes with SSD storage is the recommended best practice for production Kubernetes clusters. Dedicated nodes ensure etcd has exclusive access to CPU, memory, and network resources, preventing interference from other workloads. Furthermore, etcd is highly sensitive to disk I/O latency, making fast SSD storage crucial for maintaining low write latencies, high throughput, and overall cluster stability and responsiveness.

Job

A Job controller creates one or more pods and tracks them until a specified number successfully terminate. For a one-time task, a simple Job with default completions=1 runs once to completion, and the workload is not recreated if it exits with code 0. It is the native Kubernetes API for exactly-once batch processing.

Create a PriorityClass with a high value and assign it to the 'payment-processor' Deployment

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 container will not restart, and the Pod will be in Succeeded phase.

With restartPolicy: OnFailure, an exit code of 0 means the container completed its workload successfully, so the kubelet deliberately avoids restarting it. Because all containers have exited with code 0 and no restart is warranted, the Pod's phase is set to Succeeded, which is the terminal state for successful Pod completion. This matches the expected behavior for batch or job-style workloads that should run to completion exactly once.

Set nodeSelector to 'accelerator=nvidia-tesla' and request 'nvidia.com/gpu' in resources.

This is the correct and comprehensive approach because it addresses both the placement of the Pod and the allocation of the specialized hardware resource. The `nodeSelector` ensures the Pod is scheduled exclusively onto nodes labeled `accelerator=nvidia-tesla`, which are the GPU-equipped nodes in this scenario. Simultaneously, requesting `nvidia.com/gpu` in the Pod's `resources` section (either `requests` or `limits`) informs the Kubernetes device plugin for NVIDIA GPUs to allocate a specific GPU device to the container, making it available inside the Pod. Both mechanisms are crucial for successful GPU workload deployment.

Requests are used by the scheduler to decide which node can accommodate the Pod.

During scheduling, kube-scheduler evaluates each candidate node by subtracting the sum of container requests for CPU and memory from the node's allocatable capacity. A node is deemed feasible only if it can satisfy all requested quantities, because requests represent the minimum resource reservation needed to run the Pod. Limits are deliberately ignored in this admission calculation, making requests the primary input for node fit decisions.

The QoS class is determined based on requests and limits.

Kubernetes classifies a Pod's QoS class by comparing requests and limits set for every container in the Pod. If all containers specify equal requests and limits for both CPU and memory, the class is Guaranteed; if any container's request or limit differs, it is Burstable; if no resources are specified at all, it is BestEffort. This class determines how the kubelet ranks Pods for eviction and OOM score adjustments under memory pressure.

Memory limits can cause the Pod to be OOMKilled if exceeded.

Memory is incompressible, so the kernel enforces a memory limit as a hard cgroup cap. When a container's memory usage exceeds that cap, the OOM killer is triggered and terminates a process with the highest OOM score, often resulting in the entire Pod being restart. This is fundamentally different from CPU throttling because the limit breach causes termination, not just reduced performance.

Assign a high priority class to the database Pod.

Assigning a high priority class to the database Pod is the most effective solution for ensuring critical workloads are scheduled promptly. When the scheduler attempts to place a high-priority Pod and cannot find a node with sufficient resources, it will actively preempt (evict) lower-priority Pods from existing nodes to free up the necessary capacity. This mechanism directly addresses resource contention, significantly reducing the scheduling delay for essential applications like a database.

db-service.backend.svc.cluster.local

db-service.backend.svc.cluster.local is the fully qualified domain name Kubernetes automatically creates for the Service named db-service in the backend namespace. Any Pod in any namespace, including frontend, can use this FQDN because it contains every component needed by CoreDNS to locate the ClusterIP. It is the canonical cross-namespace address and avoids relying on search domains or local-only short names.

The cluster DNS service (10.96.0.10)

With the default `ClusterFirst` DNS policy, the `kubelet` configures the pod's `/etc/resolv.conf` to list the cluster DNS service IP (e.g., 10.96.0.10, which is the default `kube-dns` or `CoreDNS` service IP in many clusters) as the primary nameserver. All DNS queries originating from the pod are initially sent to this cluster DNS service. The service then resolves internal cluster names directly and forwards external name queries to upstream DNS servers.

The pods are not in Ready state (e.g., failing readiness probes).

Readiness probes determine whether a pod is included in the Service's EndpointSlices. The endpoint controller monitors pod readiness and only adds pods whose readiness probe is currently passing; pods failing readiness (or running a container that never becomes ready) are excluded. If all matching pods fail their readiness probe, the endpoint list is empty, and traffic to the Service's ClusterIP or DNS name is dropped. This directly explains why traffic is not reaching the application when the selector matches but no endpoints exist.

Ingress resource with a TLS certificate

An Ingress resource, coupled with an Ingress controller, provides a robust solution for exposing web applications externally by offering HTTP/S routing, virtual hosting, and crucially, built-in TLS termination. It allows defining rules to route external traffic to specific services based on hostnames or URL paths, and can manage TLS certificates (stored as Kubernetes Secrets) to encrypt traffic from the client to the Ingress controller, ensuring secure communication.

The database pods can initiate outbound connections to any destination.

Since only Ingress is specified, egress is allowed by default.

Pods with label 'app: api' can connect to the database pods on TCP port 5432.

The ingress rule explicitly allows pods with label app:api on port 5432.

The connection succeeds and reaches the pod on port 8080.

The service is correctly configured with endpoints mapping port 80 to targetPort 8080.