KCNA Kubernetes Fundamentals Practice Test 31 — 15 Questions

Question 1

A developer creates a Pod with a volume of type emptyDir. The Pod writes data to the volume and then is deleted. What happens to the data?

Accepted Answer

The data is permanently deleted when the Pod is removed.. An emptyDir volume is ephemeral and scoped to the Pod. When the Pod is deleted, the volume is removed from the node, and its data is lost. To retain data beyond the Pod's lifetime, you must use a PersistentVolumeClaim backed by durable storage. This behavior is fundamental for understanding stateless versus stateful workloads.

Answer

The data remains in the container's filesystem layer and can be recovered by restarting the container.

Answer

The data persists on the node and can be reused by a new Pod if the same emptyDir name is used.

Answer

The data is automatically backed up to a PersistentVolume before deletion.

Question 2

A developer runs `kubectl create configmap app-config --from-literal=LOG_LEVEL=debug` and then creates a Pod that references this ConfigMap as a volume. After the ConfigMap is updated with `kubectl edit configmap app-config` to change LOG_LEVEL to info, the application inside the running Pod still reads LOG_LEVEL=debug. What is the most likely reason?

Accepted Answer

ConfigMap volumes are updated automatically, but the application must be designed to reload the file; the kubelet sync period may cause a delay.. The key fact is that volume-mounted ConfigMaps are eventually updated on disk by the kubelet, but the application must detect and reload the change. Environment variables from ConfigMaps are fixed at container start. The observed stale value is therefore explained by the application not reloading the file, possibly combined with the kubelet sync interval. This is a common operational nuance.

Answer

ConfigMaps mounted as volumes are immutable after Pod creation; the Pod must be deleted and recreated to pick up changes.

Answer

The ConfigMap was created in a different namespace than the Pod, so the volume mount silently falls back to the original literal value.

Answer

Environment variables sourced from ConfigMaps are updated live, but volume-mounted ConfigMaps are cached indefinitely by the container runtime.

Question 3

A platform engineer needs to run a one-time batch job that processes a dataset and then exits. The job must run exactly once and not be restarted if it completes successfully. Which Kubernetes resource should be used?

Accepted Answer

Job. A Job is the correct resource for run-to-completion workloads. It creates Pods that are expected to terminate successfully, and it does not restart them after successful completion. Deployments, CronJobs, and DaemonSets are designed for different use cases: long-running services, scheduled tasks, and node-level agents, respectively.

Answer

DaemonSet

Answer

CronJob

Answer

Deployment

Question 4

A platform engineer applies a Pod manifest that includes the field `spec.nodeName: k8s-worker-07`. The scheduler is running normally. What is the most accurate description of what happens to this Pod?

Accepted Answer

The Pod is placed on k8s-worker-07 without kube-scheduler involvement, and the kubelet there attempts to run it regardless of taints or resource fit.. Populating spec.nodeName directly is the classic manual-scheduling pattern: kube-scheduler only considers Pods with an empty nodeName, so a Pod that already names a node skips the entire scheduling framework, including taint and affinity checks. The kubelet on the named node then takes over, and any resource or taint mismatch surfaces as a kubelet-level failure rather than a Pending Pod event.

Answer

The API server rejects the manifest because nodeName cannot be set by users; it is only written by kube-scheduler.

Answer

The kube-scheduler evaluates node affinity and taints before binding the Pod to k8s-worker-07.

Answer

The Pod is bound directly to k8s-worker-07 by the kubelet on that node, skipping the scheduler's binding step.

Question 5

An administrator needs to grant a ServiceAccount in namespace 'dev' permission to list and watch Pods in the same namespace. Which combination of resources is required?

Accepted Answer

A Role and a RoleBinding in the 'dev' namespace. To grant a ServiceAccount permission to list and watch Pods in a single namespace, you create a Role in that namespace with the appropriate rules and bind it to the ServiceAccount using a RoleBinding. This follows the principle of least privilege, as the permissions are confined to the 'dev' namespace and do not extend cluster-wide.

Answer

A ClusterRole and a RoleBinding in the 'dev' namespace

Answer

A ClusterRole and a ClusterRoleBinding

Answer

A Role and a ClusterRoleBinding

Question 6

