KCNA Kubernetes Fundamentals Practice Test 34 — 15 Questions

Question 1

A developer wants to run a one-time batch job that processes a dataset and then exits. The job must complete successfully and not be restarted after completion. Which Kubernetes resource should be used?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Job. Job is the correct resource for batch workloads that run to completion. It ensures that a specified number of pods finish successfully and then stops creating new ones. CronJob is for scheduled recurring tasks, while Deployment and StatefulSet are for long-running services that restart on exit. Thus, Job best fits the one-time batch processing requirement.

Answer

Deployment

Answer

StatefulSet

Answer

CronJob

Question 2

An application Pod in the `web` namespace must read a configuration value stored in a ConfigMap named `app-config` without restarting when the value changes. The value is consumed as a file inside the container. Which approach meets this requirement?

Accepted Answer

Mount the ConfigMap as a volume and let the application re-read the file periodically.. Volume-mounted ConfigMaps are periodically refreshed by the kubelet, so an application that re-reads its configuration file can pick up new values without a restart. Environment-variable injection and subPath mounts do not update at runtime, and immutable ConfigMaps cannot change at all, so the volume-mount approach is the only one that satisfies the scenario.

Answer

Use a subPath volume mount of the ConfigMap key.

Answer

Set the ConfigMap as an immutable object and mount it as a volume.

Answer

Reference the ConfigMap with envFrom and rely on automatic environment refresh.

Question 3

A cluster administrator needs to ensure that a logging agent runs on every node in the cluster, including nodes added in the future. The agent should collect logs from each node and forward them to a central system. Which Kubernetes resource should be used?

Accepted Answer

DaemonSet. DaemonSet is specifically designed to run a pod on each node, automatically handling new nodes as they join. This makes it the correct choice for node-level agents like log collectors. Deployments, StatefulSets, and Jobs do not provide this per-node guarantee; they manage replicas or batch tasks without ensuring coverage of every node.

Answer

Job

Answer

Deployment

Answer

StatefulSet

Question 4

A developer runs `kubectl apply -f pod.yaml` against a cluster running Kubernetes v1.29. The Pod manifest sets `spec.restartPolicy: Always` and `spec.containers[0].name: app`. The Pod starts successfully but the developer wants to change the container image from `nginx:1.24` to `nginx:1.25`. They edit the YAML file and re-run `kubectl apply -f pod.yaml`. What is the result?

Accepted Answer

The apply fails with an error indicating that the Pod spec is invalid or cannot be updated.. Pods have a largely immutable spec once created. Changing the container image via `kubectl apply` is rejected by the API server with an immutable-field error. The intended workflow for image updates is to use a controller such as a Deployment, which creates a new ReplicaSet and new Pods. For a bare Pod, you must delete it and recreate it with the new image.

Answer

The apply succeeds but the change is silently ignored because Pods are managed by the kubelet.

Answer

The existing Pod is patched in place and the container image is updated without restarting the Pod.

Answer

The Pod is deleted and recreated with the new image because Pods are immutable.

Question 5

A developer inspects a Pod and sees that it is stuck in the Pending phase. Which two conditions can legitimately cause a Pod to remain Pending? (Choose two.)

Accepted Answer

The Pod requests a PersistentVolumeClaim that is not yet bound and uses a storage class with WaitForFirstConsumer.. A Pod stays Pending whenever the scheduler cannot place it or its volumes are not ready. Unsatisfiable resource requests, affinity rules, or taints block scheduling, and a WaitForFirstConsumer PersistentVolumeClaim deliberately delays binding until a node is chosen. Image pull errors, failed liveness probes, and token expiry all occur after scheduling and therefore do not cause the Pending phase.

Answer

The Pod's container image cannot be pulled from the registry.

Answer

The Pod's liveness probe is failing repeatedly.

Answer

The Pod's ServiceAccount token has expired.

Question 6

A developer needs to inject configuration data into a pod as environment variables and also mount a configuration file into a volume. The data should be decoupled from the pod specification and easily updatable without rebuilding the container image. Which Kubernetes resource should be used?

