Certified Kubernetes Administrator CKA (CKA) — Questions 526–600

PersistentVolumeClaims are namespace-scoped objects, just like StatefulSets, Pods, and Services. When a StatefulSet defines volumeClaimTemplates, the StatefulSet controller creates the resulting PVCs in the same namespace in which the StatefulSet itself is created, ensuring that Pods and their volumes exist in the same Kubernetes namespace. This namespace isolation is a fundamental part of Kubernetes identity and access control: PVs are cluster-scoped, but PVCs cannot cross namespaces, and a Pod can only mount a PVC from its own namespace. Consequently, the PVCs are inevitably co-located with the StatefulSet.

A 'context deadline exceeded' error explicitly indicates that a gRPC or HTTP request timed out before receiving a response. In this scenario, network latency, packet loss, or misconfigured firewalls/security groups between the new node and the control plane prevent the kubelet from successfully posting its lease updates to the API server within the allocated timeframe.

This is the correct field path for defining rolling update behavior in a Kubernetes Deployment. By setting spec.strategy.rollingUpdate.maxUnavailable to 2, you guarantee that at least 2 pods (out of the 4 desired replicas) remain active and available to serve traffic at any given point during the rolling update process.

CreateVolume is a core gRPC method defined in the Container Storage Interface (CSI) Controller service specification. It is invoked by the Kubernetes external-provisioner sidecar to provision a new physical or virtual storage volume on the underlying storage provider before it can be attached to a node.

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.

A StorageClass's 'provisioner' field specifies the volume plugin responsible for dynamically provisioning PersistentVolumes. For example, 'kubernetes.io/aws-ebs' or 'pd.csi.storage-gke.io' causes the in-tree or CSI driver to create a new storage volume when a PVC references this StorageClass. Without a provisioner, a StorageClass cannot dynamically create PVs and is generally only useful for binding pre-existing PVs.

kubectl describe pod is the correct diagnostic because it displays the pod's status, conditions, container states, and a list of recent Events aggregated for that pod. These Events will contain specific errors such as FailedCreatePodSandBox, ErrImagePull, FailedMount, or CreateContainerError, along with the underlying message from the kubelet or container runtime. This gives you exactly the information needed to resolve ContainerCreating.

The KUBECONFIG environment variable accepts a colon-separated list of kubeconfig paths; with it set, kubectl loads and merges all listed files according to its precedence rules. kubectl config view outputs that merged in-memory configuration, and --flatten expands any file references (such as certificate-authority or client-key) into their base64-encoded inline data, producing a portable, self-contained kubeconfig. Redirecting the output into a file captures that single merged configuration.

kubectl top nodes queries the Metrics API (typically provided by metrics-server) to display the current CPU and memory usage for every node in the cluster. It reports actual consumption values, such as 82% memory, making it the correct command for checking real-time memory usage.

On clusters where control plane components are managed by systemd (e.g., packaged Kubernetes distributions or those set up with kubeadm before static pods became the default), `systemctl status kube-apiserver` queries the service manager for the exact process state, reporting whether the service is active, running, or failed. It also surfaces recent journal logs, making it a direct and authoritative check of the kube-apiserver service. However, this command is only valid when the component actually runs as a systemd unit; on clusters using static pods, it would return an error, so it is environment-specific but nonetheless a correct approach for systemd-based clusters.

This is the correct configuration because omitting the namespaceSelector entirely defaults the scope of the podSelector to the same namespace where the NetworkPolicy is applied. It successfully permits ingress traffic exclusively from pods labeled app: monitoring within the local namespace. This precisely satisfies the requirement of isolating traffic to specific local pods while maintaining the default-deny rule for everything else.

kubectl cordon node01 sets the node's unschedulable field to true, which causes the node to be marked as SchedulingDisabled in the output of kubectl get nodes. This prevents new pods from being scheduled onto the node while leaving all existing pods running, making it the safe and targeted way to remove a node from usage without disruption. The node remains fully Ready and can be re-enabled later with kubectl uncordon.

