KCNA Kubernetes Fundamentals Practice Test 22 — 15 Questions

Question 1

You want to run a batch job that processes data and then terminates. Which Kubernetes resource is best suited for this workload?

Accepted Answer

Job. A Kubernetes Job is designed for batch processing workloads that run to completion and then terminate. Unlike controllers that maintain a desired number of running Pods (like Deployments or StatefulSets), a Job creates one or more Pods and ensures they successfully exit. Once the specified number of successful completions is reached, the Job stops, making it the ideal choice for a one-time data processing task.

Answer

StatefulSet

Answer

DaemonSet

Answer

Deployment

Question 2

You have a Service named 'my-svc' in namespace 'default'. A pod in namespace 'other' tries to reach it using the DNS name 'my-svc'. What is the correct DNS name for cross-namespace service discovery?

Accepted Answer

my-svc.default. Kubernetes DNS resolves service names using the format `..svc.cluster.local`. For cross-namespace access, the namespace must be included. Since the pod is in namespace 'other' and the service is in 'default', the correct DNS name is 'my-svc.default' (the full cluster domain suffix is optional).

Answer

my-svc

Answer

my-svc.other

Answer

my-svc.namespace

Question 3

Which TWO of the following are valid ways to expose a set of pods to traffic from outside the Kubernetes cluster?

Accepted Answer

Service of type NodePort. A Service of type NodePort exposes the service on a static port on each node's IP address. Traffic sent to that port on any cluster node is forwarded to the underlying service, making it accessible from outside the cluster without requiring a cloud load balancer.

Answer

Ingress

Answer

Service of type ExternalName

Answer

Service of type ClusterIP

Question 4

Which TWO of the following are valid Kubernetes resource types that can be used to store configuration data or secrets?

Accepted Answer

Secret. ConfigMaps and Secrets are the only dedicated Kubernetes resource types for storing configuration data and secrets, respectively. ConfigMaps store non-sensitive data as key-value pairs, while Secrets store sensitive data (base64-encoded). Other options like Volume, PersistentVolumeClaim, and ServiceAccount are not designed for this purpose.

Answer

Volume

Answer

PersistentVolumeClaim

Answer

ServiceAccount

Question 5

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

Accepted Answer

Managing endpoint objects for Services. The kube-controller-manager runs controllers that handle routine tasks. The Node controller watches the health of nodes. The Endpoint controller (now EndpointSlice controller) manages endpoints for Services. Assigning pods to nodes is done by the scheduler. Storing cluster state is done by etcd. Serving the Kubernetes API is done by kube-apiserver.

Answer

Assigning pods to nodes

Answer

Storing cluster state

Answer

Serving the Kubernetes API

Question 6

Which Kubernetes component is responsible for storing the cluster state?

Accepted Answer

etcd. etcd is a distributed, consistent key-value store used by Kubernetes to store all cluster data, including configuration, state, and metadata. It is the single source of truth for the cluster; without etcd, the cluster cannot maintain or recover its state. The kube-apiserver is the only component that communicates directly with etcd, but it is etcd itself that physically stores the data.

Answer

kube-scheduler

Answer

kube-apiserver

Answer

kube-controller-manager

Question 7

What is the smallest deployable unit in Kubernetes?

Accepted Answer

Pod. The Pod is the smallest deployable unit in Kubernetes because it represents a single instance of a running process in the cluster and encapsulates one or more containers with shared storage and network resources. While containers are the runtime units, Kubernetes schedules and manages Pods, not individual containers, making the Pod the atomic building block for deployment.

Answer

Deployment

Answer

Container

Answer

Node

Question 8

A developer creates a Deployment with 3 replicas. The developer runs 'kubectl get pods' immediately after creation and sees that only 1 pod is in Running state, and the other 2 are Pending. What is the most likely reason for this?

Accepted Answer

The cluster does not have enough resources (CPU/memory) to schedule the additional pods. When a Pod remains in Pending state, it indicates that the scheduler cannot find a suitable node to place it. The most common cause is insufficient cluster resources (CPU or memory) to accommodate the additional Pods, as the scheduler checks node allocatable resources against Pod resource requests. With 2 out of 3 Pods pending, the cluster likely has enough resources for only one replica, leaving the others unscheduled.

Answer

The Deployment's YAML has a syntax error

Answer

The container image is not available on the worker nodes

Answer

The kubelet on the node is not running

Question 9

A team runs a stateless web application in Kubernetes. They have a Deployment named 'web-app' with 5 replicas. They want to ensure that a Service named 'web-svc' distributes traffic evenly to all healthy pods. Which type of Service should they use?

Accepted Answer

ClusterIP. A ClusterIP Service is the correct choice because it provides a stable virtual IP address and round-robin load balancing across healthy pods in the Deployment. By default, kube-proxy uses iptables or IPVS rules to distribute traffic evenly to all ready pod endpoints, ensuring stateless web application requests are balanced without requiring external exposure.

