Certified Kubernetes Administrator (CKA) Exam Questions

An administrator is bootstrapping a new Kubernetes control-plane node using kubeadm init. Which component is responsible for initializing the cluster’s control-plane components and generating the initial join token for worker nodes?

⬜ A. kubectl
✅ B. kubeadm
⬜ C. kubelet
⬜ D. containerd

Explanation:
kubeadm is the tool purpose-built to bootstrap a Kubernetes cluster: it initializes control-plane components (kube-apiserver, kube-controller-manager, kube-scheduler, etcd) as static pods and generates the token used by kubeadm join to add worker nodes.
Why other options are incorrect:
A: kubectl is the CLI used to interact with an already-running cluster’s API server; it does not bootstrap the cluster itself.
C: kubelet is the node agent that runs on every node and manages pod lifecycle; it does not initialize the control plane.
D: containerd is a container runtime that runs containers; it has no role in cluster bootstrapping.
Source: Creating a cluster with kubeadm

---

A cluster administrator wants to upgrade a kubeadm-provisioned cluster from one minor version to the next. Which statement correctly describes the required order of operations?

⬜ A. Upgrade all worker nodes first, then upgrade the control-plane node last.
✅ B. Upgrade the kubeadm tool and the control-plane node first, then upgrade worker nodes one at a time.
⬜ C. Upgrade kubelet on every node simultaneously without draining any nodes.
⬜ D. Upgrades can be applied directly by editing the etcd database.

Explanation:
The supported kubeadm upgrade process is to first upgrade the kubeadm tool itself and the control-plane node(s), and only afterward upgrade each worker node individually (typically draining it first), to avoid an unsupported skew between control-plane and node versions.
Why other options are incorrect:
A: Upgrading workers before the control plane risks running node components on a newer version than the control plane supports.
C: Nodes should be drained before their kubelet is upgraded to avoid disrupting running workloads.
D: etcd should never be edited directly to perform a version upgrade; kubeadm handles this safely.
Source: Upgrading kubeadm clusters

---

Which Kubernetes object type should be used to grant a specific user permission to read Pods within a single namespace, following the principle of least privilege?

⬜ A. ClusterRole bound with a ClusterRoleBinding
✅ B. Role bound with a RoleBinding
⬜ C. ServiceAccount only, with no Role
⬜ D. PodSecurityPolicy

Explanation:
A Role defines permissions scoped to a single namespace, and a RoleBinding grants those permissions to a user, group, or ServiceAccount within that namespace — the correct, least-privilege choice for namespace-scoped access like reading Pods in one namespace.
Why other options are incorrect:
A: A ClusterRole and ClusterRoleBinding grant permissions across the entire cluster (or reusable across namespaces), which is broader than needed here.
C: A ServiceAccount identifies a workload identity but grants no permissions by itself; it must still be bound to a Role or ClusterRole via RBAC.
D: PodSecurityPolicy (deprecated) controlled security-sensitive Pod fields, not general API access permissions.
Source: Using RBAC Authorization

---

An administrator needs to take a consistent backup of a kubeadm cluster’s cluster state so it can be restored later. Which component’s data must be backed up to fully recover cluster state?

⬜ A. Only the kubelet configuration files on each node.
✅ B. The etcd data store.
⬜ C. Only the container images cached on each node.
⬜ D. The local kubeconfig file on the administrator’s laptop.

Explanation:
etcd is the cluster’s key-value store that holds all cluster state (objects, configuration, and secrets). Taking a snapshot of etcd (for example, with etcdctl snapshot save) is what’s required to back up and later restore the full cluster state.
Why other options are incorrect:
A: kubelet configuration affects individual node behavior but does not contain cluster-wide state.
C: Cached container images can be re-pulled from a registry and are not the source of cluster state.
D: A kubeconfig file only stores client credentials and cluster connection details, not cluster state.
Source: Operating etcd clusters for Kubernetes

---

A Pod needs to run directly on a specific node and be managed by the kubelet on that node without going through the normal scheduler or API-server-managed Deployment mechanism (commonly used to run control-plane components like kube-apiserver in a kubeadm cluster). What kind of Pod is this?

⬜ A. A DaemonSet Pod
✅ B. A static Pod
⬜ C. A StatefulSet Pod
⬜ D. A Job Pod

Explanation:
A static Pod is managed directly by the kubelet on a specific node, defined by manifest files that the kubelet watches (commonly in /etc/kubernetes/manifests), rather than being scheduled by the API server — this is exactly how kubeadm runs control-plane components.
Why other options are incorrect:
A: A DaemonSet ensures a copy of a Pod runs on selected nodes but is still managed through the API server and scheduler.
C: A StatefulSet manages Pods with stable identities and storage, but is also API-server managed.
D: A Job runs Pods to completion for batch work and is also API-server managed.
Source: Static Pods

---

An administrator has multiple kubeconfig files for different clusters and wants to switch between them easily using a single kubectl command context. Which kubeconfig element should be used to switch between clusters and users?

✅ A. A context
⬜ B. A ServiceAccount token
⬜ C. A NetworkPolicy
⬜ D. A StorageClass

Explanation:
A context in a kubeconfig file bundles a cluster, a user (credentials), and optionally a default namespace together, so switching the current context with kubectl config use-context lets an administrator quickly switch between clusters and identities.
Why other options are incorrect:
B: A ServiceAccount token is a credential used for authentication, not the mechanism for switching between configured clusters.
C: A NetworkPolicy controls network traffic between Pods and has nothing to do with kubeconfig contexts.
D: A StorageClass defines how persistent storage is provisioned and is unrelated to kubeconfig.
Source: Organizing Cluster Access Using kubeconfig Files

---

Which statement about Kubernetes cluster component TLS certificates is correct?