When a container's memory usage exceeds its cgroup memory limit, the kernel's OOM killer terminates the container process, and kubelet records the reason as OOMKilled. Even with no explicit request, the limit is enforced as a hard cap, so the container is killed precisely for trying to allocate more memory than that cap. This is the only condition that sets the OOMKilled termination reason.

Gateway is a core Gateway API resource, representing a specific load-balancing instance that defines listeners, protocols and TLS settings, and binds routes to underlying infrastructure. It sits alongside GatewayClass and HTTPRoute in the role-oriented model.

When an init container fails (e.g., exits with a non-zero status code), Kubernetes will restart it according to its restart policy. If it repeatedly fails, Kubernetes applies an exponential back-off delay between restart attempts. This continuous cycle of starting, failing, and backing off is precisely what the "Init:CrashLoopBackOff" status indicates for an init container, preventing the main application containers from ever starting.

This option is correct. When a StorageClass uses the WaitForFirstConsumer volume binding mode, the Kubernetes scheduler plays a crucial role. It first finds a suitable node for the Pod, considering all its requirements, including the PVC. Once the Pod is scheduled to a specific node, the PersistentVolume is then dynamically provisioned on that very node, ensuring optimal data locality and performance for the Pod.

kubectl describe pod pod-name aggregates the pod's current and recent states under the Status section, including the 'Last State' fields where the container's terminated reason and exit code are explicitly shown. This is the canonical way to inspect why a container crashed, because it presents the last container's exit code (e.g., 137 for SIGKILL or 1 for a general error) along with the reason, message, and timestamps. It also includes recent event history, making it the most direct command to answer the question.

A Released PV retains a claimRef pointing to the deleted PVC, which prevents binding to a new claim. Removing the claimRef field makes the PV Available again, allowing a new PVC with matching capacity and access modes to bind. This is the documented reclaim procedure for Retain policy volumes.

The Role is namespaced, so scoping it to `dev` via `metadata.namespace` confines the grant to that namespace alone. `apiGroups: [""]` correctly targets the core API group, where pods reside, and `verbs: ["list"]` matches the required action. ClusterRole would be needed only for cluster-wide access.

Logs are the first place to look for process exit reasons. `kubectl logs pod-name --previous` retrieves the captured stdout/stderr from the last crashed container instance, whereas the default `kubectl logs` shows the current (possibly non-existent) container. This lets you see the application's actual error, panic, or stack trace that occurred before the crash, even if the current container is in a CrashLoopBackOff state. This makes it a valid and often essential troubleshooting step.

To enable dynamic provisioning, you must define a 'StorageClass' object where the 'provisioner' field matches the registered name of your CSI driver. When a user submits a 'PersistentVolumeClaim' referencing this 'StorageClass', the Kubernetes volume controller automatically invokes the specified CSI driver to provision the underlying storage asset and create the corresponding 'PersistentVolume' on demand.

The kube-controller-manager bundles the core control loops that reconcile the cluster's actual state toward the desired state, such as node lifecycle, replication, and endpoint management. It is essential for a HA control plane because in that setup you run multiple replicas with leader election, so only one instance actively runs controllers while the others stand by, but at least one must be reachable via the API server. Without it, no automated corrections would be made to workloads, making it an indispensable control-plane component.

This explicitly sets the current-context field to my-context in the kubeconfig file, making kubectl use that context for subsequent commands. It performs the validation-free update needed to switch a running session from one context to another, and is the standard command for changing the active context. This makes it a valid configuration method.

Retain is a valid reclaim policy because when a PersistentVolume is released from a PersistentVolumeClaim, the underlying storage resource is kept intact. The volume is not automatically removed or scrubbed; instead, it remains in a Released state until a cluster administrator manually intervenes to recover or reuse it. This policy is essential for protecting critical data from accidental deletion.