A platform team wants to run a batch job that must complete successfully exactly once per day on a schedule. They need Kubernetes to create a Job object automatically at the specified times, and they want to keep a history of the last three successful and one failed Job for debugging. Which resource should they create?

Accepted Answer

A CronJob with a schedule, successfulJobsHistoryLimit: 3, and failedJobsHistoryLimit: 1.. The requirement is a scheduled, one-off task with retention of past runs. A CronJob is the only resource that natively creates Jobs on a cron schedule and exposes history limits for successful and failed Jobs. The Job it creates handles completion and retries. Other workload controllers either run continuously or lack scheduling and history features, so they cannot fulfill the scenario.

Answer

A Job with a cron schedule annotation and a restartPolicy of OnFailure.

Answer

A DaemonSet that runs a Pod on every node and executes the batch script once per day.

Answer

A StatefulSet with an initContainer that sleeps until the next scheduled time.

Question 7

An operations team wants a workload that runs exactly one Pod on every node in the cluster, including nodes added later, typically for log forwarding and node monitoring. Which Kubernetes workload resource is designed for this?

Accepted Answer

DaemonSet. A DaemonSet ensures one Pod per eligible node and extends coverage automatically as nodes join, which matches the requirement for log forwarding and node monitoring. Unlike replica-count workloads, it is node-centric rather than count-centric, and it honors taints, tolerations, and node selectors to decide which nodes receive the agent Pod.

Answer

StatefulSet

Answer

Job

Answer

Deployment

Question 8

A developer wants to store non-confidential configuration data as key-value pairs that can be consumed by Pods as environment variables or mounted files. Which Kubernetes resource is designed for this purpose?

Accepted Answer

ConfigMap. ConfigMaps are the standard Kubernetes resource for managing non-confidential configuration data. They allow you to decouple configuration artifacts from image content, and Pods can consume them as environment variables or mounted files. Secrets are for sensitive data, while Volumes and PersistentVolumeClaims are storage abstractions, not configuration stores.

Answer

PersistentVolumeClaim

Answer

Volume

Answer

Secret

Question 9

A developer runs `kubectl get pods` and notices that one Pod is stuck in the `Pending` state. The Pod's resource requests are modest, and the node has sufficient CPU and memory. Which of the following is the MOST likely reason the Pod is not being scheduled?

Accepted Answer

The Pod has a nodeSelector that does not match any node's labels.. The scheduler assigns Pods to nodes based on resource requests, node selectors, affinity rules, and taints/tolerations. When a Pod remains Pending despite adequate resources, a nodeSelector mismatch is a common cause. The scheduler cannot find a node that satisfies the label constraint, so it leaves the Pod unscheduled until a suitable node becomes available or the selector is corrected.

Answer

The Pod's service account does not exist.

Answer

The Pod's container image is not available in the registry.

Answer

The Pod's liveness probe is failing.

Question 10

An administrator runs `kubectl taint nodes node1 dedicated=gpu:NoSchedule` and then creates a Pod with the toleration `key: dedicated, operator: Equal, value: gpu, effect: NoSchedule`. The Pod is scheduled onto node1, but the administrator expected the taint to repel all Pods without a matching toleration. Which statement explains why the Pod was still placed on node1?

Accepted Answer

The toleration matches the taint, so the scheduler is allowed to place the Pod on node1; taints repel only Pods that do not tolerate them.. Taints and tolerations work as a pair: a taint repels Pods that lack a matching toleration, but a Pod that tolerates the taint is allowed onto the node. Because the Pod's toleration matched the taint's key, value, and effect, the scheduler correctly placed it on node1. The administrator's mental model omitted the effect of the toleration, which is the intended escape hatch.

Answer

The taint effect `NoSchedule` only applies to Pods created in the kube-system namespace, so user Pods are unaffected.

Answer

Taints are only enforced during eviction, not during initial scheduling, so any Pod can land on a tainted node.

Answer

The toleration must use `operator: Exists` to match a taint with a value; `operator: Equal` never matches when a value is present.

Question 11

You are reviewing the manifest for a Pod that must only run on nodes with the label `disktype=ssd`. The manifest includes the following snippet:

```yaml
nodeSelector:
  disktype: ssd
```

After applying the manifest, the Pod remains in Pending state indefinitely. `kubectl get nodes --show-labels` shows no node has the `disktype=ssd` label. Which action will allow the Pod to be scheduled without modifying the Pod's nodeSelector?