⬜ A. Kubernetes cluster components never use TLS certificates; all communication is unencrypted by default.
✅ B. kubeadm automatically generates and manages the certificates required for control-plane components to communicate securely, and administrators can inspect their expiration with kubeadm certs check-expiration.
⬜ C. Certificates only need to be renewed once, at initial cluster creation, and never again.
⬜ D. Worker nodes do not require any certificates to join a cluster.

Explanation:
kubeadm automates generation of the PKI certificates that secure communication between control-plane components (API server, etcd, kubelet, and so on), and provides kubeadm certs check-expiration and kubeadm certs renew to help administrators manage certificate lifecycles.
Why other options are incorrect:
A: Kubernetes control-plane communication is secured with TLS by default, not unencrypted.
C: Certificates have expiration dates and must be periodically renewed, not just generated once.
D: Worker nodes require a valid client certificate (or bootstrap token) to authenticate and join the cluster securely.
Source: PKI certificates and requirements

---

An administrator needs to perform maintenance on a worker node and wants to safely evict all Pods from it while preventing new Pods from being scheduled there. Which command sequence is correct?

⬜ A. kubectl delete node, then kubectl create node
✅ B. kubectl cordon , then kubectl drain
⬜ C. kubectl taint only, with no cordon or drain
⬜ D. kubectl scale node –replicas=0

Explanation:
kubectl cordon <node> marks the node as unschedulable so no new Pods land on it, and kubectl drain <node> then safely evicts existing Pods (respecting PodDisruptionBudgets), which is the correct, safe workflow for node maintenance.
Why other options are incorrect:
A: Deleting and recreating a node object is disruptive and not the standard maintenance workflow.
C: A taint alone can influence scheduling but does not evict already-running Pods the way drain does.
D: There is no kubectl scale node command; scaling applies to workload controllers, not nodes.
Source: Safely Drain a Node

---

A platform team wants to extend the Kubernetes API with their own custom object type, such as a Database resource, that can be managed with standard kubectl commands. Which Kubernetes feature enables this?

⬜ A. A ConfigMap
✅ B. A Custom Resource Definition (CRD)
⬜ C. A NetworkPolicy
⬜ D. A ResourceQuota

Explanation:
A Custom Resource Definition (CRD) lets a platform team define a new, custom Kubernetes object type (a Custom Resource) that the API server will serve just like any built-in resource, enabling kubectl get/create/delete on it.
Why other options are incorrect:
A: A ConfigMap stores configuration data for existing workloads; it does not define new API object types.
C: A NetworkPolicy controls network traffic; it doesn’t extend the API with new resource types.
D: A ResourceQuota limits resource consumption in a namespace; it doesn’t define new resource types.
Source: Custom Resources

---

A company wants to package and deploy a complex application (with multiple Kubernetes manifests, configurable values, and versioned releases) more easily than applying raw YAML files individually. Which widely used CNCF tool is designed for this?

✅ A. Helm
⬜ B. etcdctl
⬜ C. kubeadm
⬜ D. crictl

Explanation:
Helm is the Kubernetes package manager: it lets teams define, install, version, and upgrade complex applications as reusable Charts with configurable values, rather than managing individual raw manifests.
Why other options are incorrect:
B: etcdctl is a command-line tool for interacting with etcd directly, not for packaging applications.
C: kubeadm bootstraps clusters; it doesn’t package or template application manifests.
D: crictl is a CLI for interacting with container runtimes (CRI), unrelated to application packaging.
Source: Charts

---

For high availability, a company is designing a kubeadm cluster’s control plane with multiple control-plane nodes. Which etcd topology co-locates etcd members on the same nodes as the control-plane components?

⬜ A. External etcd topology
✅ B. Stacked etcd topology
⬜ C. Single-node etcd topology
⬜ D. etcd is never required in a highly available cluster

Explanation:
In a stacked etcd topology, each control-plane node also runs its own etcd member locally, co-locating etcd with the control-plane components — simpler to set up than an external topology, though it couples etcd and control-plane node failures together.
Why other options are incorrect:
A: External etcd topology runs etcd on separate, dedicated nodes from the control-plane components, which is the opposite of stacked.
C: A single-node etcd setup isn’t a highly available topology and defeats the purpose of an HA design.
D: etcd is required to store all cluster state regardless of the HA topology chosen.
Source: Options for Highly Available Topology

---

Which statement about Kubernetes user authentication is correct?

⬜ A. Kubernetes has a built-in, mandatory user-management database for human users, similar to a traditional operating system.
✅ B. Kubernetes does not manage human user objects directly; instead it relies on external identity sources (such as client certificates, tokens, or an external identity provider) and authorizes requests via mechanisms like RBAC.
⬜ C. All users are automatically cluster administrators unless explicitly restricted.
⬜ D. ServiceAccounts and regular users are functionally identical with no differences in how they authenticate.

Explanation:
Kubernetes does not have its own user database for human users; authentication is delegated to external mechanisms (x509 client certificates, static tokens, OIDC providers, and so on), and RBAC is then used to authorize what an authenticated identity can do.
Why other options are incorrect:
A: There is no built-in Kubernetes user-management database analogous to an OS user directory.
C: Users are not administrators by default; permissions must be explicitly granted through RBAC.
D: ServiceAccounts are Kubernetes-managed identities for workloads with their own tokens, distinct from external human user authentication mechanisms.
Source: Authenticating

---

A team wants to ensure a fixed number of identical Pod replicas of a stateless web application are always running, with automatic rollout of new versions and the ability to roll back. Which Kubernetes object should they use?

✅ A. Deployment
⬜ B. DaemonSet
⬜ C. Job
⬜ D. Static Pod

