KCNA Kubernetes Fundamentals Practice Test 9 — 15 Questions

Question 1

Which THREE of the following are valid ways to expose a set of pods as a network service in Kubernetes?

Accepted Answer

Creating a Service of type NodePort.. A Service of type NodePort exposes the pods on a static port on each node's IP address, making the service accessible externally. This is a valid method for exposing a set of pods as a network service in Kubernetes.

Answer

Creating a headless Service (clusterIP: None).

Answer

Creating a Deployment with a label selector.

Question 2

Refer to the exhibit. A pod 'my-pod' shows repeated 'BackOff' events after the container starts. Which is the most likely cause?

Accepted Answer

The application crashes shortly after starting.. The 'BackOff' event in Kubernetes indicates that the container has started but repeatedly crashes, causing the kubelet to increase the restart delay. Option D is correct because an application that crashes shortly after starting will trigger this restart loop, as the container exits with a non-zero exit code, leading to exponential backoff.

Answer

The image 'myapp:v2' does not exist.

Answer

The container exceeds its memory limit.

Answer

The liveness probe is failing.

Question 3

A development team deploys a microservice that crashes every few minutes. The deployment uses a single replica, and the pod restarts repeatedly. Which Kubernetes feature should be enabled to ensure the service remains available during failures?

Accepted Answer

Increase the replicas in the Deployment to at least 2. Increasing the replicas to at least 2 ensures that if one pod crashes, the other replica(s) can continue serving traffic, maintaining availability. With only a single replica, the service becomes unavailable every time the pod restarts. This is the most direct way to provide redundancy and fault tolerance for a stateless microservice.

Answer

Move the deployment to a separate namespace

Answer

Store the application configuration in a ConfigMap

Answer

Add a readiness probe to the pod

Question 4

A DevOps engineer needs to expose a set of pods running an HTTP API to external clients. The pods are stateless and should be load-balanced. Which Kubernetes resource should they use?

Accepted Answer

Service of type LoadBalancer. A Service of type LoadBalancer is the correct choice because it provisions an external load balancer (e.g., an AWS ELB or Azure LB) that distributes incoming traffic across the pods, exposing the stateless HTTP API to external clients. This resource automatically assigns a public IP and handles load balancing without requiring manual proxy configuration, making it ideal for external access to stateless workloads.

Answer

StatefulSet with a headless Service

Answer

Ingress resource without a Service

Answer

Service of type ClusterIP

Question 5

An administrator notices that a pod in a Deployment is stuck in CrashLoopBackOff. The pod logs show 'Error: failed to start container: exec: "app": executable file not found in $PATH'. What is the most likely cause?

Accepted Answer

The container image does not contain the binary specified in the pod's command field. The error 'exec: "app": executable file not found in $PATH' indicates that the container image does not contain the binary or script specified in the pod's command field (e.g., `command: ["app"]`). This typically happens when the image is built without the expected executable, the command path is incorrect, or the image tag points to a different version. The container fails to start because the runtime cannot locate the entrypoint.

Answer

The image registry credentials are missing

Answer

The liveness probe is misconfigured and killing the container

Answer

The container is running as a non-root user without proper permissions

Question 6

A team uses a Deployment with 3 replicas and a RollingUpdate strategy. They update the container image. During the update, one of the new pods fails to start. What will happen by default?

Accepted Answer

The update pauses, keeping the remaining old replicas running. By default, a Deployment with a RollingUpdate strategy uses a `maxUnavailable` of 25% and a `maxSurge` of 25%. When a new pod fails to start (e.g., CrashLoopBackOff or ImagePullBackOff), the ReplicaSet controller will not create additional new pods beyond the surge limit, and the update will effectively pause because the new ReplicaSet cannot reach its desired replica count. The old ReplicaSet remains running with its existing pods, ensuring availability is maintained.

Answer

The entire update is rolled back and all old pods are deleted

Answer

The Deployment automatically rolls back to the previous image

Answer

The failed pod is terminated and not retried

Question 7

A company wants to ensure that a database pod runs on a node with SSD storage. How should this be achieved?

Accepted Answer

Label SSD nodes with 'disk=ssd' and add a nodeSelector to the pod. NodeSelector is a field in the Pod spec that constrains which nodes the Pod can be scheduled on, based on node labels. By labeling nodes with SSD storage as 'disk=ssd' and adding a nodeSelector with that label to the Pod, Kubernetes will only schedule the Pod on nodes that have the matching label, ensuring it runs on SSD storage.

Answer

Set a resource request for local SSD storage in the pod spec

Answer

Use pod anti-affinity to avoid non-SSD nodes

Answer

Add a taint to nodes without SSDs and a toleration to the pod

Question 8

Which TWO statements about Kubernetes Services are correct?

Accepted Answer

The default Service type is ClusterIP. The default Service type in Kubernetes is ClusterIP, which exposes the Service on a cluster-internal IP address. This means the Service is only reachable from within the cluster, providing a stable internal endpoint for pod-to-pod communication without external exposure.

