KCNA Practice Test 18 — 15 Questions

Question 1

You notice that a newly created Pod remains in 'Pending' state. Which of the following is the MOST likely cause?

Accepted Answer

There are insufficient resources available on any node to meet the Pod's requests. A Pod enters 'Pending' state when it cannot be scheduled onto a node. The most common reason is insufficient CPU, memory, or other resources on any available node to satisfy the Pod's resource requests. The Kubernetes scheduler continuously evaluates node capacity against Pod requests, and if no node can accommodate the Pod, it remains unscheduled in Pending.

Answer

The Pod manifest has a syntax error

Answer

The container image does not exist

Answer

The Service does not exist

Question 2

A team is designing a Kubernetes observability stack and wants to use Prometheus for metrics. They need to understand how Prometheus collects and stores time series data. Which TWO of the following statements accurately describe Prometheus? (Choose two.)

Accepted Answer

Prometheus pulls metrics from targets by scraping HTTP endpoints at regular intervals.. Prometheus is a pull-based monitoring system that scrapes HTTP endpoints and stores samples in a local append-only time-series database. It does not depend on distributed consensus, does not require proprietary SDKs, and does not automatically scrape all pods without configuration. The two accurate statements describe its core collection and storage mechanisms, which are essential to understand when designing a Kubernetes observability stack.

Answer

Prometheus requires a distributed consensus protocol to ensure data consistency across all nodes.

Answer

Prometheus automatically discovers and scrapes all pods in a cluster without any configuration.

Answer

Prometheus can only collect metrics that are pushed to it by applications using a proprietary SDK.

Question 3

A platform engineer is explaining cloud-native architecture to a new team. The team asks which statement BEST describes the relationship between microservices and cloud-native architecture. Which answer is correct?

Accepted Answer

Microservices are one common architectural style used within cloud-native systems. Microservices are a common architectural style within cloud-native systems, valued for independent deployability, scalability, and fault isolation. They are not the only way to be cloud-native, and they do not remove the need for observability or decentralized data. The other statements are either too absolute or contradict established cloud-native practices, so the accurate description is that microservices are one common style.

Answer

Microservices are the only valid way to build cloud-native applications

Answer

Cloud-native architecture requires every service to share a single database

Answer

Microservices eliminate the need for observability and monitoring

Question 4

A security team wants to audit which users performed privileged actions in a Kubernetes cluster. They need a record of API requests, including the user, verb, resource, and response status. Which Kubernetes feature should they enable?

Accepted Answer

Audit logging. Audit logging in Kubernetes records API server requests with user, verb, resource, and response details, which is exactly what the security team needs to trace privileged actions. Event recording is limited to cluster events, metrics-server provides resource metrics, and Pod Security Admission enforces policies but does not create an audit trail. Only audit logging delivers the required request-level records.

Answer

Metrics-server

Answer

Pod Security Admission

Answer

Event recording

Question 5

A Kubernetes cluster has a pod that is stuck in the 'Pending' state. The operations team runs 'kubectl describe pod' and sees the event: '0/3 nodes are available: 3 Insufficient cpu.' What is the most likely cause of this issue?

Accepted Answer

The pod's CPU request exceeds the allocatable 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 happens when the sum of CPU requests from existing pods on each node plus the new pod's request exceeds the node's capacity. The pod remains Pending until resources are freed or the request is lowered. Other factors like taints or node selectors would produce different event messages.

Answer

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

Answer

The nodes have CPU resources but are tainted, preventing scheduling.

Answer

The pod's CPU limit is set too low, causing the scheduler to reject it.

Question 6

A CI pipeline builds a container image and tags it as 'myapp:latest'. The pipeline then pushes the image to a registry. A Kubernetes Deployment manifest references 'myapp:latest' with imagePullPolicy: Always. After a new image is pushed with the same tag, the team notices that existing Pods are not updated. What is the most likely reason?

Accepted Answer

