KCNA Practice Exam 58 — 20 Questions

Question 1

A team wants to run a database Pod that must be scheduled onto a node with an SSD and must not be evicted when the node comes under memory pressure. Which combination of fields should be configured in the Pod spec?

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

Accepted Answer

nodeAffinity with a disk-type match and resource requests equal to limits for memory. Node placement is expressed through nodeSelector or nodeAffinity, and protection from kubelet eviction under resource pressure comes from the Pod's QoS class. Setting memory requests equal to limits yields Guaranteed QoS, which is evicted last. Taints, tolerations, PriorityClass, and PodDisruptionBudgets address different concerns and do not provide the required placement plus eviction resistance together.

Answer

A taint on the database Pod and a matching toleration on the SSD nodes

Answer

nodeSelector with a disk-type label and a PriorityClass with a high value

Answer

A PodDisruptionBudget with minAvailable set to one and an emptyDir volume

Question 2

A developer is troubleshooting a Pod that is stuck in the Pending state. Which two commands can help identify the reason for the scheduling failure? (Choose two.)

Accepted Answer

kubectl get events --field-selector involvedObject.name=<pod-name>. When a Pod is Pending, the scheduler has not placed it on a node. The describe command and filtered events both surface scheduler events that state the reason, such as insufficient resources or taints. Logs, exec, and top require a running container and are not useful for a Pod that has never started.

Answer

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

Answer

kubectl top pod <pod-name>

Answer

kubectl logs <pod-name>

Question 3

A site reliability engineer is investigating high latency in a microservices application. They have distributed tracing enabled with OpenTelemetry and traces exported to a backend. They want to correlate a specific slow trace with the logs generated by the involved services. Which practice best enables this correlation?

Accepted Answer

Include the trace ID and span ID in the log entries of each service.. Correlating traces and logs requires a shared identifier. By injecting the trace ID and span ID into log records, each log line can be tied to the exact trace and span that produced it. This allows an engineer to take a slow trace, extract its trace ID, and query logs for that ID to see all related events across services. Other options do not provide this direct linkage.

Answer

Enable debug logging on all services and increase log verbosity.

Answer

Configure the OpenTelemetry Collector to sample all traces at 100%.

Answer

Use a separate logging backend that is different from the tracing backend.

Question 4

A developer instruments a service using the OpenTelemetry SDK and wants to export traces to a backend. The backend expects data in the OTLP format. Which OpenTelemetry component is responsible for receiving, processing, and exporting telemetry data to the backend?

Accepted Answer

OpenTelemetry Collector. The OpenTelemetry Collector is designed to receive telemetry in OTLP and other formats, apply processors such as batching or filtering, and export to one or more backends. The API and SDK are for instrumenting and generating data inside applications, while OTLP is only the transport protocol. Therefore, the Collector is the component that receives, processes, and exports telemetry in this pipeline.

Answer

OpenTelemetry Protocol (OTLP)

Answer

OpenTelemetry SDK

Answer

OpenTelemetry API

Question 5

A team is evaluating whether their application qualifies as cloud-native. They want to identify characteristics that are central to cloud-native architecture rather than incidental implementation details. Which TWO of the following are core characteristics of cloud-native architecture? (Choose two.)

Accepted Answer

Declarative configuration and automated management. Declarative configuration with automated management and resilience through fault tolerance and graceful degradation are core cloud-native characteristics. They shape how systems are defined, reconciled, and kept running under failure. Manual provisioning, tight coupling, and exclusive reliance on proprietary APIs work against portability, automation, and independent operation, so they are not central characteristics of cloud-native architecture.

Answer

Manual, ticket-driven provisioning of production servers

Answer

Tight coupling between services to reduce network calls

Answer

Vendor-specific, proprietary APIs for all internal communication

Question 6

You are deploying a stateful application that requires each pod to have a stable, unique network identity and its own persistent storage. Which Kubernetes resource should you use?

Accepted Answer

StatefulSet. StatefulSet is the correct resource for stateful applications because it provides stable network identities and persistent storage per pod. Each pod in a StatefulSet gets a unique ordinal index, a stable hostname, and its own PersistentVolumeClaim. Deployments, DaemonSets, and ReplicaSets are designed for stateless workloads and do not offer these guarantees.

Answer

DaemonSet