Explanation:
A Deployment manages a ReplicaSet to keep a desired number of identical Pod replicas running, and natively supports rolling updates and rollbacks — exactly what’s needed for a stateless web application.
Why other options are incorrect:
B: A DaemonSet runs one Pod per (matching) node, which is for node-level agents, not a fixed replica count of a stateless app.
C: A Job runs Pods to completion for a finite task; it isn’t designed for continuously running services.
D: A static Pod is managed by a single node’s kubelet directly and doesn’t provide rollout/rollback features.
Source: Deployments

---

A company wants exactly one instance of a log-collection agent Pod running on every node in the cluster, including new nodes as they’re added. Which Kubernetes object is designed for this?

⬜ A. Deployment
✅ B. DaemonSet
⬜ C. StatefulSet
⬜ D. ReplicaSet

Explanation:
A DaemonSet ensures that a copy of a Pod runs on all (or a selected subset of) nodes, automatically adding Pods to new nodes as they join — the standard pattern for node-level agents like log collectors or monitoring agents.
Why other options are incorrect:
A: A Deployment manages a specified number of replicas, not necessarily one per node.
C: A StatefulSet provides stable identity and storage for stateful applications, not a one-per-node guarantee.
D: A ReplicaSet maintains a stable set of replica Pods but has no built-in one-per-node behavior; that’s the DaemonSet’s job.
Source: DaemonSet

---

A batch process needs to run a Pod to completion exactly once, and Kubernetes should retry it automatically if it fails. Which object should be used?

⬜ A. CronJob
✅ B. Job
⬜ C. ReplicaSet
⬜ D. DaemonSet

Explanation:
A Job creates one or more Pods and ensures a specified number of them successfully terminate, retrying failed Pods according to its configured policy — ideal for a run-to-completion batch task.
Why other options are incorrect:
A: A CronJob schedules Jobs to run on a recurring time-based schedule; it’s built for a task that runs once, not on a recurring cron schedule.
C: A ReplicaSet keeps Pods continuously running, which doesn’t match a run-to-completion batch task.
D: A DaemonSet runs continuously on every matching node, unrelated to a one-time batch task.
Source: Job

---

Which Kubernetes object should be used to run a data-cleanup task automatically every night at 2 AM?

⬜ A. Job
✅ B. CronJob
⬜ C. Deployment
⬜ D. ReplicaSet

Explanation:
A CronJob creates Jobs on a repeating schedule defined using standard cron syntax, making it the correct choice for a task that must run automatically at a specific recurring time, such as nightly at 2 AM.
Why other options are incorrect:
A: A Job runs once (or a fixed number of times) but has no built-in scheduling mechanism for recurrence.
C and D: Deployment and ReplicaSet are designed for continuously running workloads, not scheduled, run-to-completion tasks.
Source: CronJob

---

A Pod’s container needs access to a database password without hardcoding it in the container image or in a plain-text ConfigMap. Which Kubernetes object is designed to hold this kind of sensitive value?

⬜ A. ConfigMap
✅ B. Secret
⬜ C. PersistentVolumeClaim
⬜ D. ResourceQuota

Explanation:
A Secret is designed to hold sensitive data, such as passwords, tokens, or keys, and can be mounted into Pods as files or environment variables, keeping sensitive values out of container images and out of plain-text ConfigMaps.
Why other options are incorrect:
A: A ConfigMap is intended for non-sensitive configuration data, not secrets.
C: A PersistentVolumeClaim requests durable storage; it isn’t designed for small sensitive config values.
D: A ResourceQuota limits aggregate resource consumption in a namespace; it has nothing to do with storing secrets.
Source: Secrets

---

A team notices that one Pod is consuming so much CPU that it starves other Pods on the same node. Which Pod spec fields should be set to prevent a single container from exceeding a defined CPU ceiling?

⬜ A. requests.memory only
✅ B. limits.cpu (and limits.memory as needed)
⬜ C. affinity rules only
⬜ D. A NetworkPolicy

Explanation:
Setting resources.limits.cpu (and, typically, limits.memory) on a container caps the maximum CPU (and memory) it can consume, preventing it from starving other Pods on the same node; requests alone only affects scheduling, not the enforced ceiling.
Why other options are incorrect:
A: requests.memory influences scheduling decisions but does not cap actual usage.
C: Affinity rules influence which node a Pod is scheduled to, not how much CPU it can consume once running.
D: A NetworkPolicy controls network traffic, not compute resource consumption.
Source: Resource Management for Pods and Containers

---

A company wants Pods to be scheduled only on nodes that have GPUs, using a required (hard) scheduling rule based on node labels. Which mechanism should they use?

⬜ A. A taint applied to the Pod
✅ B. requiredDuringSchedulingIgnoredDuringExecution node affinity
⬜ C. A NetworkPolicy selector
⬜ D. A PersistentVolumeClaim selector

Explanation:
requiredDuringSchedulingIgnoredDuringExecution node affinity lets a Pod spec define a hard requirement that the Pod can only be scheduled onto nodes matching specific labels (such as a GPU label) — this is the correct mechanism for mandatory node-label-based placement.
Why other options are incorrect:
A: Taints are applied to nodes (not Pods) to repel Pods, and generally work together with tolerations on Pods, which is a different mechanism than affinity-based required placement.
C: NetworkPolicy selectors control network traffic between Pods, not scheduling placement.
D: A PersistentVolumeClaim selector matches a Pod’s storage claim to a PersistentVolume, not node placement.
Source: Assigning Pods to Nodes

---

A Pod needs a helper container to run and successfully complete a setup task (such as fetching configuration) BEFORE the main application container starts. Which Kubernetes feature is designed for this?

⬜ A. A sidecar container running continuously alongside the main container.
✅ B. An init container.
⬜ C. A second Deployment.
⬜ D. A DaemonSet.