Answer

Headless Service

Answer

ExternalName Service

Answer

NodePort

Question 10

An administrator wants to update the image of a Deployment named 'my-app' from 'nginx:1.19' to 'nginx:1.20' with a rolling update strategy. They want to ensure that during the update, the number of unavailable pods never exceeds 1. Which field should they set in the Deployment spec?

Accepted Answer

spec.strategy.rollingUpdate.maxUnavailable. `spec.strategy.rollingUpdate.maxUnavailable` controls the maximum number of Pods that can be unavailable during a rolling update. Setting this to 1 ensures that at most one Pod is unavailable at any time, meeting the administrator's requirement. This field is part of the Deployment's rolling update strategy and directly governs the availability guarantee during the update process.

Answer

spec.replicas

Answer

spec.minReadySeconds

Answer

spec.strategy.rollingUpdate.maxSurge

Question 11

A pod named 'db' in the 'default' namespace cannot connect to another pod named 'cache' in the 'prod' namespace via DNS. The service 'cache-svc' exists in the 'prod' namespace. What DNS name should the 'db' pod use to reach the 'cache-svc' service?

Accepted Answer

cache-svc.prod.svc.cluster.local. Kubernetes DNS resolves services across namespaces using the format ..svc.cluster.local. Since the 'cache-svc' service is in the 'prod' namespace, the 'db' pod in the 'default' namespace must use 'cache-svc.prod.svc.cluster.local' to reach it. The default cluster domain is 'cluster.local', and the 'svc' subdomain is part of the standard DNS schema for services.

Answer

cache-svc.default

Answer

cache-svc.prod

Answer

cache-svc.default.svc.cluster.local

Question 12

A DevOps engineer has created a ConfigMap named 'app-config' with some configuration data. They want to make that data available as environment variables in a pod. Which field in the pod spec should they use to achieve this?

Accepted Answer

spec.containers[].envFrom. The `envFrom` field in the container spec allows you to inject all key-value pairs from a ConfigMap (or Secret) as environment variables into the container. This is the most direct and efficient way to expose ConfigMap data as environment variables without needing to specify each key individually.

Answer

spec.volumes

Answer

spec.containers[].volumeMounts

Answer

spec.containers[].env

Question 13

A cluster administrator wants to ensure that a specific pod only runs on nodes that have an SSD for local storage. The nodes with SSDs have the label 'disk-type: ssd'. How should the administrator configure the pod to enforce this constraint?

Accepted Answer

Add a nodeSelector with 'disk-type: ssd' to the pod spec. The `nodeSelector` field in a Pod spec is the standard Kubernetes mechanism for constraining a Pod to run only on nodes that match specific labels. By setting `nodeSelector: { disk-type: ssd }`, the scheduler will ensure the Pod is placed exclusively on nodes with that label, enforcing the administrator's requirement.

Answer

Add a toleration for node.kubernetes.io/disk-type: ssd

Answer

Use a readiness probe to check for SSD

Answer

Add an annotation 'disk-type: ssd' to the pod

Question 14

A pod is experiencing high memory usage. The administrator wants to enforce that the pod is terminated if it exceeds a memory limit and restarted automatically, but also wants to guarantee a minimum amount of memory for the pod. Which resource specification should be used in the container definition?

Accepted Answer

spec.containers[].resources.requests.memory and limits.memory. Setting both `requests.memory` and `limits.memory` guarantees a minimum memory allocation (the request) while enforcing a hard cap (the limit). If the pod exceeds the memory limit, it is terminated (OOMKilled) and, if part of a Deployment or StatefulSet, the controller automatically restarts it. This satisfies the requirement for both guaranteed minimum and enforced maximum with automatic restart.

Answer

spec.containers[].resources.requests.memory only

Answer

spec.containers[].resources.limits.memory and requests.cpu

Answer

spec.containers[].resources.limits.memory only

Question 15

A developer deploys a CronJob that runs a batch job every 5 minutes. After a while, they notice that the job fails with 'DeadlineExceeded' and the pod is stuck in 'PodInitializing' state. What is the most likely reason?

Accepted Answer

A pre-existing InitContainer is failing or stuck. The 'PodInitializing' state indicates that the pod is stuck before its main containers can start, which is typically caused by an InitContainer that is failing or hanging. Since the job fails with 'DeadlineExceeded', the pod's activeDeadlineSeconds (or the CronJob's startingDeadlineSeconds) has been reached while the InitContainer is still running, preventing the main container from executing. This is the most likely reason because InitContainers run sequentially to completion before any main containers start, and a stuck InitContainer blocks the entire pod lifecycle.

Answer

The CronJob schedule is misconfigured

Answer

The container runtime is not installed on the node

Answer

The job's backoffLimit is set too low