CoreDNS generates DNS records only for Service objects that actually exist. If no Service named my-svc exists in the pod's namespace, the query for my-svc.<namespace>.svc.cluster.local returns NXDOMAIN, which is exactly the failure described. Because the short name my-svc is expanded using the pod's search domains to include the namespace, a missing Service object means no A record can be synthesized. Running kubectl get svc -n <namespace> to confirm that the Service is present is the correct first troubleshooting step.

The `kubectl describe pod` command provides a comprehensive, human-readable summary of a specific pod's current state, including its status, conditions, and a chronological list of *events* directly associated with it. For a pending pod, this command is invaluable as it surfaces critical information such as scheduler decisions, volume attachment issues, image pull failures, or resource constraints directly within the 'Events' section, clearly indicating the root cause of the pending state.

The kube-controller-manager is a client of the Kubernetes API server; every control loop (deployment, replicaset, namespace, service account) lists objects through the API. A repeated 'failed to list' or connection-refused error means the API server is either down, unresponsive, or unreachable from the controller node. This is the only condition that explains the manager's own client logs while the manager process itself remains running.

The error message for a missing tag in a registry is typically 'manifest unknown' or 'not found' (HTTP 404). The question states that the error clearly indicates the manifest is not found for the tag 'myimage:v2', which means that specific tag does not exist in the registry. This is a definitive registry-side response: the registry is reachable, the repository may exist, but the requested tag has no associated manifest.

kubectl top pods and kubectl top nodes are the correct commands because they query the Metrics API (backed by metrics-server) and display real-time CPU and memory utilization for pods and nodes. kubectl top provides immediate, current usage values, which is exactly what 'resource usage' means in a Kubernetes context.

The kubectl cordon command is the precise administrative tool used to toggle a node's status to unschedulable by updating its spec.unschedulable field to true. This action prevents the scheduler from assigning any new pods to the node while safely leaving existing, currently running workloads completely unaffected.

This is the exact procedure recommended by the official kubeadm upgrade documentation: for the control plane node, run `kubectl drain` (with `--ignore-daemonsets`), upgrade the `kubeadm` binary, run `kubeadm upgrade apply`, upgrade `kubelet`, restart it, then `uncordon` the node. Repeating the same drain-upgrade-uncordon cycle for worker nodes ensures they remain within the supported version skew and maintains cluster availability throughout the rolling upgrade.

The error "manifest not found" specifically indicates that the container registry was successfully contacted, but it does not contain a schema or manifest matching the requested repository and tag combination. This occurs when the deployment specifies an image tag, such as "latest", that was never pushed to the registry or has been deleted.

kubectl top nodes queries the Metrics API, which is backed by metrics-server, to report each node's current CPU and memory usage as a percentage of allocatable capacity. This is the standard command for quickly assessing real-time node utilization in a cluster. It requires the metrics-server (or a compatible metrics API) to be installed and producing node metrics.

ImagePullBackOff is the kubelet's status when it fails to fetch a container image, and the most frequent cause is a typo in the image name or an invalid/unavailable tag (for example, `nginx:lateest` or `myapp:v2` that does not exist in the registry). The kubelet retries the pull with an exponential backoff, and the underlying error — such as `manifest unknown` or `not found` — is visible in the pod's Events via `kubectl describe pod`. Because the image reference itself is unresolvable, the container never starts and the pod remains in this state until the image reference is corrected.

An empty `podSelector` targets all pods in the 'app' namespace, and because the policy defines `Ingress` in its `policyTypes` but contains no allowed ingress rules, it acts as a default-deny policy. This effectively blocks all incoming traffic to every pod in that namespace.

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.

When a container terminates with exit code 1, it indicates an application-level failure or configuration error rather than an external infrastructure issue. Inspecting the container logs using `kubectl logs` is the primary troubleshooting step to identify runtime exceptions, missing environment variables, or syntax errors causing the process to crash immediately upon startup.

This is the official and recommended command under the etcd v3 API to create a point-in-time, consistent backup of the keyspace. It securely writes the active database state to a specified file path on the local disk. For a successful execution in a secure Kubernetes cluster, this command must be accompanied by the appropriate CA certificate, client certificate, and private key flags.