Explanation:
Init containers run to completion, in order, before any main application containers in a Pod start, making them the correct tool for one-time setup tasks (like fetching configuration) that must finish before the application starts.
Why other options are incorrect:
A: A sidecar container runs continuously alongside the main container for the life of the Pod; it isn’t designed as a one-time, must-finish-first setup step.
C: A separate Deployment would create independently scheduled Pods, not a setup step within the same Pod.
D: A DaemonSet runs one Pod per node continuously; it doesn’t provide a pre-start setup step within a specific Pod.
Source: Init Containers

---

A company wants to expose a set of backend Pods to other Pods within the cluster only, using a stable internal IP address and DNS name, with no external access. Which Service type should they use?

✅ A. ClusterIP
⬜ B. NodePort
⬜ C. LoadBalancer
⬜ D. ExternalName

Explanation:
ClusterIP, the default Service type, exposes the Service on a stable, cluster-internal IP address and DNS name, making it reachable only from within the cluster — exactly what’s needed for internal-only Pod-to-Pod communication.
Why other options are incorrect:
B: NodePort exposes the Service externally on a static port on every node’s IP, which is more access than required here.
C: LoadBalancer provisions an external cloud load balancer, again exposing the Service externally.
D: ExternalName maps a Service to an external DNS name outside the cluster; it does not expose internal Pods at all.
Source: Service

---

A company needs to route external HTTP traffic to multiple backend Services based on the request’s hostname and URL path, using a single external entry point rather than provisioning a separate load balancer per Service. Which Kubernetes object is designed for this?

✅ A. Ingress
⬜ B. NetworkPolicy
⬜ C. Endpoints
⬜ D. PersistentVolume

Explanation:
An Ingress resource defines HTTP/HTTPS routing rules (based on host and path) to direct external traffic to different backend Services through a single entry point, managed by an Ingress controller — avoiding the need for one load balancer per Service.
Why other options are incorrect:
B: A NetworkPolicy controls which traffic is allowed between Pods; it does not perform HTTP host/path-based routing.
C: Endpoints track the actual Pod IPs backing a Service; they are not a routing configuration object.
D: A PersistentVolume provides storage and is unrelated to HTTP traffic routing.
Source: Ingress

---

By default, can Pods in a Kubernetes cluster communicate with any other Pod, across any namespace, without restriction?

⬜ A. No — Kubernetes blocks all Pod-to-Pod traffic by default until a NetworkPolicy explicitly allows it.
✅ B. Yes — by default, Kubernetes networking allows all Pods to communicate with all other Pods, unless a NetworkPolicy is used to restrict traffic.
⬜ C. Pods can only ever communicate within the same Deployment.
⬜ D. Pod-to-Pod communication requires manually configuring static routes for every Pod IP.

Explanation:
By default, Kubernetes networking is flat and permissive: any Pod can communicate with any other Pod across the cluster without restriction, unless a NetworkPolicy is created to explicitly restrict that traffic (and a CNI plugin that enforces NetworkPolicies is in use).
Why other options are incorrect:
A: This describes a ‘default deny’ behavior, which is not the Kubernetes default — traffic is allowed by default until restricted.
C: Pod-to-Pod communication is not limited to Pods within the same Deployment.
D: Kubernetes networking does not require manually configured static routes per Pod IP; the CNI plugin handles this automatically.
Source: Network Policies

---

A security team wants to restrict a set of backend Pods so that they only accept incoming traffic from Pods labeled role=frontend, and reject all other traffic. Which Kubernetes object should be used?

⬜ A. A ResourceQuota
✅ B. A NetworkPolicy with an ingress rule matching the role=frontend label selector
⬜ C. A Secret
⬜ D. A StorageClass

Explanation:
A NetworkPolicy can define ingress rules that allow traffic only from Pods matching a specific label selector (such as role=frontend), and — once any NetworkPolicy selects a Pod — all other traffic not explicitly allowed is denied, achieving the required restriction.
Why other options are incorrect:
A: A ResourceQuota limits resource consumption in a namespace; it has no effect on network traffic.
C: A Secret stores sensitive data; it doesn’t control network traffic between Pods.
D: A StorageClass defines how storage volumes are provisioned; it’s unrelated to network access control.
Source: Network Policies

---

Within a Kubernetes cluster using the default cluster DNS add-on, what is the standard DNS name format used to reach a Service named payments in namespace prod from another namespace?

⬜ A. payments.svc.cluster.local only
✅ B. payments.prod.svc.cluster.local
⬜ C. prod-payments.default.svc
⬜ D. payments://prod

Explanation:
Kubernetes cluster DNS resolves Services using the format <service-name>.<namespace>.svc.cluster.local (with cluster.local being the default cluster domain), so the payments Service in the prod namespace resolves as payments.prod.svc.cluster.local.
Why other options are incorrect:
A: This omits the namespace, which is required when accessing a Service from a different namespace.
C and D: These are not valid Kubernetes Service DNS name formats.
Source: DNS for Services and Pods

---

Which statement about the Container Network Interface (CNI) in Kubernetes is correct?

⬜ A. Kubernetes includes one single, built-in networking implementation with no plugin architecture.
✅ B. CNI is a plugin specification that allows different networking providers (such as Calico, Cilium, or Flannel) to implement Pod networking, and a cluster requires a CNI plugin to be installed for Pod-to-Pod networking to function.
⬜ C. CNI plugins are only used for Ingress traffic, not Pod-to-Pod communication.
⬜ D. CNI has been fully replaced by NetworkPolicy objects and is no longer required.

Explanation:
CNI (Container Network Interface) is a specification that lets Kubernetes support pluggable networking providers; a compatible CNI plugin (like Calico, Cilium, or Flannel) must be installed on a cluster for Pod networking to work, and some CNI plugins also enforce NetworkPolicy rules.
Why other options are incorrect:
A: Kubernetes deliberately delegates networking to pluggable CNI implementations rather than a single built-in one.
C: CNI plugins provide the fundamental Pod networking layer, not just Ingress traffic.
D: NetworkPolicy defines traffic rules but still relies on an underlying CNI plugin to enforce them; CNI itself is still required.
Source: Cluster Networking