Accepted Answer

ConfigMap. ConfigMap is the standard Kubernetes resource for storing non-sensitive configuration data. It can be consumed as environment variables or mounted as files, and it separates configuration from pod definitions, allowing updates without image rebuilds. Secret is for sensitive data, Downward API for metadata, and PersistentVolumeClaim for storage, so ConfigMap is the correct answer.

Answer

Secret

Answer

PersistentVolumeClaim

Answer

Downward API

Question 7

An administrator is troubleshooting a cluster and runs `kubectl get pods -n kube-system`. They see a Pod named `kube-apiserver-controlplane` running on the control plane node. Which statement best describes the role of this component?

Accepted Answer

It stores and serves the cluster's API, acting as the front end for all control plane communication.. The kube-apiserver is the central control plane component that exposes the Kubernetes API and is the sole client of etcd. It authenticates, authorizes, validates, and persists requests, and all other components interact with the cluster through it. Scheduling, container runtime management, and controller reconciliation are handled by separate components, not by the API server.

Answer

It schedules Pods onto nodes by evaluating resource requests and node affinity.

Answer

It watches for changes to desired state and reconciles them by creating or deleting Pods.

Answer

It runs the container runtime and manages the lifecycle of containers on each node.

Question 8

A platform engineer runs `kubectl get pods -n web` and sees a pod stuck in the `Pending` phase. The pod's `nodeName` field is empty, and no events about image pulling appear. Which Kubernetes component is most directly responsible for assigning this pod to a node?

Accepted Answer

kube-scheduler. A pod enters the Pending phase when it has been accepted by the API server but not yet bound to a node. The kube-scheduler continuously watches for such pods and selects a node that satisfies resource requests, affinity, taints, and tolerations. Once it binds the pod, the kubelet on that node takes over and starts the containers, moving the pod toward Running.

Answer

kubelet

Answer

kube-controller-manager

Answer

kube-proxy

Question 9

A team runs a stateless web application as a Deployment with 4 replicas. They want each replica to be reachable through a single stable virtual IP inside the cluster, and they want the traffic distributed across all healthy replicas. They have already created a Service of type ClusterIP with the correct selector. A new engineer asks what backend object the Service actually targets. What does the Service select?

Accepted Answer

The individual Pods whose labels match the Service selector, tracked via EndpointSlices.. A Service with a selector targets Pods, not Deployments or ReplicaSets. The endpoints controller watches for Pods matching the selector and populates EndpointSlice objects with their IPs and readiness state. kube-proxy then programs load-balancing rules to send traffic to those Pod IPs. This decoupling is why Services remain stable even as Pods are replaced.

Answer

The Deployment object itself, because the Service selector matches the Deployment's labels.

Answer

The ReplicaSet created by the Deployment, because it owns the Pods.

Answer

The nodes running the Pods, using each node's kubelet port as the backend.

Question 10

A platform team needs to ensure that a critical StatefulSet pod always runs on a specific node that has local NVMe storage. The node is labeled `disktype=nvme`. Which Kubernetes scheduling mechanism should they use to guarantee this placement?

Accepted Answer

nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution. The requirement is a guaranteed placement on a node with a specific label. nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution enforces a hard rule that the pod must be scheduled on a node matching the label selector. This is the standard, declarative way to pin pods to nodes based on labels, and it works well with StatefulSets. Other options either provide only soft preferences, do not attract pods, or bypass the scheduler in a non-idiomatic way.

Answer

Taints and tolerations on the node

Answer

nodeName field in the Pod spec

Answer

podAffinity with preferredDuringSchedulingIgnoredDuringExecution

Question 11

A cluster administrator needs to run a node-level logging agent on every node, including nodes added later. The agent must collect logs from the host filesystem and must run even if a node is cordoned. Which workload resource should be used?

Accepted Answer

A DaemonSet. DaemonSets are purpose-built for per-node workloads. The DaemonSet controller creates a pod on each eligible node and adds new pods when nodes join the cluster. Its default tolerations allow the pods to run on nodes that are unschedulable or carry common taints, which is essential for infrastructure agents like log shippers, monitoring exporters, and CNI plugins that must operate everywhere.

