CCNA Cloud Native Observability Questions — Page 2 of 2

Multi-Selectmedium

Which TWO of the following are valid Prometheus metric types? (Select two.)

Select 2 answers

A.Log

B.Counter

C.Event

D.Histogram

E.Trace

AnswersB, D

Counter metrics only increase monotonically, resetting solely on process restart, which satisfies Prometheus's requirement for cumulative time-series data such as request totals. This monotonic behaviour distinguishes it from gauges, which rise and fall freely, and makes Counter one of the four valid Prometheus metric types alongside Gauge, Histogram and Summary.

Why this answer

Option B (Counter) is correct because Counter is one of the four core Prometheus metric types, representing a cumulative value that only increases (or resets to zero on restart), such as http_requests_total. Option D (Histogram) is also correct because Histogram is a core Prometheus metric type that samples observations into configurable buckets and exposes _bucket, _sum, and _count series, commonly used for request durations or response sizes. The other options do not belong: Log (A) and Trace (E) are observability signal categories (logs and distributed traces) rather than Prometheus metric types, and Event (C) is not a Prometheus metric type—Prometheus has Gauge and Summary as its other two types, but neither is listed here.

Exam trap

KCNA often tests whether candidates confuse observability signal types (logs, metrics, traces) with Prometheus metric types, so options like 'Log' and 'Trace' look plausible but are not Prometheus metric primitives.

Practice this question →

MCQmedium

Which component of the metrics-server provides resource metrics like CPU and memory usage?

A.kube-apiserver

B.metrics-server

C.kubelet

D.Prometheus

AnswerB

The metrics-server aggregates kubelet Summary API data from each node and exposes it through the Metrics API, which is what serves CPU and memory usage figures. It is the component itself, not a client or storage backend, satisfying the resource-metrics requirement.

Why this answer

The metrics-server is the component that collects and provides resource metrics such as CPU and memory usage in a Kubernetes cluster. It aggregates metrics from kubelets via the Summary API and exposes them through the Kubernetes API for use by Horizontal Pod Autoscaler and kubectl top. It is the canonical source for core resource metrics in KCNA-level Kubernetes.

Exam trap

KCNA often tests the distinction between kubelet (node-level metrics source), metrics-server (cluster aggregator), and Prometheus (external monitoring) — candidates confuse the raw source with the API-serving component.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the API front end that serves requests but does not itself collect or store resource metrics — it relies on the metrics-server or other adapters. Option C is wrong because kubelet runs on each node and exposes raw cAdvisor metrics, but it is not the cluster-wide component that provides aggregated resource metrics to the API. Option D is wrong because Prometheus is a third-party monitoring system that can scrape metrics but is not the built-in Kubernetes component that supplies CPU/memory metrics to the API.

Practice this question →

MCQmedium

Which tool is specifically designed for distributed tracing and was originally developed by Uber?

A.Prometheus

B.Loki

C.Grafana

D.Jaeger

AnswerD

Jaeger was created at Uber for distributed tracing, propagating context across services to reconstruct request flows and latencies. This satisfies the stem's specific origin requirement, distinguishing it from Zipkin and from metrics-only tools such as Prometheus.

Why this answer

Jaeger is an open source distributed tracing system originally developed by Uber and later donated to the CNCF, where it became a graduated project. It is designed to monitor and troubleshoot microservices-based distributed systems by tracing requests across service boundaries. This makes Jaeger the correct answer for a tool specifically built for distributed tracing and originating from Uber.

Exam trap

KCNA often tests the specific origin and purpose of observability tools, and candidates commonly confuse Jaeger with Prometheus or Grafana because all are CNCF-related observability projects.

How to eliminate wrong answers

Option A is wrong because Prometheus is a metrics monitoring and alerting toolkit, not a distributed tracing system, although it is also a CNCF project. Option B is wrong because Loki is a log aggregation system developed by Grafana Labs, focused on logs rather than traces. Option C is wrong because Grafana is a visualization and dashboarding platform that can display tracing data but is not itself a distributed tracing backend.

Practice this question →

MCQmedium

What is the primary role of the OpenTelemetry Collector?

A.To replace Prometheus for metric collection

B.To receive, process, and export telemetry data

C.To store traces and metrics long-term

D.To generate traces for applications

AnswerB

The Collector receives telemetry through receivers, processes it with processors, and exports it via exporters, acting as a vendor-neutral pipeline. This satisfies the stem's requirement to receive, process and export telemetry data as its primary function.

Why this answer

The OpenTelemetry Collector is a vendor-agnostic component that receives telemetry data (traces, metrics, logs), processes it (e.g., batching, filtering, enriching), and exports it to one or more backends. Its primary role is to decouple instrumentation from backend systems, providing a flexible pipeline for telemetry data. It does not replace Prometheus, store data long-term, or generate traces.