---

A company wants to expose a Service on a static port on every node’s IP address so it can be reached from outside the cluster, without provisioning a cloud load balancer. Which Service type fits this requirement?

⬜ A. ClusterIP
✅ B. NodePort
⬜ C. ExternalName
⬜ D. Headless Service

Explanation:
A NodePort Service exposes the Service on a static port on every node’s IP address, allowing external access via <NodeIP>:<NodePort> without requiring a cloud load balancer.
Why other options are incorrect:
A: ClusterIP is only reachable from within the cluster.
C: ExternalName maps to an external DNS name and does not expose an internal Service via a node port.
D: A Headless Service (ClusterIP: None) is used for direct Pod DNS resolution (e.g., for StatefulSets), not for exposing a static per-node external port.
Source: Service

---

An application needs to discover the individual, stable network identities of each Pod backing a Service (rather than a single load-balanced virtual IP), such as for a clustered database. Which Service configuration supports this?

⬜ A. A LoadBalancer Service
✅ B. A Headless Service (ClusterIP set to None)
⬜ C. A NodePort Service
⬜ D. An Ingress resource

Explanation:
A Headless Service (created by setting clusterIP: None) does not allocate a single virtual IP; instead, DNS queries return the individual Pod IPs directly, which is the pattern used when clients need to discover and connect to specific Pods, such as members of a clustered database.
Why other options are incorrect:
A and C: LoadBalancer and NodePort still front the Service with a single virtual IP/port abstraction rather than exposing individual Pod identities.
D: Ingress routes HTTP(S) traffic to Services; it doesn’t provide direct per-Pod DNS discovery.
Source: Service

---

Which statement about how a Service finds the Pods it should route traffic to is correct?

⬜ A. A Service statically lists Pod IP addresses that never change.
✅ B. A Service uses a label selector to dynamically match Pods, and Kubernetes tracks matching Pod IPs (traditionally via an Endpoints object, or EndpointSlices for scalability).
⬜ C. A Service can only route to Pods within the exact same Deployment object.
⬜ D. A Service requires manual updates to its Pod IP list every time a Pod restarts.

Explanation:
A Service selects Pods dynamically using a label selector; Kubernetes automatically tracks the matching Pods’ IPs (historically via an Endpoints object, and via EndpointSlices for better scalability in larger clusters), updating them as Pods are created, restarted, or removed.
Why other options are incorrect:
A and D: Service-to-Pod mapping is dynamic and automatically maintained, not a static or manually updated IP list.
C: A Service’s label selector can match Pods from multiple sources (Deployments, ReplicaSets, or even standalone Pods), not only one specific Deployment.
Source: EndpointSlices

---

A platform team is evaluating the newer Kubernetes API for managing ingress traffic that offers more expressive, role-oriented routing configuration than the original Ingress resource. Which API are they most likely evaluating?

✅ A. The Gateway API
⬜ B. The PodDisruptionBudget API
⬜ C. The Horizontal Pod Autoscaler API
⬜ D. The Admission Webhook API

Explanation:
The Gateway API is the newer, more expressive Kubernetes networking API for modeling ingress and service-mesh-style traffic routing, designed with distinct roles (infrastructure provider, cluster operator, application developer) in mind, as a more flexible evolution beyond the original Ingress resource.
Why other options are incorrect:
B: PodDisruptionBudget limits voluntary disruptions to Pods; it is unrelated to ingress traffic routing.
C: The Horizontal Pod Autoscaler scales workloads based on metrics; it has nothing to do with ingress routing.
D: Admission webhooks intercept API requests for validation/mutation; they are unrelated to ingress traffic routing configuration.
Source: Gateway API

---

A cluster administrator has provisioned a piece of network storage as a cluster resource, and a developer wants their Pod to consume some of that storage without needing to know the underlying storage implementation details. Which two objects work together to achieve this?

⬜ A. ConfigMap and Secret
✅ B. PersistentVolume (PV) and PersistentVolumeClaim (PVC)
⬜ C. DaemonSet and StatefulSet
⬜ D. NetworkPolicy and Ingress

Explanation:
A PersistentVolume (PV) represents a piece of actual storage provisioned in the cluster (by an administrator or dynamically), and a PersistentVolumeClaim (PVC) is a developer’s request for storage that gets bound to a matching PV — abstracting the underlying storage details away from the Pod.
Why other options are incorrect:
A: ConfigMaps and Secrets store configuration/sensitive data, not durable block/file storage.
C: DaemonSet and StatefulSet are workload controllers, not storage abstraction objects.
D: NetworkPolicy and Ingress deal with network traffic, unrelated to storage provisioning.
Source: Persistent Volumes

---

A company wants PersistentVolumes to be automatically created on-demand whenever a developer submits a PersistentVolumeClaim, rather than requiring an administrator to manually pre-provision volumes. Which object enables this dynamic provisioning?

✅ A. A StorageClass
⬜ B. A ConfigMap
⬜ C. A ResourceQuota
⬜ D. A LimitRange

Explanation:
A StorageClass defines a provisioner and parameters for a class of storage; when a PVC references a StorageClass, the cluster can dynamically provision a matching PersistentVolume automatically, without requiring an administrator to pre-create it.
Why other options are incorrect:
B: A ConfigMap stores configuration data and has no role in storage provisioning.
C: A ResourceQuota limits aggregate resource consumption in a namespace, not storage provisioning behavior.
D: A LimitRange sets default/min/max resource constraints for objects in a namespace, not dynamic volume provisioning.
Source: Storage Classes

---

A Pod needs temporary scratch space that is shared between two containers in the same Pod, but the data does NOT need to survive if the Pod is deleted. Which volume type is MOST appropriate?

