KCNA Practice Test 31 — 15 Questions

Question 1

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?

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

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 2

An administrator runs 'kubectl get pods' and sees that a pod named 'app-pod' is in 'CrashLoopBackOff'. They run 'kubectl logs app-pod' and see a segmentation fault error. What is the most likely cause?

Accepted Answer

The application code has a bug. A segmentation fault (segfault) is a specific error caused by a program attempting to access memory it does not have permission to access, typically due to a bug in the application code (e.g., null pointer dereference, buffer overflow). Since the container starts but then crashes repeatedly (CrashLoopBackOff), the segfault indicates the application itself is failing, not the infrastructure or configuration. This is the most direct cause of the pod entering CrashLoopBackOff.

Answer

The node is out of memory

Answer

The container has a configuration error

Answer

The readiness probe is misconfigured

Question 3

Which THREE are valid container runtimes that implement the Kubernetes CRI? (Choose three.)

Accepted Answer

Docker (via dockershim, deprecated). Docker (via dockershim) is correct because Kubernetes historically shipped an in-tree CRI adapter called dockershim that translated CRI calls to the Docker Engine API, allowing Docker to serve as a container runtime until its deprecation in v1.24. containerd is correct because it natively implements the CRI plugin (cri plugin enabled by default), making it a first-class Kubernetes container runtime. CRI-O is correct because it was purpose-built as a lightweight CRI implementation for Kubernetes using OCI-compliant runtimes like runc. runc is not a CRI implementation; it is a low-level OCI runtime invoked by higher-level runtimes such as containerd and CRI-O to actually create containers. rkt is not a CRI runtime; it was an alternative container engine that was deprecated and never implemented the Kubernetes CRI.

Answer

runc

Answer

rkt

Question 4

Which two of the following are container runtimes that implement the Container Runtime Interface (CRI)? (Choose two.)

Accepted Answer

containerd. containerd is a core container runtime that implements the Container Runtime Interface (CRI), which is the Kubernetes API for integrating container runtimes. It was originally extracted from Docker and is now a graduated CNCF project, providing a stable CRI-compatible interface for managing container lifecycles.

Answer

Docker

Answer

Podman

Answer

runc

Question 5

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 6

What is the primary purpose of the Kubernetes control plane component 'kube-apiserver'?

Accepted Answer

Expose the Kubernetes REST API and act as the entry point for all administrative tasks. The kube-apiserver is the front-end of the Kubernetes control plane, exposing the Kubernetes REST API. It validates and processes all administrative requests (e.g., creating pods, scaling deployments) and is the only component that directly interacts with the etcd datastore. This makes it the central entry point for all cluster management tasks, aligning with option D. Other options are incorrect: A describes the kubelet, B describes the kube-scheduler, and C describes etcd.

Answer

Run container runtime operations on nodes

Answer

Schedule pods onto nodes

Answer

Store cluster state and configuration

Question 7

Which THREE of the following are valid ways to pass configuration data to a container in a pod? (Select 3)

Accepted Answer

Setting environment variables directly in the pod spec. Option C is correct because the pod spec allows you to define environment variables directly under the container's env field, which Kubernetes injects into the container process at startup. Option D is correct because a ConfigMap can be mounted as a volume, making its key-value pairs available as files inside the container's filesystem. Option E is correct because a Secret can be exposed as an environment variable using env or envFrom with valueFrom.secretKeyRef or secretRef, delivering sensitive configuration data to the container. Option A is not a valid runtime configuration method because container images are immutable after deployment and cannot be modified in place. Option B is not a configuration-passing mechanism; a PersistentVolumeClaim provides persistent storage, not structured configuration data.

Answer

Modifying the container image after deployment

Answer

Using a PersistentVolumeClaim to store configuration

Question 8

You need to deploy a batch job that processes a queue and runs to completion. The job should run exactly once and create exactly one pod per work item, but some items may fail. Which Kubernetes resource is best suited?

Accepted Answer

Job. A Kubernetes Job is the correct resource for batch processing tasks that run to completion, such as processing a queue where each work item corresponds to a pod. By configuring the `.spec.completions` and `.spec.parallelism` fields, you can ensure exactly one pod per work item and control concurrency. The Job automatically retries failed pods (up to a configurable limit) without restarting the entire batch, making it ideal for handling some failures. In contrast, a Deployment (A) is for long-running, continuously available services; a CronJob (C) is for scheduled recurring jobs; and a DaemonSet (D) runs a pod on every node for infrastructure tasks. Therefore, Job (B) is the best fit.

Answer

Deployment

Answer

CronJob

Answer

DaemonSet

Question 9