The Deployment's pod template spec has not changed, so no rolling update is triggered.. A Kubernetes Deployment initiates a rolling update only when the pod template spec changes, such as an image tag or environment variable. Overwriting an existing image tag does not alter the template, so the Deployment controller does not roll out new Pods. Even with imagePullPolicy: Always, existing Pods are not restarted. To force an update, the team must change the image tag or another template field.

Answer

The container registry does not support overwriting existing tags.

Answer

The imagePullPolicy: Always setting causes Kubernetes to ignore the new image.

Answer

The Deployment's rollout strategy is set to Recreate, which prevents updates.

Question 7

A platform team must ensure that a critical StatefulSet named ledger in the finance namespace always has at least two Pods available during voluntary disruptions such as node drains, and that Pods are spread across different nodes. Which two resources or settings should they configure? (Choose two.)

Accepted Answer

A PodDisruptionBudget in the finance namespace with minAvailable: 2 and a selector matching the ledger Pods.. A PodDisruptionBudget with minAvailable: 2 protects the StatefulSet during voluntary disruptions by blocking evictions that would drop below two available Pods. A topologySpreadConstraint keyed on kubernetes.io/hostname with DoNotSchedule enforces placement on separate nodes, which supports both resilience and the availability target. NetworkPolicy, ResourceQuota, and PriorityClass address traffic control, resource limits, and scheduling priority rather than the required availability and spread guarantees.

Answer

A ResourceQuota in the finance namespace limiting CPU and memory requests.

Answer

A NetworkPolicy in the finance namespace that allows ingress only from the ledger Pods.

Answer

A PriorityClass assigned to the ledger Pods with a high value.

Question 8

A development team wants to package and deploy a multi-tier application to Kubernetes. They need to template Kubernetes manifests with environment-specific values and manage releases with versioning and rollback capabilities. Which tool is purpose-built for this?

Accepted Answer

Helm. Helm is specifically designed to package Kubernetes applications as charts, template manifests with values files for different environments, and manage releases with versioning and rollback. It provides a release history and atomic upgrades, making it ideal for the described scenario. Other tools like Kustomize or Argo CD serve different purposes and do not offer the same integrated packaging and release lifecycle.

Answer

Argo CD

Answer

kubectl

Answer

Kustomize

Question 9

A platform team is deploying a logging stack in Kubernetes. They want to collect logs from all pods and nodes, store them centrally, and provide a query interface. Which combination of tools is commonly used to achieve this?

Accepted Answer

Fluent Bit for collection, Elasticsearch for storage, Kibana for visualization. The EFK stack—Elasticsearch, Fluent Bit (or Fluentd), and Kibana—is a widely adopted solution for Kubernetes logging. Fluent Bit runs as a DaemonSet to collect logs from each node, Elasticsearch indexes and stores them, and Kibana provides a UI for searching and visualizing. This architecture meets the needs of collecting, storing, and querying logs centrally, making it the correct choice among the options.

Answer

Prometheus for collection, Grafana for storage, Loki for visualization

Answer

OpenTelemetry Collector for collection, Jaeger for storage, Kibana for visualization

Answer

Jaeger for collection, Prometheus for storage, Grafana for visualization

Question 10

A platform team wants to package a multi-service application into a single distributable artifact that includes Kubernetes manifests, default configuration values, and a version number. Which tool is purpose-built for this task?

Accepted Answer

Helm. Helm is the package manager for Kubernetes: a chart bundles templated manifests, default values, and metadata into a versioned artifact that can be installed, upgraded, and rolled back as a unit. The other tools either patch existing YAML, talk to the API server, or target a different runtime entirely.

Answer

kubectl

Answer

Kustomize

Answer

Docker Compose

Question 11

A team is implementing observability for a cloud native application. They want to adopt OpenTelemetry to instrument their code and collect telemetry data. Which TWO of the following are core components of the OpenTelemetry project? (Choose two.)

Accepted Answer