⬜ A. A PersistentVolumeClaim backed by network storage
✅ B. An emptyDir volume
⬜ C. A StorageClass
⬜ D. A hostPath volume pointing to a critical system directory

Explanation:
An emptyDir volume is created when a Pod is assigned to a node and exists only for the Pod’s lifetime, making it ideal for temporary scratch space shared between containers in the same Pod, with no requirement to persist beyond the Pod’s life.
Why other options are incorrect:
A: A PersistentVolumeClaim is meant for data that should persist beyond the Pod’s lifecycle, which is more than what’s needed here.
C: A StorageClass defines how volumes are provisioned; it isn’t itself a mountable volume type.
D: hostPath ties a Pod to a specific node’s filesystem and is generally discouraged for this use case, especially against critical system directories, due to portability and security risks.
Source: Volumes

---

Which PersistentVolume access mode allows the volume to be mounted as read-write by a single node at a time?

⬜ A. ReadWriteMany (RWX)
⬜ B. ReadOnlyMany (ROX)
✅ C. ReadWriteOnce (RWO)
⬜ D. ReadWriteOncePod (RWOP), which allows unlimited nodes

Explanation:
ReadWriteOnce (RWO) allows the volume to be mounted as read-write by a single node at a time, which is the most common access mode for block storage such as typical cloud block volumes.
Why other options are incorrect:
A: ReadWriteMany (RWX) allows read-write mounting by many nodes simultaneously, which is broader than RWO.
B: ReadOnlyMany (ROX) allows many nodes to mount the volume read-only, not read-write.
D: ReadWriteOncePod (RWOP) actually restricts read-write access to a single Pod (not unlimited nodes), which is even more restrictive than RWO, not less.
Source: Persistent Volumes: Access Modes

---

A storage vendor wants to provide a Kubernetes-compatible storage driver for their proprietary storage system without modifying Kubernetes’ own source code. Which standard interface should they implement?

⬜ A. The Container Network Interface (CNI)
✅ B. The Container Storage Interface (CSI)
⬜ C. The Container Runtime Interface (CRI)
⬜ D. The Custom Resource Definition (CRD) interface

Explanation:
The Container Storage Interface (CSI) is the standard that lets storage vendors implement drivers that plug into Kubernetes (and other container orchestrators) without needing changes to Kubernetes core code, enabling broad storage ecosystem support.
Why other options are incorrect:
A: CNI is the standard for pluggable networking, not storage.
C: CRI is the standard for pluggable container runtimes (like containerd or CRI-O), not storage.
D: A CRD lets you define new API object types; it is not the mechanism for implementing a storage driver.
Source: Volumes (CSI)

---

A Pod is stuck in Pending status and never gets scheduled. Which command should an administrator run FIRST to see the scheduling-related events explaining why?

⬜ A. kubectl logs
✅ B. kubectl describe pod
⬜ C. kubectl delete pod
⬜ D. kubectl top pod

Explanation:
kubectl describe pod <pod-name> shows the Pod’s recent Events, which for a Pending Pod typically reveal the scheduling failure reason (such as insufficient resources or no matching node), making it the right first diagnostic step.
Why other options are incorrect:
A: kubectl logs retrieves container logs, but a Pending Pod has no running container yet to produce logs.
C: Deleting the Pod does not diagnose the problem and may just recreate the same issue.
D: kubectl top pod shows resource usage of running Pods; it won’t work for a Pod that was never scheduled.
Source: Debug Running Pods

---

A Pod’s container keeps restarting repeatedly and kubectl get pods shows its status as CrashLoopBackOff. Which command is MOST useful to see why the container is crashing, including logs from its previous run before the restart?

✅ A. kubectl logs –previous
⬜ B. kubectl get nodes
⬜ C. kubectl cordon
⬜ D. kubectl scale deployment –replicas=0

Explanation:
kubectl logs <pod-name> --previous retrieves logs from the previous (crashed) instance of the container, which is exactly what’s needed to diagnose why a container in CrashLoopBackOff keeps failing.
Why other options are incorrect:
B: kubectl get nodes shows node status, not the failing container’s own logs.
C: Cordoning a node prevents new scheduling there but doesn’t diagnose an application crash.
D: Scaling the Deployment to zero replicas would stop the Pods entirely rather than helping diagnose the crash.
Source: Debug Running Pods

---

An administrator suspects that the kube-scheduler static Pod on the control-plane node has failed to start. Where should they look to find the relevant static Pod manifest and container logs on that node?

⬜ A. Inside a ConfigMap named kube-scheduler-config.
✅ B. The static Pod manifests directory (commonly /etc/kubernetes/manifests) and the container runtime/kubelet logs on that node.
⬜ C. Only inside the etcd database.
⬜ D. In the developer’s local kubeconfig file.

Explanation:
Control-plane components like kube-scheduler typically run as static Pods defined by manifest files in a directory the kubelet watches (commonly /etc/kubernetes/manifests), so checking that manifest and the container runtime/kubelet logs on the node is the correct troubleshooting path for a failed control-plane static Pod.
Why other options are incorrect:
A: There’s no requirement for scheduler configuration to live in a ConfigMap by that name; static Pod control-plane components are defined by manifest files, not ConfigMaps, by default.
C: etcd stores cluster state/objects, not the static Pod manifest files or container logs directly.
D: A local kubeconfig only holds client credentials/connection info, not server-side component logs.
Source: Troubleshooting Clusters

---

kubectl get componentstatuses (or checking control-plane health) shows the kube-controller-manager appears unhealthy on a kubeadm cluster. What is a reasonable next troubleshooting step?

⬜ A. Immediately reinstall the entire operating system on the node.
✅ B. Check the kube-controller-manager static Pod’s status and logs on the control-plane node (e.g., with kubectl -n kube-system describe pod and container runtime logs).
⬜ C. Delete all Pods in all namespaces.
⬜ D. Ignore it since the controller-manager is optional for cluster function.