kube-proxy is the component that directly maintains network rules on each node. It watches the Kubernetes API for Service and EndpointSlice objects, then programs iptables rules (or IPVS entries) to translate a Service's ClusterIP to the IP addresses of its backing Pods. This provides load-balanced, virtual-IP connectivity to Pods without a traditional proxy process in the data path.

kubectl top nodes relies on the metrics-server to collect resource usage from each kubelet and expose them through the metrics.k8s.io API. If metrics-server is not installed, the API endpoint returns 404 or no data, and kubectl top prints an error such as "error: metrics not available yet". If metrics-server is installed but not running (CrashLoopBackOff, pending), the same failure occurs because the API aggregator has no healthy backing service. Therefore, verifying the metrics-server deployment and its API service is the first step.

When a container enters CrashLoopBackOff, the kubelet has successfully started the process and the runtime is restarting it because of a non-zero exit. If the application dies immediately—for example, due to a missing executable, an invalid ENTRYPOINT, a panic before logging setup, or an exec format error—there is no stdout/stderr capture for kubectl logs to return. The restart count increments and the container's state becomes Waiting with reason CrashLoopBackOff, but the logs remain empty.

`journalctl -u kubelet` is the correct approach because kubelet is registered as a systemd service under the unit name `kubelet.service` on essentially all managed Kubernetes distributions. This command displays all journal entries associated with that unit, preserving timestamps, priorities, and source metadata. It is the standard first step for diagnosing kubelet failures, and can be combined with flags like `-f`, `-n 100`, or `--since` for targeted live troubleshooting.

`kubectl describe pod <pod-name>` is the correct command because it aggregates the container's current status (Waiting with reason ImagePullBackOff) and the recent pod Events, including the detailed error message from the container runtime, such as "Failed to pull image" with the specific registry response (e.g., "not found" or "unauthorized"). This single command shows the image name, the node, and a timestamped history of pull attempts, making it the fastest path to diagnose why the image pull failed.

This is the correct command because it first cordons the node to prevent new scheduling and then safely evicts all active pods to other nodes in the cluster. The --ignore-daemonsets flag is required because DaemonSet-managed pods cannot be rescheduled elsewhere and would otherwise block the drain operation from completing.

Setting volumeMode: Block on a volume causes Kubernetes to present the backing storage as an unformatted raw block device inside the container. You must attach it through the container's volumeDevices list, providing a devicePath (e.g., /dev/xvdb), rather than using volumeMounts and a mountPath. This is required for workloads such as databases or storage engines that manage their own on-disk layout and want to bypass the filesystem layer entirely. Only Block mode supports this raw device access model.

`kubectl top pods` is the correct command to view current resource usage. It queries the Metrics API, typically served by metrics-server, which aggregates per-container CPU and memory data from kubelet/cAdvisor. The output shows values like CPU in cores or millicores and memory in bytes or mebibytes, giving an accurate snapshot of live consumption. However, it depends on metrics-server being deployed in the cluster.

This is the correct sequence: `mkdir -p $HOME/.kube` ensures the default kubeconfig directory exists, `sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config` copies the cluster-admin kubeconfig generated by kubeadm into the current user's home, and `sudo chown $(id -u):$(id -g) $HOME/.kube/config` makes the file readable/writable by the current user. Because the admin.conf file is owned by root (readable only by root), sudo is required for the copy; without the chown, kubectl would fail to read the kubeconfig. The resulting `~/.kube/config` is discovered automatically by kubectl, granting full cluster-admin privileges to the local user.

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.

kube-scheduler is the control plane component that selects the optimal node for each newly created pod. It subscribes to the API server's watch stream for pending pods, filters nodes according to resource requirements, taints/tolerations, node selectors, and affinity rules, then scores the feasible candidates to choose the best match. The decision is written back as a binding object, which sets the pod's nodeName field, so this component alone is responsible for assigning pods to nodes.

