KCNA Kubernetes Fundamentals Practice Test 23 — 15 Questions

Question 1

Which component runs on every node and is responsible for maintaining network rules that allow communication to Pods from network endpoints?

Accepted Answer

kube-proxy. B is correct because kube-proxy is the component that runs on every node in a Kubernetes cluster and is responsible for maintaining network rules (e.g., iptables, IPVS, or userspace proxy) that allow network communication to Pods from network endpoints, both inside and outside the cluster. It implements the Kubernetes Service concept by managing the mapping of Service IPs to backend Pod IPs and performing load balancing.

Answer

kube-controller-manager

Answer

container runtime

Answer

kubelet

Question 2

A pod is in 'Pending' state for a long time. What is the most likely cause?

Accepted Answer

The scheduler cannot find a node that satisfies the pod's resource requests or constraints. A pod remains in 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is that the scheduler cannot find a node that meets the pod's resource requests (CPU/memory) or constraints (node selectors, affinity rules, taints/tolerations). Until a suitable node is found, the pod stays in Pending, waiting for scheduling.

Answer

The pod's container has crashed

Answer

The pod's service endpoint is misconfigured

Answer

The container image is invalid

Question 3

You have two pods in different namespaces that need to communicate using a stable IP address. Which Kubernetes object provides a stable endpoint for a set of pods?

Accepted Answer

Service. A Kubernetes Service provides a stable IP address and DNS name that remains constant regardless of pod restarts or rescheduling, enabling reliable communication between pods in different namespaces. Unlike pods, which have ephemeral IPs, a Service selects a set of pods via label selectors and load-balances traffic to them, ensuring a stable endpoint across namespace boundaries.

Answer

ConfigMap

Answer

Ingress

Answer

Deployment

Question 4

Which Kubernetes object is used to logically isolate resources within a cluster, such as for separating environments like dev and prod?

Accepted Answer

Namespace. D is correct because a Namespace is the Kubernetes object designed to logically isolate resources within a single cluster. By creating separate Namespaces for environments like dev and prod, you can apply distinct policies, quotas, and access controls without needing multiple physical clusters.

Answer

ClusterRole

Answer

ResourceQuota

Answer

Node

Question 5

Your application requires persistent storage that must be available across pod restarts and rescheduling. What is the recommended approach?

Accepted Answer

Use a PersistentVolumeClaim (PVC) and mount it into the pod. PersistentVolumeClaim (PVC) is the recommended approach because it decouples storage provisioning from pod lifecycle, ensuring data persists across pod restarts and rescheduling. PVCs request storage from a PersistentVolume (PV) that is backed by a physical storage system (e.g., NFS, cloud block storage), and the pod mounts this volume, allowing the data to survive even if the pod is deleted and recreated on a different node.

Answer

Store data in the container's writable layer

Answer

Use hostPath volume

Answer

Use an emptyDir volume

Question 6

A Deployment is configured with 'replicas: 5' and a rolling update strategy. During an update, you notice that the number of available pods drops to 3 momentarily. Which field in the Deployment spec can be adjusted to control the minimum number of pods available during a rolling update?

Accepted Answer

spec.strategy.rollingUpdate.maxUnavailable. `spec.strategy.rollingUpdate.maxUnavailable` defines the maximum number (or percentage) of Pods that can be unavailable during a rolling update. With `replicas: 5`, setting `maxUnavailable: 2` would allow at most 2 Pods to be unavailable at any time, ensuring that at least 3 Pods remain available — which matches the observed drop to 3. This field directly controls the minimum number of available Pods during the update process.

Answer

spec.strategy.rollingUpdate.maxSurge

Answer

spec.minReadySeconds

Answer

spec.replicas

Question 7

A Service of type ClusterIP is not resolving DNS names for pods. The pods are running and can communicate with each other via IP addresses. Which component should be checked first?

Accepted Answer

CoreDNS pods in the kube-system namespace. DNS name resolution for Services in Kubernetes is handled by CoreDNS, which runs as pods in the kube-system namespace. When a ClusterIP Service fails to resolve DNS names but pods can communicate via IP addresses, the issue is almost certainly with the DNS resolver itself, not with network connectivity or Service endpoints. CoreDNS must be checked first to ensure it is running, has correct configuration, and can query the Kubernetes API for Service records.

Answer

The kubelet on the node where the pod is running

Answer

The Service's endpoint slices

Answer

kube-proxy on the nodes

Question 8

Which TWO of the following are responsibilities of the kube-controller-manager?

Accepted Answer

Ensuring the correct number of pod replicas are running. Option B is correct because the kube-controller-manager runs the ReplicationController/ReplicaSet controller, which continuously reconciles the desired replica count in a workload's spec with the actual number of running pods, creating or deleting pods as needed. Option D is correct because the kube-controller-manager includes the node controller, which monitors node heartbeats/status and reacts to node failures by marking nodes NotReady and evicting or rescheduling their pods (subject to tolerations). Option A is not a kube-controller-manager responsibility; pod-to-node assignment is performed by the kube-scheduler. Option C is not correct because Service network rules are implemented by the kube-proxy component (and/or CNI/iptables/IPVS), not the kube-controller-manager. Option E is not correct because cluster state is stored in etcd, the distributed key-value store, not by the kube-controller-manager.