Explanation:
The correct approach is to inspect the specific failing static Pod for the affected control-plane component — checking its status, recent events, and logs — to identify the root cause before taking any drastic action.
Why other options are incorrect:
A: Reinstalling the OS is an extreme, disruptive step that isn’t a standard first troubleshooting action.
C: Deleting all Pods cluster-wide is unrelated and highly disruptive.
D: The controller-manager is a core control-plane component responsible for reconciliation loops (like ReplicaSet scaling); it is not optional.
Source: Troubleshooting Clusters

---

Users report that a web application’s Service is unreachable, even though its backend Pods show as Running. Which of the following is a valid troubleshooting step to isolate whether the issue is with the Service’s Pod selection?

✅ A. Check that the Service’s label selector actually matches the labels on the backend Pods, and verify the resulting Endpoints/EndpointSlices are populated.
⬜ B. Immediately delete the Service and recreate the Deployment from scratch.
⬜ C. Increase the CPU limit on the backend Pods.
⬜ D. Change the container image tag to latest.

Explanation:
A common root cause of an unreachable Service despite healthy Pods is a label selector mismatch. Checking that the Service’s selector matches the Pods’ labels, and confirming the Endpoints/EndpointSlices list the expected Pod IPs, directly isolates this class of problem.
Why other options are incorrect:
B: Deleting and recreating objects is disruptive and skips proper diagnosis.
C: CPU limits are unrelated to Service-to-Pod connectivity issues.
D: Changing the image tag addresses application code/version, not Service selector or networking issues.
Source: Debug Services

---

An administrator wants to view real-time CPU and memory usage of all Pods in a namespace to identify which one is consuming excessive resources. Which command and supporting component are required?

✅ A. kubectl top pods, which requires the Metrics Server to be installed in the cluster.
⬜ B. kubectl get events, with no additional components required.
⬜ C. kubectl describe node, which always shows live Pod-level CPU/memory usage.
⬜ D. kubectl logs, which shows historical CPU/memory graphs.

Explanation:
kubectl top pods displays real-time CPU and memory usage, but it depends on the Metrics Server (or a compatible metrics pipeline) being installed and running in the cluster; without it, kubectl top commands fail.
Why other options are incorrect:
B: kubectl get events shows cluster events, not resource usage metrics.
C: kubectl describe node shows allocatable/requested resources and conditions, but not live per-Pod usage without the metrics pipeline.
D: kubectl logs shows container log output, not CPU/memory usage graphs.
Source: Resource metrics pipeline

---

A worker node shows a NotReady status in kubectl get nodes. Which of the following is the MOST relevant next troubleshooting step?

✅ A. Check the kubelet’s status and logs on that node (e.g., systemctl status kubelet and journal logs), since kubelet health directly determines node readiness.
⬜ B. Delete the node object and assume it will self-heal with no other action.
⬜ C. Edit the ClusterRoleBinding for the default ServiceAccount.
⬜ D. Increase the replica count of unrelated Deployments in a different namespace.

Explanation:
Node Ready status is reported by the kubelet based on its own health and its ability to communicate with the control plane, so checking the kubelet’s service status and logs on that node is the most direct and relevant troubleshooting step for a NotReady node.
Why other options are incorrect:
B: Deleting the node object doesn’t fix an underlying kubelet or node-level problem and isn’t a diagnostic step.
C: RBAC bindings control API authorization, unrelated to node readiness.
D: Scaling unrelated Deployments has no bearing on a specific node’s readiness.
Source: Monitor Node Health

---

A Pod remains stuck in ContainerCreating for a long time. kubectl describe pod shows an event about failing to pull the container image. Which of these is a plausible root cause to investigate?

✅ A. The container image tag doesn’t exist, or the node lacks correct registry credentials/network access to pull it.
⬜ B. The Kubernetes API server has crashed and is not restartable.
⬜ C. The cluster’s etcd database has been corrupted beyond repair.
⬜ D. The Horizontal Pod Autoscaler was misconfigured.

Explanation:
An ImagePullBackOff/failed image pull event most commonly points to an incorrect image name/tag, a private registry requiring credentials the node doesn’t have, or a network/DNS issue preventing the node from reaching the registry — all worth checking directly.
Why other options are incorrect:
B: If the API server had crashed, kubectl describe itself likely wouldn’t return results at all; this doesn’t match the described symptom.
C: An etcd corruption issue would typically manifest as much broader cluster-wide API failures, not a single Pod’s image pull error.
D: HPA misconfiguration affects scaling decisions, not the ability to pull a specific container image.
Source: Debug Running Pods

---

An application inside a Pod cannot resolve other Services by their DNS names, though the Pod itself is Running. Which of the following is a reasonable early troubleshooting step?

✅ A. Verify the Pod’s /etc/resolv.conf points to the cluster DNS service, and confirm the cluster DNS add-on (e.g., CoreDNS) Pods are running and healthy.
⬜ B. Increase the Pod’s memory limit.
⬜ C. Restart the kube-scheduler only.
⬜ D. Apply a new StorageClass.

Explanation:
DNS resolution failures inside a Pod are commonly diagnosed by checking that the Pod’s resolv.conf correctly points to the cluster DNS service and by confirming the cluster DNS add-on (commonly CoreDNS) Pods are healthy and responding — both are the standard first checks.
Why other options are incorrect:
B: Memory limits are unrelated to DNS name resolution.
C: The scheduler places Pods on nodes; it has no role in DNS resolution.
D: A StorageClass configures storage provisioning and is unrelated to DNS.
Source: DNS for Services and Pods

---

Which command shows the recent lifecycle events for a specific object (such as a Pod, Deployment, or Node), which is often the fastest way to understand what went wrong?