A node can have multiple taints in its spec.taints list, each defined by a key, value, and effect (NoSchedule, PreferNoSchedule, or NoExecute). For a pod to be schedulable, it must tolerate every taint present on the node; if any taint lacks a matching toleration, the pod will not be scheduled there. This allows fine-grained control over node isolation.

kubectl logs pod-name --previous retrieves the log output from the previous instantiation of the container in the same pod. When a container crashes and restarts, the kubelet replaces its log file, so the current logs only contain output from the new, possibly healthy instance. The --previous flag accesses the log file of the terminated container, making it the correct way to see the crash-related output.

The `kubernetes.io/aws-ebs` provisioner is specifically designed to interact with the AWS EC2 API to create EBS volumes. For this provisioner to function correctly, the Kubernetes cluster must be running within an AWS environment, and the `kube-controller-manager` must be configured with the AWS cloud provider integration. If the cluster is not on AWS, or if the cloud provider integration is misconfigured or missing, the provisioner cannot authenticate or make API calls to AWS, leading to the PVC remaining in a `Pending` state indefinitely as it cannot provision the underlying storage.

A container whose startup command includes invalid arguments (for example, a misspelled flag, undefined positional parameter, or a file path that does not exist) causes the runtime to launch the process only for it to exit immediately with a non-zero exit code. Because the process fails before it can do meaningful work, the kubelet sees a completed/error container and applies the restartPolicy, which rapidly restarts it and transitions to CrashLoopBackOff. The backoff timer doubles on each restart, but the underlying command flaw remains, so the crash loop persists until the arguments are corrected.

A Kubernetes Job creates one or more pods and ensures that a specified number of them successfully terminate, tracking the overall completion. It is the ideal controller for a one-time batch task because the pod runs to completion and the Job status becomes Complete, without any automatic restart of the finished pod. If the pod fails, the Job can restart it according to the backoffLimit, ensuring the task eventually succeeds.

The field storageClassName is the correct, canonical way to reference a StorageClass in a PersistentVolumeClaim. It tells the Kubernetes scheduler which StorageClass should be used to dynamically provision a PersistentVolume for this claim. If the StorageClass exists and is available, the provisioner associated with it creates the underlying storage, and the PV is bound to the PVC. If storageClassName is not specified, the cluster's default StorageClass is used, but explicit specification ensures the desired class is selected. This field is part of the PVC spec and is crucial for controlling storage characteristics like performance, reclaim policy, and provisioner.