Answer

A Service can expose only one container port

Answer

A Service can only route traffic to pods on the same node as the Service

Answer

A Service of type NodePort exposes the service only on the node where the pod is running

Question 9

Which THREE are valid ways to provide configuration data to a pod in Kubernetes?

Accepted Answer

Mount a ConfigMap as a volume. A ConfigMap is a Kubernetes API object designed to store non-confidential configuration data in key-value pairs. Mounting a ConfigMap as a volume makes its data available as files in the pod's filesystem, allowing applications to read configuration without hardcoding it into the container image or pod spec. This approach decouples configuration from containerized applications, following the principle of immutable infrastructure.

Answer

Use an init container to write configuration to a shared volume

Answer

Hardcode environment variables in the pod spec that contain sensitive data

Question 10

A team observes that a Pod is stuck in CrashLoopBackOff. The Pod runs a single container with an entrypoint that exits with non-zero code after a few seconds. The team wants to inspect the container's logs to understand why it is crashing. Which command should they use?

Accepted Answer

kubectl logs --previous. The `kubectl logs --previous` command retrieves the logs from the previous instance of a crashed container. Since the Pod is in CrashLoopBackOff, the current container has already exited, and the `--previous` flag accesses the logs of the last terminated container, which contains the crash output (e.g., the non-zero exit code and error messages). This is the direct way to see why the entrypoint failed.

Answer

kubectl get pods

Answer

kubectl describe pod <pod-name>

Answer

kubectl exec -it <pod-name> -- sh

Question 11

A developer wants to run a one-time batch job that processes a queue and then terminates. Which Kubernetes resource should they use?

Accepted Answer

Job. A Kubernetes Job is designed for finite, batch-oriented tasks that run to completion, such as processing a queue and then terminating. Unlike controllers that maintain a desired state (like Deployments or StatefulSets), a Job creates one or more Pods and ensures they successfully exit, making it the correct choice for a one-time batch job.

Answer

StatefulSet

Answer

Deployment

Answer

DaemonSet

Question 12

An application running in a Kubernetes cluster needs to securely access a third-party API. The API key must be stored in the cluster and mounted into the Pod as an environment variable. Which is the best practice?

Accepted Answer

Create a Secret with the API key and use envFrom or valueFrom in the Pod spec.. Kubernetes Secrets are specifically designed to store sensitive data like API keys, and using `envFrom` or `valueFrom` in the Pod spec injects the Secret value as an environment variable without exposing it in the Pod definition. This approach follows the principle of least privilege and avoids hardcoding secrets in images or plaintext ConfigMaps.

Answer

Store the API key in a ConfigMap and reference it in the Pod spec.

Answer

Embed the API key directly in the container image.

Answer

Store the API key in a Pod annotation and read it with kubectl.

Question 13

A Pod has a container that needs to write logs to a file. The administrator wants the logs to persist even if the container restarts. What is the simplest solution?

Accepted Answer

Use an emptyDir volume and mount it at the log path.. An emptyDir volume provides a simple, ephemeral storage solution that persists across container restarts within the same Pod. When a container crashes and is restarted by the kubelet, the emptyDir volume's contents remain intact, allowing log files to survive container restarts without requiring external storage or complex configuration.

Answer

Use a PersistentVolumeClaim for each container.

Answer

Use a hostPath volume to write logs directly to the node filesystem.

Answer

Store logs in a ConfigMap.

Question 14

A team is designing a Kubernetes cluster for a production workload that requires high availability. They have three worker nodes in different availability zones. Which statement about scheduling Pods is correct?

Accepted Answer

Define a Pod topology spread constraint with topologyKey: topology.kubernetes.io/zone.. A Pod topology spread constraint with `topologyKey: topology.kubernetes.io/zone` explicitly instructs the scheduler to distribute Pods evenly across the specified failure domains (availability zones). This ensures that if one zone fails, the remaining zones still have running Pods, achieving high availability for the production workload.

Answer

Use nodeSelector to assign Pods to nodes in different zones.

Answer

Add tolerations for the zone taint.

Answer

Use podAntiAffinity with a requiredDuringSchedulingIgnoredDuringExecution rule.

Question 15

Drag and drop the steps to set up a Kubernetes cluster using kubeadm into the correct order.

Accepted Answer

Install container runtime and Kubernetes tools, then run kubeadm init on the control plane, then install a pod network plugin, then run kubeadm join on worker nodes.. First install runtime and Kubernetes tools, then init control plane, add network plugin, and join workers.

Answer

Install container runtime and Kubernetes tools, then install a pod network plugin, then run kubeadm init on the control plane, then run kubeadm join on worker nodes.

Answer

Run kubeadm init on the control plane, then install container runtime and Kubernetes tools, then install a pod network plugin, then run kubeadm join on worker nodes.

Answer

Install container runtime and Kubernetes tools, then run kubeadm init on the control plane, then run kubeadm join on worker nodes, then install a pod network plugin.