Answer

ReplicaSet

Answer

Deployment

Question 7

A platform team uses Argo CD to manage a Kubernetes cluster. A developer manually edits a Deployment's replica count from 3 to 5 using kubectl, bypassing Git. Argo CD detects the drift and its sync policy is set to automated with self-heal enabled. What happens next?

Accepted Answer

Argo CD reverts the replica count back to the value defined in Git.. When Argo CD's automated sync policy includes self-heal, it automatically reverts any manual changes to the cluster that deviate from the Git repository. In this case, the developer's manual scaling to 5 replicas is undone, and the Deployment is restored to the Git-defined 3 replicas. This ensures Git remains the single source of truth and prevents configuration drift.

Answer

Argo CD marks the application as OutOfSync but takes no action because self-heal is disabled.

Answer

Argo CD deletes the Deployment and recreates it from the Git manifest.

Answer

Argo CD updates the Git repository to match the live cluster state.

Question 8

A cluster administrator wants to ensure that a specific Pod always runs on a node with an SSD. The node has the label disktype=ssd. Which Kubernetes feature should the administrator use?

Accepted Answer

nodeSelector. nodeSelector is the simplest way to constrain a Pod to nodes with specific labels. By specifying a label like disktype=ssd, the scheduler only considers nodes that have that label. This directly satisfies the requirement of running on an SSD node.

Answer

Pod affinity

Answer

Taints and tolerations

Answer

Resource requests and limits

Question 9

A pod is stuck in the Pending state. The administrator runs 'kubectl describe pod' and sees the event '0/3 nodes are available: 3 Insufficient cpu.' What is the most likely cause?

Accepted Answer

The pod's CPU request is higher than the available CPU on any node.. The event 'Insufficient cpu' indicates that the scheduler cannot find a node with enough allocatable CPU to meet the pod's CPU request. This is a resource constraint issue, not related to limits, cordoning, or node selectors. The pod will remain Pending until sufficient CPU is available or the request is reduced.

Answer

The nodes are cordoned and cannot accept new pods.

Answer

The pod's CPU limit is set too low, causing it to be rejected.

Answer

The pod has a nodeSelector that does not match any node labels.

Question 10

A cluster runs the Horizontal Pod Autoscaler (HPA) v2 for a Deployment named queue-worker. The HPA is configured with minReplicas: 2, maxReplicas: 10, and a target average CPU utilization of 60%. Metrics Server is installed and reports CPU for the Pods. During a burst, CPU utilization rises to 95% and stays there, but the Deployment remains at 2 replicas. Which condition most likely explains why the HPA is not scaling out?

Accepted Answer

The Deployment's Pod template does not set CPU requests, so the HPA cannot compute utilization.. The HPA computes CPU utilization against the container's CPU request. Without resources.requests.cpu in the Pod template, the utilization metric is unavailable and the HPA cannot decide to scale, so replicas remain at the minimum even during sustained high CPU. PodDisruptionBudgets, Metrics Server scope, and maxReplicas are not the cause in this scenario.

Answer

The HPA needs a PodDisruptionBudget before it can scale the Deployment.

Answer

The HPA's maxReplicas of 10 is lower than the current node capacity, so it refuses to scale.

Answer

Metrics Server only reports node metrics, so the HPA must use custom metrics instead.

Question 11

A developer is troubleshooting a Pod that is stuck in the Pending state. They want to gather information to determine why the Pod has not been scheduled. Which two commands or outputs are most directly useful for this diagnosis? (Choose two.)

Accepted Answer

Run `kubectl describe pod <pod-name>` and inspect the Events section at the bottom.. For a Pending Pod, the scheduler's reasoning is exposed through events. `kubectl describe pod` surfaces FailedScheduling events with specific reasons, and `kubectl get events` with a field selector provides a filtered event timeline. Logs, exec, and top all require a running container, which does not exist before scheduling, so they cannot diagnose a Pending state. The two event-based approaches are the correct diagnostic tools.

Answer

Run `kubectl top pod <pod-name>` to check the Pod's CPU and memory usage against requests.

Answer

Run `kubectl logs <pod-name>` to read the application logs for scheduling errors.

Answer

Run `kubectl exec -it <pod-name> -- /bin/sh` to inspect the container's environment.

Question 12