As the primary node agent, the kubelet is responsible for ensuring that containers described in PodSpecs are running and healthy on its node. It acts as the bridge between the control plane and the container runtime, translating declarative pod specifications into runtime commands via the Container Runtime Interface (CRI).

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`.

To grant cluster-wide permissions to a ServiceAccount, you must pair a ClusterRole with a ClusterRoleBinding. Because a ClusterRoleBinding is a non-namespaced resource, it applies the permissions defined in the ClusterRole across all namespaces in the cluster, as well as to cluster-scoped resources like Nodes and PersistentVolumes.

This is the correct solution as it precisely meets the requirements. It creates a `ServiceAccount` named `deployer` in the `app` namespace. A `Role` is then defined in the `app` namespace, granting the specific permission to create `deployments`. Finally, a `RoleBinding` in the `app` namespace associates this namespaced `Role` with the `deployer` `ServiceAccount`, ensuring permissions are confined strictly to the 'app' namespace.

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.

accessModes is a mandated field for both PersistentVolumes and PersistentVolumeClaims, and it must contain at least one valid access mode such as ReadWriteOnce, ReadOnlyMany, or ReadWriteMany. Kubernetes uses these modes to enforce how many nodes can mount the volume and whether it can be mounted read-only. Without this field, the API server will reject the claim because there is no way to determine the volume's intended access semantics.

The `podAntiAffinity` rule explicitly prevents a pod from being scheduled on a node that already hosts another pod matching specific labels within a defined topology domain. If the `kubectl describe po` output indicates an anti-affinity conflict on the third node, either relaxing the `podAntiAffinity` rule in the pod's specification or removing the existing, conflicting pod from that node would allow the pending pod to be scheduled. This directly resolves the constraint preventing the pod from finding a suitable node.

With the default podManagementPolicy of OrderedReady, a StatefulSet creates or terminates pod replicas one at a time in strict ordinal order. When scaling up, each pod must become Ready before the next is started; when scaling down or deleting, pods are removed from the highest ordinal back to the lowest, waiting for each deletion to complete. This controlled sequencing lets distributed applications bootstrap or shut down in a predictable, deterministic manner instead of all replicas launching simultaneously.

The events described are exactly what kubectl describe pod would show when the kube-scheduler cannot find a feasible node: a combination of 'Insufficient memory' (the pod's resource requests exceed allocatable memory on every node) and 'node(s) had untolerated taint' (the pod lacks a matching toleration for a taint applied to candidate nodes). Since the scheduler must satisfy both the resource request/limit check and the taint/toleration rule before binding, the pod is never assigned and remains Pending. This is a scheduling failure, not a runtime issue.

kube-proxy runs on every worker node and is responsible for implementing the Kubernetes Service abstraction by maintaining network rules that govern traffic forwarding to backend pods. It watches the API server for Service and Endpoint changes and programs iptables, IPVS, or userspace rules to route packets correctly. This directly matches the task of maintaining network rules on a worker node, making it the correct answer.

This Role grants the verbs "get," "watch," and "list" for the "pods" resource, which are all read-only operations in Kubernetes RBAC. "get" retrieves a single pod's details, "list" enumerates pods, and "watch" streams pod changes. Because the rule is scoped to the development namespace via a Role and the verbs are read-only, this correctly describes the permission to read pod details in that namespace.

The application's logs clearly show an attempt to establish a database connection to the hardcoded IP address "10.0.0.1". In a Kubernetes environment, applications should typically connect to services using their DNS-resolvable service names (e.g., 'mysql' or 'mysql.default.svc.cluster.local') rather than static cluster IPs, which are ephemeral and subject to change. This misconfiguration prevents the application from correctly resolving and connecting to the intended 'mysql' service, leading to the CrashLoopBackOff.

When a container starts, the container runtime attempts to execute the command specified in the container's configuration. If the /app binary is missing from the image or the path is misconfigured, the runtime fails to spawn the process, resulting in a container creation or start failure with a 'no such file or directory' error.

The scheduler rejected every node because the control-plane node carries the `node-role.kubernetes.io/master:` taint with no matching toleration in the pod spec. Without a toleration for that specific key and effect, the scheduler cannot bind the pod, leaving it Pending indefinitely.

The kubectl logs command uses the --container (or shorthand -c) flag to select a specific container in a multi-container pod. Here, web-pod is the pod name and app-container is the container name, which is the exact syntax required. This command correctly returns only the logs from app-container, making it the right choice.

GatewayClass is a core, cluster-scoped resource in the Kubernetes Gateway API that defines a template and set of common configurations for a class of Gateways. Similar to how IngressClass functions for Ingress resources, it links the declarative API to a specific controller implementation that manages the underlying data plane infrastructure.

ReadWriteMany (RWX) is the correct access mode because it allows multiple pods to mount the volume simultaneously with both read and write access, regardless of which nodes those pods run on. This is the only standard access mode that satisfies the requirement of shared read-write storage for many pods. RWX is typically supported by network-based storage like NFS, CephFS, or GlusterFS, and is essential for applications such as clustered web servers or shared content management systems.

The kubelet is the core node agent that takes PodSpecs from the API server or local manifests and uses the Container Runtime Interface to instruct a runtime such as containerd or CRI-O to pull images, create sandboxes, and start containers. It also monitors container health, enforces pod resources, and reports status back to the control plane. Because it is the component that directly drives the runtime, the kubelet is responsible for running containers.