Accepted Answer

Add the label `disktype=ssd` to at least one node using `kubectl label nodes <node-name> disktype=ssd`.. A Pod with nodeSelector only lands on nodes whose labels match every specified key-value pair. Because no node currently has `disktype=ssd`, the scheduler cannot find a feasible node and the Pod stays Pending. Labeling an appropriate node with that exact pair makes it feasible, allowing scheduling without altering the Pod manifest. The other actions either use the wrong metadata type or change the Pod spec.

Answer

Add an annotation `disktype=ssd` to a node with `kubectl annotate nodes <node-name> disktype=ssd`.

Answer

Edit the Pod's nodeSelector to an empty map so it matches any node, then reapply the manifest.

Answer

Create a taint on a node with `kubectl taint nodes <node-name> disktype=ssd:NoSchedule` so the scheduler treats it as matching.

Question 12

A team is deciding how to isolate workloads across namespaces. Which two statements about Kubernetes Namespaces are accurate? (Choose two.)

Accepted Answer

Deleting a Namespace triggers deletion of the resources it contains, and the Namespace stays in Terminating until finalizers complete.. Namespace deletion is finalizer-gated and removes contained resources, and ResourceQuota plus LimitRange are the namespaced mechanisms for aggregate caps and per-container defaults. The other statements misstate Kubernetes Namespaces as network isolation, kernel isolation, or a container for cluster-scoped objects, none of which reflects how the API partitions resources.

Answer

Namespaces provide kernel-level isolation between Pods, equivalent to Linux namespaces used by containers.

Answer

A NetworkPolicy that selects all Pods in a namespace automatically blocks traffic from other namespaces without additional rules.

Answer

Cluster-scoped resources such as Nodes and PersistentVolumes can be created inside any namespace for organizational clarity.

Question 13

A developer needs to store non-confidential configuration data, such as a database hostname and port, that can be consumed by multiple Pods in a namespace. The data should be decoupled from the Pod specification to allow updates without rebuilding images. Which Kubernetes resource is designed for this purpose?

Accepted Answer

ConfigMap. ConfigMaps are the standard Kubernetes resource for storing non-confidential configuration data. They allow you to separate configuration from container images, making applications more portable and easier to manage. Pods can reference ConfigMaps as environment variables, command-line arguments, or files in a volume. This enables dynamic updates to configuration without redeploying Pods, depending on how the ConfigMap is consumed.

Answer

ServiceAccount

Answer

PersistentVolumeClaim

Answer

Secret

Question 14

A cluster administrator wants to restrict which nodes a Pod can be scheduled on based on node labels, while also allowing the scheduler to prefer certain nodes but still run elsewhere if needed. Which combination of features should be used?

Accepted Answer

Use `nodeSelector` for a hard requirement and `nodeAffinity` with `preferredDuringSchedulingIgnoredDuringExecution` for soft preferences.. The scenario requires a hard constraint on node labels and a soft preference that still permits scheduling elsewhere. `nodeSelector` enforces the hard label match, while `nodeAffinity` with a preferred rule provides weighted preferences without preventing scheduling. Other mechanisms either constrain by Pod labels, repulse rather than prefer, or focus on spreading, so they do not satisfy both parts of the requirement.

Answer

Use `topologySpreadConstraints` with `whenUnsatisfiable: DoNotSchedule` to spread Pods across labeled nodes.

Answer

Use `taints` on the nodes and `tolerations` on the Pod to define which nodes are preferred.

Answer

Use `podAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` to pin the Pod to nodes with specific labels.

Question 15

A team wants a single stable IP address and DNS name that load-balances traffic across a changing set of backend Pods. The Pods are managed by a Deployment and are regularly replaced during rollouts. Which Kubernetes object should they create to provide this stable virtual IP and DNS entry?

Accepted Answer

A Service of type ClusterIP. A Service abstracts a set of Pods behind a stable virtual IP and DNS name, and its label selector keeps the backend list current as Pods come and go. ClusterIP is the default type and is ideal for internal access. Ingress, NetworkPolicy, and ConfigMap serve routing, security, and configuration purposes respectively, and none of them supplies a stable virtual IP for a dynamic Pod set.

Answer

A NetworkPolicy

Answer

A ConfigMap

Answer

An Ingress resource