OpenTelemetry API. OpenTelemetry consists of several core components, including the API, SDK, and Collector. The API defines the instrumentation interfaces, while the SDK provides the implementation. The Collector is a standalone service that receives, processes, and exports telemetry. Together, these components enable vendor-neutral collection of metrics, logs, and traces. Prometheus, Jaeger, and Fluentd are separate projects that can integrate with OpenTelemetry but are not part of it.

Answer

Fluentd

Answer

Jaeger Backend

Answer

Prometheus Server

Question 12

A team uses Argo CD to manage a production cluster. A developer commits a change to the Git repository that declares a Deployment with three replicas, but someone later manually scales the Deployment to five replicas using kubectl. What does Argo CD report and do by default?

Accepted Answer

It reports the application as OutOfSync and, with auto-sync enabled, reverts the live Deployment to three replicas.. Argo CD enforces Git as the single source of truth. A manual scale creates drift, which Argo CD detects as OutOfSync, and with automated sync enabled it applies the Git manifest to restore the declared replica count, undoing the out-of-band change.

Answer

It updates the Git repository to record five replicas so the declared state matches the cluster.

Answer

It ignores the manual change until the next Git commit touches the same Deployment.

Answer

It reports the application as Synced because the Deployment still exists and is healthy.

Question 13

Which two statements about Pods are true? (Select TWO)

Accepted Answer

Containers in the same Pod share the same network namespace. Option B is correct because all containers within a single Pod share the same network namespace, meaning they share the same IP address and port space and can communicate with each other via localhost. Option D is correct because the Pod is the smallest deployable unit in Kubernetes; you cannot deploy or schedule a single container directly without wrapping it in a Pod. Option A is incorrect because a Pod can contain multiple containers (e.g., sidecar, ambassador, or adapter patterns) that are co-scheduled and co-located. Option C is incorrect because a Pod is not automatically recreated if its Node fails; only Pods managed by a controller such as a ReplicaSet or Deployment are rescheduled and recreated. Option E is incorrect because users typically create Pods indirectly through controllers like Deployments, ReplicaSets, or StatefulSets, and bare Pods created directly are not rescheduled if they fail.

Answer

A Pod can only contain one container

Answer

A Pod is automatically recreated if its Node fails

Answer

Pods are always created directly by users

Question 14

Which TWO of the following are best practices for implementing observability in a cloud-native environment?

Accepted Answer

Add unique request IDs to logs for end-to-end tracing correlation. Option C is correct because injecting a unique request ID (correlation ID) into every log entry lets you stitch together events across distributed microservices, load balancers, and queues, enabling true end-to-end tracing correlation in a cloud-native environment where a single request fans out across many ephemeral components. Option E is correct because structured logging in JSON (or similar key-value formats) makes logs machine-readable, so log aggregators like Fluentd, Loki, or Elasticsearch can parse fields automatically, enabling reliable filtering, alerting, and correlation without brittle regex parsing of free-text lines. Option A is wrong because retaining all raw observability data indefinitely is costly and unsustainable; best practice is tiered retention with sampling, aggregation, and lifecycle policies. Option B is wrong because metrics alone lack the contextual detail needed to diagnose root causes; logs, traces, and metrics are complementary pillars of observability. Option D is wrong because randomly sampling all traces and logs indiscriminately can discard critical error and latency data; sampling should be intelligent (e.g., tail-based, error-biased) rather than uniform across everything.

Answer

Store all raw observability data indefinitely for forensic analysis

Answer

Use only metrics and avoid logs to reduce complexity

Answer

Randomly sample all traces and logs to reduce storage

Question 15

Which kubectl command would you use to view the detailed state of a pod named 'web-pod' in the 'default' namespace?

Accepted Answer

kubectl describe pod web-pod. `kubectl describe pod web-pod` retrieves a detailed, multi-section view of the pod's current state, including events, conditions, container statuses, and resource usage. This command is specifically designed for deep inspection of a Kubernetes resource, unlike `kubectl get` which shows a summary, or `kubectl logs` which shows container output.

Answer

kubectl logs web-pod

Answer

kubectl get pod web-pod

Answer

kubectl exec web-pod -- /bin/sh