A team is designing a cloud-native system that must remain available even if an entire availability zone fails. They want to distribute workloads across multiple zones and automatically recover from failures. Which cloud-native architectural approach BEST addresses this requirement?

Accepted Answer

Use a multi-zone cluster with anti-affinity rules and health checks. Spreading workloads across multiple availability zones with anti-affinity and health checks enables the system to tolerate a zone failure. Kubernetes can reschedule pods from a failed zone onto nodes in healthy zones, maintaining service. This design is a standard cloud-native pattern for high availability.

Answer

Rely on vertical scaling of a single large node

Answer

Store all state in a single-zone database

Answer

Deploy all replicas in a single zone with a load balancer

Question 13

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 14

You are writing a Pod manifest and need to ensure the container always pulls the newest image from the registry, even if an image with the same tag already exists on the node. Which imagePullPolicy should you set?

Accepted Answer

Always. The imagePullPolicy field controls whether the kubelet consults the node's local image cache or the registry. Always is the only policy that unconditionally pulls on every container start, which is what guarantees fresh content when a mutable tag is reused. IfNotPresent and Never both allow a stale cached image to run, and Latest is not a recognized policy value.

Answer

Latest

Answer

Never

Answer

IfNotPresent

Question 15

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 16

A cluster administrator needs to run a node-level log collector that must read files from /var/log on every node in the cluster, including nodes added later. The collector does not need to run on control plane nodes. Which Kubernetes resource should be used?

Accepted Answer

DaemonSet. A DaemonSet is the correct resource because it schedules exactly one Pod on each node that matches its node selector or affinity rules, and it automatically adds Pods to new nodes as they join the cluster. This makes it ideal for node-level agents such as log collectors, monitoring daemons, and network plugins that must run everywhere.

Answer

Job with parallelism set to the node count

Answer

StatefulSet with podAntiAffinity

Answer

Deployment with replicas equal to the number of nodes

Question 17

A team wants to run a batch job that must complete successfully exactly once and then stop. The job processes a queue and should not be restarted after successful completion. Which Kubernetes resource is most appropriate for this requirement?

Accepted Answer

Job. Job is the controller designed for run-to-completion workloads. It tracks successful Pod completions and stops creating new Pods once the required count is reached. Deployments, DaemonSets, and StatefulSets all maintain long-running Pods and would not naturally terminate after a single successful execution, making them inappropriate for this batch processing requirement.

Answer

DaemonSet

Answer

StatefulSet

Answer

Deployment

Question 18

An administrator must run a privileged DaemonSet on every node, including the control-plane node, to collect host logs. The control-plane node has a taint node-role.kubernetes.io/control-plane:NoSchedule. Which change allows the DaemonSet Pods to be scheduled on the control-plane node while keeping the taint intact?

Accepted Answer

Add a toleration for key node-role.kubernetes.io/control-plane with operator Exists and effect NoSchedule to the DaemonSet Pod template.. Taints repel Pods unless the Pod declares a matching toleration. Adding a toleration with operator Exists and effect NoSchedule for the control-plane taint lets the DaemonSet schedule there while leaving the taint in place, so other workloads remain excluded. Removing the taint, pinning with nodeName, or using a nodeSelector does not meet the requirement of keeping the taint intact.

Answer

Remove the taint from the control-plane node with kubectl taint nodes --all node-role.kubernetes.io/control-plane-.

Answer

Set spec.template.spec.nodeName to the control-plane node name in the DaemonSet.

Answer

Add a nodeSelector for node-role.kubernetes.io/control-plane to the DaemonSet Pod template.

Question 19

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 20

A developer wants to run a one-off database migration task in Kubernetes that must complete successfully and then stop. The task should not restart after successful completion, and the developer wants to inspect logs after it finishes. Which resource should be created?

Accepted Answer

A Job with restartPolicy set to OnFailure or Never. A Job is the correct resource for run-to-completion tasks. By setting the Pod template's restartPolicy to OnFailure or Never, the container stops after a successful exit, and the Job records completion. The completed Pod remains for log inspection, unlike a Deployment or bare Pod with Always restart policy, which would keep restarting the container.

Answer

A bare Pod with restartPolicy set to Always

Answer

A CronJob with schedule set to a date in the past

Answer

A Deployment with a single replica