KCNA Practice Exam 51 — 20 Questions

Question 1

What is the primary purpose of a service mesh in a cloud-native architecture?

Accepted Answer

To provide a dedicated infrastructure layer for handling service-to-service communication. A service mesh provides a dedicated infrastructure layer for managing service-to-service communication, typically using sidecar proxies. It handles traffic management, security, and observability without requiring changes to application code. This allows developers to focus on business logic while the mesh handles cross-cutting concerns.

Answer

To compile application code

Answer

To replace container orchestration

Answer

To store application configuration

Question 2

A Pod is stuck in Pending state. Which of the following is the MOST likely cause?

Accepted Answer

No node has enough resources to run the Pod. A Pod stuck in Pending state means the scheduler cannot place it on a node. The most common reason is insufficient resources (CPU, memory, or ephemeral storage) on any available node, causing the scheduler to leave the Pod unscheduled. This is indicated by the Pod's status remaining Pending and typically confirmed via `kubectl describe pod` showing events like '0/1 nodes are available: 1 Insufficient cpu'.

Answer

The Pod's container is crashing

Answer

The container image has a typo

Answer

The Pod's liveness probe is failing

Question 3

You have a Deployment named 'web-app' with 3 replicas. You need to scale it to 5 replicas. Which kubectl command should you use?

Accepted Answer

kubectl scale deployment web-app --replicas=5. The `kubectl scale` command is the correct way to adjust the replica count of an existing Deployment. It directly modifies the `spec.replicas` field in the Deployment's desired state, instructing the ReplicaSet controller to create or delete Pods to match the new count. Option B uses the correct syntax `kubectl scale deployment web-app --replicas=5` to achieve this.

Answer

kubectl create deployment web-app --replicas=5

Answer

kubectl edit deployment web-app --replicas=5

Answer

kubectl describe deployment web-app

Question 4

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 5

Which TWO statements correctly describe the purpose of etcd in a Kubernetes cluster?

Accepted Answer

It stores the cluster state, including all Kubernetes objects.. Option A is correct because etcd is the backing store for all Kubernetes cluster data: every API object (Pods, Services, ConfigMaps, Secrets, etc.) is serialized and persisted in etcd, making it the single source of truth for cluster state. Option E is correct because etcd is fundamentally a distributed key-value store built on the Raft consensus algorithm, which replicates data across members to deliver high availability and strong consistency (linearizable reads/writes). Option B is wrong because Pod-to-Pod network rules are implemented by the CNI plugin and kube-proxy (iptables/IPVS or eBPF), not etcd. Option C is wrong because Pod scheduling is the job of kube-scheduler, which watches the API server and binds Pods to nodes. Option D is wrong because the Kubernetes API is exposed by kube-apiserver; etcd only serves as its storage backend and is not itself an API endpoint for clients.

Answer

It manages network rules for Pod-to-Pod communication.

Answer

It schedules Pods onto nodes based on resource availability.

Answer

It exposes the Kubernetes API for external access.

Question 6

Which TWO of the following are benefits of using Helm for application delivery?

Accepted Answer

Ability to roll back to previous releases. Option B is correct because Helm maintains a release history for each chart installation, and the 'helm rollback ' command lets you revert a release to any prior revision, restoring the previously deployed Kubernetes manifests. Option D is correct because Helm packages Kubernetes resources into reusable charts and uses Go templating plus values files to parameterize manifests, which simplifies packaging, sharing, and customizing deployments across environments. Option A is not a Helm feature; automatic CPU-based scaling is provided by the Kubernetes Horizontal Pod Autoscaler, not by Helm itself. Option C is not built into Helm; canary deployments require additional tooling such as Argo Rollouts, Flagger, or service-mesh traffic splitting. Option E is not provided by Helm; monitoring and alerting come from tools like Prometheus, Grafana, or Alertmanager, while Helm only manages manifest packaging and release lifecycle.

Answer

Automatic scaling based on CPU usage

Answer