Answer

A StatefulSet with one replica per node

Answer

A Job with a parallelism equal to the number of nodes

Answer

A Deployment with a nodeSelector matching each node's label

Question 12

A platform engineer is designing a multi-tenant cluster. They want to ensure that a specific team's workloads can only be scheduled onto nodes labeled `team=blue`, and that workloads from other teams cannot be scheduled there. The team's Pods should not run on any other nodes. Which combination of Kubernetes features should the engineer use to enforce this?

Accepted Answer

nodeSelector on the Pods plus taints and tolerations on the nodes.. Dedicated node pools are implemented by combining attraction and repulsion. nodeSelector or nodeAffinity pulls the team's Pods toward nodes labeled team=blue, while a taint on those nodes, paired with a toleration on the Pods, keeps other workloads away. Neither feature alone provides full isolation: nodeSelector without a taint lets others share the node, and a taint without nodeSelector lets the team's Pods land elsewhere.

Answer

NetworkPolicy applied to the team's namespace with a node selector.

Answer

Pod affinity rules alone, using requiredDuringSchedulingIgnoredDuringExecution.

Answer

ResourceQuota and LimitRange applied to the team's namespace.

Question 13

A developer creates a Deployment with 3 replicas. After a few seconds, they run `kubectl get deployments` and see `READY 2/3`. They want to quickly identify why one replica is not ready. Which command should they use to inspect the status of the individual Pods?

Accepted Answer

kubectl get pods -l app=myapp -o wide. To quickly identify which Pod is not ready, listing Pods with the Deployment's label selector and wide output shows each Pod's status and node. This provides an immediate view of which replica is failing and basic context. Describing the Deployment or fetching logs from the Deployment does not show per-Pod readiness. Filtering events by the Deployment name misses Pod-level events. The correct approach is to query the Pods directly.

Answer

kubectl describe deployment myapp

Answer

kubectl get events --field-selector involvedObject.name=myapp

Answer

kubectl logs deployment/myapp

Question 14

An administrator is configuring a NetworkPolicy to allow ingress traffic to Pods with label `role=db` only from Pods with label `role=api` on TCP port 6379. The NetworkPolicy is applied in the same namespace as the Pods. Which NetworkPolicy YAML correctly implements this requirement?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api
    ports:
    - protocol: TCP
      port: 6379. The correct NetworkPolicy selects the target Pods (role=db) and defines an ingress rule that allows traffic from Pods labeled role=api on TCP port 6379. It uses a podSelector within the from clause to match the source Pods. Since both sets of Pods are in the same namespace, no namespaceSelector is required. The other options either allow too much traffic, reverse the roles, or add unnecessary egress restrictions that could disrupt other traffic.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - podSelector:
        matchLabels:
          role: api
    ports:
    - protocol: TCP
      port: 6379

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {}
    ports:
    - protocol: TCP
      port: 6379

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
spec:
  podSelector:
    matchLabels:
      role: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: db
    ports:
    - protocol: TCP
      port: 6379

Question 15

A developer wants to run a batch job that processes a large dataset. The job should run to completion, and if the Pod fails, it should be retried up to 4 times before being marked as failed. Which Kubernetes resource and configuration should be used?

Accepted Answer

A Job with backoffLimit set to 4 and restartPolicy set to OnFailure. The requirement is a run-to-completion workload with limited retries. A Job is the correct resource, and backoffLimit specifies the number of retries before marking the Job as failed. Setting restartPolicy to OnFailure allows the container to restart within the Pod on failure, which is necessary for retries to occur. Deployments and bare Pods do not provide completion semantics, and CronJobs are for scheduled tasks, not immediate one-time jobs.

Answer

A Deployment with replicas set to 5 and restartPolicy set to Always

Answer

A CronJob with schedule set to a future time and backoffLimit set to 4

Answer

A Pod with restartPolicy set to Never and no controller