You have a Deployment running 3 replicas. You need to update the container image without downtime. Which command updates the image while performing a rolling update?

Accepted Answer

kubectl set image deployment/my-deployment nginx=nginx:1.25. `kubectl set image` triggers a rolling update on the Deployment, updating the container image gradually without downtime. Kubernetes automatically manages the rollout by creating new Pods with the new image and terminating old ones, ensuring the desired replica count is maintained throughout the process.

Answer

kubectl replace deployment my-deployment --image=nginx:1.25

Answer

kubectl scale deployment my-deployment --image=nginx:1.25

Answer

kubectl update deployment my-deployment --image=nginx:1.25

Question 10

You have a web application that needs to read configuration from a file and also access a database password. Which combination of resources should you use to manage these configurations securely?

Accepted Answer

Use ConfigMap for configuration file and Secret for database password. ConfigMap is designed for storing non-confidential configuration data like configuration files, while Secret is specifically for sensitive data such as database passwords. Secrets are base64-encoded and can be encrypted at rest using etcd encryption or KMS, providing a security boundary that ConfigMaps lack. This combination follows Kubernetes best practices for separating configuration from secrets.

Answer

Use ConfigMap for both

Answer

Use PersistentVolume for configuration and environment variables for the password

Answer

Use Secret for both

Question 11

A cloud-native application uses a service mesh (Istio) for traffic management. The team notices increased latency in inter-service communication. Which likely cause should be investigated first?

Accepted Answer

Misconfigured sidecar proxy settings. In Istio, the sidecar proxy (Envoy) intercepts all inbound and outbound traffic for the application container. Misconfigured proxy settings—such as incorrect timeouts, retry policies, or circuit breaker thresholds—can introduce significant latency by causing unnecessary retries, connection delays, or queueing. This is the most common and immediate cause of increased latency in a service mesh, as the data plane is directly in the request path.

Answer

Kubernetes Network Policies blocking traffic

Answer

Application code is not optimized for the mesh

Answer

mTLS encryption overhead

Question 12

What is the purpose of a readiness probe in a Kubernetes pod?

Accepted Answer

To signal that the pod is ready to accept traffic. A readiness probe in Kubernetes determines whether a container inside a pod is ready to start accepting traffic. If the probe fails, the pod is removed from the Service's endpoints, ensuring that only healthy pods receive requests. This is distinct from liveness probes, which check if the container is alive and should be restarted.

Answer

To determine if the pod should be terminated

Answer

To check if the pod is alive and restart it if not

Answer

To measure CPU usage of the container

Question 13

Which Prometheus metric type is best suited to count the number of HTTP requests received?

Accepted Answer

Counter. A Counter is a Prometheus metric type that represents a cumulative value that only increases (or resets to zero on restart). It is the correct choice for counting total HTTP requests received because the value monotonically increases over time. PromQL's rate() and increase() functions are designed to work with counters to compute per-second rates.

Answer

Gauge

Answer

Histogram

Answer

Summary

Question 14

Which component of the Kubernetes control plane is responsible for persisting the cluster state?

Accepted Answer

etcd. etcd is the distributed key-value store that acts as the single source of truth for the entire Kubernetes cluster. It stores all cluster state data, including configuration, secrets, and the desired state of every object, ensuring consistency and durability. The kube-apiserver is the only component that directly interacts with etcd, enforcing a strict serialization of writes to prevent corruption.

Answer

kube-scheduler

Answer

kube-controller-manager

Answer

kube-apiserver

Question 15

Which TWO of the following are benefits of using a Deployment over managing ReplicaSets directly? (Choose two.)

Accepted Answer

Declarative scaling. Option B (Declarative scaling) is correct because a Deployment declares the desired replica count in its spec (spec.replicas), and the Deployment controller continuously reconciles the actual number of pods to match that declared state, so scaling is expressed declaratively rather than by manually editing a ReplicaSet. Option D (Automatic rolling updates and rollbacks) is correct because Deployments manage ReplicaSets under the hood to perform rolling updates via spec.strategy (RollingUpdate with maxSurge/maxUnavailable) and preserve revision history (spec.revisionHistoryLimit) so that kubectl rollout undo can roll back to a previous ReplicaSet. Option A is incorrect because stateful workloads requiring stable identities and persistent per-pod storage are handled by StatefulSets, not Deployments. Option C is incorrect because pod IP addresses are a function of the cluster network (e.g., CNI-assigned IPs) and are not a Deployment-specific benefit; direct pod access is generally discouraged in favor of Services. Option E is incorrect because running one pod on every node is the purpose of a DaemonSet, not a Deployment.

Answer

Support for stateful workloads

Answer

Direct access to pod IP addresses

Answer

Ability to run a pod on every node