Answer

Assigning pods to nodes based on resource requirements

Answer

Implementing network rules for Services

Answer

Storing the cluster state

Question 9

Which THREE of the following are true about Kubernetes labels and selectors?

Accepted Answer

Set-based selectors support operators like 'In' and 'NotIn'. Option B is correct because set-based selectors support operators such as In, NotIn, Exists, and DoesNotExist, allowing matching against a set of values rather than a single equality. Option C is correct because a Service uses its selector to match pod labels and route traffic only to the pods whose labels satisfy that selector. Option E is correct because labels are key/value pairs attached to objects specifically so users can organize and select subsets of objects, for example with kubectl get pods -l app=web. Option A is not correct because labels are ordinary metadata and are not encrypted at rest by default; encryption at rest applies to etcd data only if configured. Option D is not correct because labels are mutable and can be added, updated, or removed after object creation.

Answer

Labels are encrypted at rest by default

Answer

Labels are immutable after creation

Question 10

Which TWO of the following are characteristics of a Kubernetes Pod?

Accepted Answer

Pods are the smallest deployable units in Kubernetes. Option B is correct because the Pod is the smallest and most basic deployable object in Kubernetes — you cannot deploy a container directly; it must be wrapped in a Pod, which represents a single instance of a running process in the cluster. Option C is correct because all containers in a Pod share the same network namespace, meaning they share one IP address and port space and can communicate with each other via localhost, and they can also share storage volumes. Option A is incorrect because a Pod can run one or multiple containers (e.g., sidecar, ambassador, or adapter patterns), not only a single container. Option D is incorrect because Pods are ephemeral by design — they are not intended to be long-lived; they are created, terminated, and replaced rather than repaired in place. Option E is incorrect as a defining characteristic of a Pod itself: replication is performed by higher-level controllers such as Deployments or ReplicaSets, which manage Pods but are not properties of the Pod object.

Answer

Pods can only run a single container

Answer

Pods are designed to be long-lived and rarely replaced

Answer

Pods are typically replicated by a Deployment or ReplicaSet

Question 11

Which control plane component is responsible for assigning pods to nodes?

Accepted Answer

kube-scheduler. The kube-scheduler is the control plane component responsible for assigning pods to nodes. It watches for newly created pods that have no node assignment and selects an optimal node for each pod based on resource requirements, constraints, policies, and data locality. The scheduler does not actually run the pod; it updates the pod's `nodeName` field via the API server, which then triggers the kubelet on the chosen node to launch the pod.

Answer

etcd

Answer

kube-apiserver

Answer

kube-controller-manager

Question 12

A developer deploys a pod with the following resource specification:
```yaml
resources:
  requests:
    memory: "256Mi"
  limits:
    memory: "512Mi"
```
The pod is killed with OOMKilled. What is the most likely cause?

Accepted Answer

The container exceeded the memory limit of 512Mi. The OOMKilled exit code indicates the container was terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it attempted to use more memory than its configured limit of 512Mi. Kubernetes enforces memory limits using cgroups; when the container exceeds the limit, the kernel kills the process, resulting in the OOMKilled status.

Answer

The container exceeded the memory request of 256Mi

Answer

The node ran out of memory

Answer

The CPU limit was too low

Question 13

A Deployment is created with `replicas: 3`. After applying the manifest, only 2 pods are running and one is in Pending state. What is the most likely reason?

Accepted Answer

There are insufficient resources on the nodes. When a Pod remains in Pending state, it means the scheduler cannot find a node that satisfies the Pod's resource requirements (CPU, memory, or other constraints). Since two Pods are running successfully, the Deployment configuration (image, name, selector) is valid, and the issue is that the cluster lacks sufficient capacity to schedule the third replica. The scheduler continuously evaluates node resources and will leave the Pod pending until resources become available or the request is adjusted.

Answer

The Service selector does not match

Answer

The Deployment name is misspelled

Answer

The container image is invalid

Question 14

An application requires that configuration data be mounted as a file inside the container. The data may change at runtime, and the application should automatically read the updated values without restarting. Which approach should be used?

Accepted Answer

Use a ConfigMap mounted as a volume without subPath. Mounting a ConfigMap as a volume (without subPath) creates a symlink-based mount that automatically updates when the ConfigMap changes. The kubelet periodically syncs the ConfigMap data and updates the symlinks, allowing the application to read the new values without a restart. This satisfies the requirement for runtime configuration updates without container restart.

Answer

Store the configuration in a Secret and mount it using subPath

Answer

Use a PersistentVolumeClaim to store the configuration

Answer

Store the configuration in an environment variable from a ConfigMap

Question 15

Which of the following is NOT a responsibility of the kubelet on a worker node?

Accepted Answer

Implementing network rules for Services. The kubelet is the primary node agent that runs on each worker node, responsible for ensuring containers are running in a Pod as specified by the PodSpec. It performs liveness and readiness probes, starts and stops containers, and reports node and pod status to the control plane. Implementing network rules for Services, such as iptables or IPVS rules, is the responsibility of the kube-proxy, not the kubelet.

Answer

Performing liveness and readiness probes

Answer

Starting and stopping containers based on PodSpecs

Answer

Reporting node and pod status to the control plane