Automatic canary deployments

Answer

Built-in monitoring and alerting

Question 7

What is the primary purpose of a Kubernetes Service?

Accepted Answer

To provide a stable network endpoint for a set of pods. A Kubernetes Service provides a stable, virtual IP and DNS name that remains constant even as the underlying pods are created, destroyed, or scaled. It acts as a load balancer across a set of pods selected by labels, abstracting away the ephemeral nature of pod IPs. This enables reliable communication between components within the cluster without requiring clients to track individual pod addresses.

Answer

To implement network routing rules on each node

Answer

To manage rolling updates of applications

Answer

To store configuration data as key-value pairs

Question 8

A pod is stuck in 'Pending' state. Which of the following is NOT a common cause for a pod to remain Pending?

Accepted Answer

The container runtime is not functioning on the node. A non-functioning container runtime on a node typically results in pod states like CrashLoopBackOff or Error, not prolonged 'Pending' state. Pending state occurs when a pod cannot be scheduled. Insufficient resources (A), node selector mismatch (B), and unbound PVCs (D) are common causes of scheduling failures that keep a pod in Pending. Container runtime issues affect pod execution after scheduling, not the scheduling process itself. Therefore, C is NOT a common cause for a pod to remain Pending.

Answer

Insufficient CPU or memory resources available in the cluster

Answer

The node selector in the pod spec does not match any node labels

Answer

The pod's PVC is not yet bound to a PV

Question 9

A Pod is in the 'Pending' state. What is the most likely cause?

Accepted Answer

The Pod is still being scheduled because no Node has enough resources. A Pod in 'Pending' state means the Pod has been accepted by the API server but is not yet running. The most common reason is that the scheduler cannot find a Node with sufficient CPU, memory, or other resources to place the Pod. This triggers the scheduler to continuously attempt to bind the Pod to a suitable Node, leaving it in Pending until resources become available or the Pod is deleted.

Answer

The container image is missing

Answer

The Service referencing the Pod does not exist

Answer

The application inside the container has crashed

Question 10

A Service of type ClusterIP is not resolving DNS names for pods. The pods are running and can communicate with each other via IP addresses. Which component should be checked first?

Accepted Answer

CoreDNS pods in the kube-system namespace. DNS name resolution for Services in Kubernetes is handled by CoreDNS, which runs as pods in the kube-system namespace. When a ClusterIP Service fails to resolve DNS names but pods can communicate via IP addresses, the issue is almost certainly with the DNS resolver itself, not with network connectivity or Service endpoints. CoreDNS must be checked first to ensure it is running, has correct configuration, and can query the Kubernetes API for Service records.

Answer

The kubelet on the node where the pod is running

Answer

The Service's endpoint slices

Answer

kube-proxy on the nodes

Question 11

A Deployment manages ReplicaSets. What is the primary benefit of using a Deployment over directly managing ReplicaSets?

Accepted Answer

Deployments support rolling updates and rollbacks. The primary benefit of using a Deployment over directly managing ReplicaSets is that Deployments provide declarative updates for Pods and ReplicaSets, including built-in support for rolling updates and rollbacks. This allows you to update the desired state (e.g., a new container image version) and have the Deployment controller automatically orchestrate the transition, while also enabling you to revert to a previous revision if the update fails. Directly managing ReplicaSets would require manual steps to scale down old ReplicaSets and scale up new ones, and it lacks the automated revision history and rollback capabilities that Deployments offer.

Answer

Deployments can expose services externally

Answer

Deployments automatically configure DNS

Answer

Deployments provide persistent storage

Question 12

Which Kubernetes control plane component is the primary entry point for all administrative tasks and serves the Kubernetes API?

Accepted Answer

kube-apiserver. The kube-apiserver is the front-end of the Kubernetes control plane and the sole entry point for all administrative operations. It exposes the Kubernetes REST API, validates and processes requests (including authentication, authorization, and admission control), and updates the corresponding objects in etcd. Without the API server, no kubectl command, automation, or internal component communication can occur.