⬜ A. kubectl apply -f
✅ B. kubectl describe
⬜ C. kubectl config view
⬜ D. kubectl api-resources

Explanation:
kubectl describe <resource> <name> includes an Events section showing recent lifecycle events (scheduling decisions, pulls, failures, and so on) for that specific object, making it one of the fastest ways to understand what’s going wrong.
Why other options are incorrect:
A: kubectl apply creates/updates resources; it doesn’t display diagnostic event history.
C: kubectl config view shows kubeconfig contents, unrelated to object-level troubleshooting.
D: kubectl api-resources lists available API resource types, not diagnostic events for a specific object.
Source: kubectl describe reference

---

A company wants application container logs to be collected and made durably available even after Pods are deleted or rescheduled, across the whole cluster. Which Kubernetes-native approach directly provides this out of the box?

⬜ A. Kubernetes provides this automatically with no additional setup required.
✅ B. Kubernetes itself does not provide durable, cluster-wide log aggregation out of the box; a cluster-level logging architecture (e.g., a node-level logging agent shipping logs to a backend) must be deployed.
⬜ C. Only kubectl logs is needed, and it retains logs indefinitely by default.
⬜ D. PersistentVolumes automatically capture and store all container stdout/stderr.

Explanation:
Kubernetes itself only retains container logs locally (via the container runtime) for the life of the container/Pod. For durable, cluster-wide log retention, a cluster-level logging architecture — such as a node-level agent that ships logs to a backend store — must be deployed separately.
Why other options are incorrect:
A and C: Kubernetes does not automatically provide durable, indefinite log retention without additional logging infrastructure.
D: PersistentVolumes provide durable storage for application data explicitly written to them; they do not automatically capture container stdout/stderr.
Source: Logging Architecture

---

An administrator wants to check whether the kube-apiserver itself is reachable and responding, as a first step when kubectl commands are timing out entirely. Which of these is a reasonable diagnostic action?

✅ A. Check network connectivity to the API server’s endpoint/port and review the API server’s static Pod status and logs on the control-plane node.
⬜ B. Immediately restore the entire cluster from an old etcd snapshot without further investigation.
⬜ C. Delete and recreate all worker nodes.
⬜ D. Assume the issue is always with a single application Pod and check only that Pod’s logs.

Explanation:
When kubectl itself cannot reach the cluster, the API server is the first thing to check: verifying network connectivity to its endpoint and reviewing its static Pod status/logs on the control-plane node isolates whether the control plane itself is the problem.
Why other options are incorrect:
B: Restoring from an etcd snapshot is a drastic, data-losing action that should only follow proper diagnosis, not be the first response.
C: Recreating worker nodes doesn’t address a control-plane/API-server reachability problem.
D: If kubectl itself can’t connect, the issue is unlikely to be a single application Pod’s logs, which wouldn’t even be reachable via kubectl in that state.
Source: Troubleshooting Clusters

---

A Pod has been running for a while, but the application inside seems to be serving errors, though the Pod’s status shows Running with 1/1 containers ready. What Kubernetes probe would help automatically detect and restart a container in this exact scenario going forward?

⬜ A. A startup probe only
✅ B. A liveness probe configured to check the application’s actual health
⬜ C. A resource limit with no probes
⬜ D. A NetworkPolicy

Explanation:
A liveness probe periodically checks whether the application inside a container is actually healthy (not just that the process is running); if configured correctly, Kubernetes will restart a container whose liveness probe fails, addressing this class of ‘running but broken’ scenario going forward.
Why other options are incorrect:
A: A startup probe is used to know when a slow-starting application has finished initializing; it doesn’t continuously monitor ongoing health.
C: Resource limits control compute consumption but don’t detect or react to an application-level health failure.
D: A NetworkPolicy manages traffic rules, not container health detection.
Source: Pod Lifecycle

---

An administrator wants a general reference for the recommended, systematic workflow to troubleshoot a failing application running in Kubernetes, from checking the Pod status down to container-level issues. Which official resource documents this?

✅ A. The Kubernetes ‘Troubleshooting Applications’ task documentation.
⬜ B. The Kubernetes release notes.
⬜ C. The etcd API reference.
⬜ D. The kubeadm command-line reference only.

Explanation:
The official ‘Troubleshooting Applications’ documentation under kubernetes.io provides a systematic, step-by-step reference for diagnosing failing applications, covering Pod status, container logs, and related checks.
Why other options are incorrect:
B: Release notes describe changes between Kubernetes versions, not a troubleshooting workflow.
C: The etcd API reference documents etcd’s own API, not application troubleshooting steps.
D: The kubeadm CLI reference documents kubeadm subcommands, not a general application-troubleshooting workflow.
Source: Troubleshoot Applications

---

A container keeps getting terminated with an OOMKilled status shown in kubectl describe pod. What does this status indicate, and what is a reasonable remediation?

✅ A. It indicates the container ran out of allocated memory and was killed by the kernel; consider increasing the container’s memory limit or investigating a memory leak in the application.
⬜ B. It indicates the container’s image failed to pull.
⬜ C. It indicates a DNS resolution failure inside the container.
⬜ D. It indicates the node has been cordoned by an administrator.

Explanation:
OOMKilled means the container exceeded its allowed memory (its resources.limits.memory, or the node ran out of memory) and was terminated by the kernel’s out-of-memory killer; remediation typically involves right-sizing the memory limit or investigating and fixing a memory leak in the application.
Why other options are incorrect:
B: An image pull failure would show as ImagePullBackOff or similar, not OOMKilled.
C: DNS failures show up as resolution errors within the application, not as an OOMKilled container status.
D: Cordoning a node affects scheduling of new Pods; it does not cause a running container to be OOMKilled.
Source: Resource Management for Pods and Containers