Exam trap

KCNA often tests the misconception that the OpenTelemetry Collector stores or generates telemetry data, when in fact it is a pipeline component that receives, processes, and exports data to backend systems.

How to eliminate wrong answers

Option A is wrong because the Collector does not replace Prometheus; it can receive metrics from Prometheus and export them to various backends, but Prometheus remains a monitoring system with its own storage and query capabilities. Option C is wrong because the Collector does not store telemetry long-term; it forwards data to backends like Jaeger, Prometheus, or commercial APMs that handle storage. Option D is wrong because the Collector does not generate traces; traces are generated by instrumented applications using OpenTelemetry SDKs, and the Collector only processes and exports them.

Practice this question →

Multi-Selecthard

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.)

Select 2 answers

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

B.Prometheus pulls metrics from targets by scraping HTTP endpoints at regular intervals.

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

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

E.Prometheus stores data in a local time-series database optimized for append-only writes.

AnswersB, E

Prometheus uses a pull-based model, actively scraping configured targets over HTTP at defined intervals. This is a core design characteristic and is how it collects metrics from exporters, kubelets, and instrumented applications. The statement accurately reflects the scraping mechanism, so it is one of the correct descriptions of how Prometheus operates in a Kubernetes observability stack.

Why this answer

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.

Exam trap

The trap here is assuming that Prometheus is a distributed system with automatic cluster-wide discovery, when it is actually a single-node scraper that requires explicit configuration and stores data locally.

Practice this question →

MCQeasy

A Kubernetes operator wants to view real-time CPU and memory usage of pods and nodes in a cluster using kubectl top. Which component must be installed and running in the cluster for this command to work?

A.Prometheus

B.kube-state-metrics

C.metrics-server

D.OpenTelemetry Collector

AnswerC

The metrics-server is a cluster-wide aggregator of resource usage data. It collects metrics from Kubelets and exposes them via the Metrics API, which kubectl top uses to display current CPU and memory usage for pods and nodes. Without metrics-server, kubectl top returns an error indicating that metrics are not available, so it is the required component.

Why this answer

kubectl top retrieves metrics from the Kubernetes Metrics API, which is implemented by the metrics-server. The metrics-server collects resource usage data from Kubelets and makes it available through the API. Other tools like Prometheus or kube-state-metrics serve different purposes and do not power kubectl top, so metrics-server is the correct component to install.

Exam trap

The trap here is confusing general monitoring tools like Prometheus with the specific component that backs the kubectl top command.

Practice this question →

MCQhard

A company defines an SLO that 99.9% of requests to a service should complete in under 200ms. Which metric type is used to measure this SLO?

A.Summary

B.Histogram

C.Gauge

D.Counter

AnswerB

Histograms bucket observations into configurable ranges, so the proportion of requests completing under 200ms can be calculated from the relevant bucket counts. This satisfies the SLO's latency threshold, which a gauge or counter cannot express as a distribution.

Why this answer

A histogram is the Prometheus metric type designed to capture the distribution of observations (like request durations) into configurable buckets, and it automatically exposes _bucket, _sum, and _count series. This allows you to compute quantiles (e.g., the 99.9th percentile latency) and ratios such as 'fraction of requests under 200ms' using PromQL, which is exactly what the SLO requires.

Exam trap

The trap is choosing Summary because it also measures latency distributions; the key differentiator is that Summaries cannot be aggregated across instances, which breaks service-wide SLO calculations.

How to eliminate wrong answers

Option A is wrong because a Summary also captures distributions and quantiles, but quantiles are pre-computed client-side and cannot be aggregated across instances — making it unsuitable for a service-level SLO that spans multiple pods. Option C is wrong because a Gauge represents a single instantaneous value that can go up or down (e.g., temperature, queue depth), not a distribution of request durations. Option D is wrong because a Counter is a monotonically increasing value (e.g., total requests), which cannot express '99.9% under 200ms' without a distribution.

Practice this question →

MCQmedium

A DevOps team wants to collect and forward logs from all nodes in a Kubernetes cluster to a centralized logging backend. Which component is specifically designed for lightweight log collection and forwarding?

A.Fluent Bit

B.Prometheus

C.Jaeger

D.Grafana

AnswerA

Fluent Bit is a lightweight, low-memory log processor and forwarder, typically deployed as a DaemonSet so one pod runs per node. This satisfies the stem's requirement for lightweight node-level log collection forwarding to a centralised backend.

Why this answer

Fluent Bit is a lightweight log processor and forwarder, ideal for Kubernetes nodes.

Practice this question →