Answer

kube-scheduler

Answer

kube-controller-manager

Answer

etcd

Question 13

An application requires that a set of Pods each be assigned a unique DNS name that can be used for peer-to-peer communication. Which Kubernetes resource should be used?

Accepted Answer

StatefulSet with a Headless Service. A StatefulSet with a Headless Service is correct because StatefulSets assign each Pod a stable, unique network identity (e.g., pod-name-0.service-name.namespace.svc.cluster.local) that persists across rescheduling. A Headless Service (clusterIP: None) disables load balancing and DNS round-robin, allowing direct DNS resolution to individual Pod IPs for peer-to-peer communication. This matches the requirement for unique DNS names for each Pod.

Answer

Job with a Service

Answer

DaemonSet with a Service

Answer

Deployment with a Service

Question 14

A pod is in 'Pending' state for a long time. What is the most likely cause?

Accepted Answer

The scheduler cannot find a node that satisfies the pod's resource requests or constraints. A pod remains in 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is that the scheduler cannot find a node that meets the pod's resource requests (CPU/memory) or constraints (node selectors, affinity rules, taints/tolerations). Until a suitable node is found, the pod stays in Pending, waiting for scheduling.

Answer

The pod's container has crashed

Answer

The pod's service endpoint is misconfigured

Answer

The container image is invalid

Question 15

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 16

You are asked to schedule a pod on a node that has SSD storage. Which mechanism should you use to achieve this?

Accepted Answer

Add a nodeSelector with a label matching the node, e.g., disktype: ssd. NodeSelector is the built-in Kubernetes mechanism for constraining a pod to nodes with specific labels. By labeling a node with disktype=ssd and adding that same label selector to the pod spec, the scheduler will only place the pod on nodes that have that label, ensuring it lands on SSD-equipped nodes.

Answer

Use a resource request for SSD storage capacity

Answer

Set an annotation on the pod specifying the disk type

Answer

Add a toleration for a taint on SSD nodes

Question 17

A Deployment is configured with 'replicas: 4' and 'strategy.type: RollingUpdate'. You update the container image. What behavior does the Deployment exhibit?

Accepted Answer

New Pods are created before old ones are terminated, one at a time. With a RollingUpdate strategy, the Deployment controller replaces old Pods with new ones incrementally to ensure zero downtime. By default, it creates new Pods before terminating old ones (maxSurge=25%, maxUnavailable=25%), so one new Pod is created first, then one old Pod is terminated, repeating until all 4 Pods run the new image.

Answer

The Deployment creates 8 Pods total, 4 old and 4 new

Answer

All 4 Pods are deleted immediately and then 4 new Pods are created

Answer

The update is paused until manually resumed

Question 18

The exhibit shows a Deployment manifest for a frontend service. After deployment, the pods are running but the service reports that no endpoints are available. What is the most likely cause?

Accepted Answer

The readiness probe is checking /ready which is not returning a 200 OK response.. The service reports no endpoints because the readiness probe is failing. A readiness probe determines whether a pod should receive traffic; if it does not return a 200 OK on the configured path (/ready), the pod is removed from the service’s endpoint list. Since the pods are running (liveness probe passes), the most likely cause is that the /ready endpoint is not serving a successful response.

Answer

The readiness probe periodSeconds is too short, causing the probe to overload the container.

Answer

The container image nginx:1.21 does not have the /healthz endpoint.

Answer

The liveness probe is failing, causing the pod to be restarted.

Question 19

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 20

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

Accepted Answer

To check if the application is still running; if not, restart the container. A liveness probe in Kubernetes is used to determine if a container is still running and healthy. If the probe fails, the kubelet kills the container and restarts it based on the pod's restart policy. This ensures that applications that have entered a deadlock or hung state are automatically recovered without manual intervention.

Answer

To check if the pod is scheduled on a node

Answer

To check if the container has started successfully

Answer

To check if the application is ready to serve traffic