Linux Foundation Prometheus Certified Associate PCA Exam Practice Test

Answer : C

Deduplication in Alertmanager ensures that identical alerts from multiple Prometheus servers or rule evaluations do not trigger duplicate notifications.

Alertmanager compares alerts based on their labels and fingerprints; if an alert with identical labels already exists, it merges or refreshes the existing one instead of creating a new notification.

This mechanism is essential in high-availability setups where multiple Prometheus instances monitor the same targets.

Answer : C

The Prometheus Node Exporter is a core system-level exporter that exposes hardware and operating system metrics from *nix-based hosts. It collects metrics such as CPU usage, memory, disk I/O, filesystem space, network statistics, and load averages.

It runs as a lightweight daemon on each host and exposes metrics via an HTTP endpoint (default: :9100/metrics), which Prometheus scrapes periodically.

Key clarification:

It does not instrument applications (A).

It does not collect metrics directly from application HTTP endpoints (B).

It is unrelated to HTTP probing tasks --- those are handled by the Blackbox Exporter (D).

Thus, the correct use of the Node Exporter is to collect and expose hardware and OS-level metrics for Prometheus monitoring.

Extracted and verified from Prometheus documentation -- Node Exporter Overview, Host-Level Monitoring, and Exporter Usage Best Practices sections.

Answer : B

The max operator in PromQL is an aggregation operator, not a binary vector matching operator. Therefore, the valid syntax for aggregation uses by() or without(), not on().

max by (instance) up Valid; aggregates maximum values per instance.

max without (instance) up and max without (instance, job) up Valid; aggregates over all labels except those listed.

max on (instance) (up) Invalid; the keyword on() is only valid in binary operations (e.g., +, -, and, or, unless), where two vectors are being matched on specific labels.

Hence, max on (instance) (up) is a syntax error in PromQL because on() cannot be used directly with aggregation operators.

Verified from Prometheus documentation -- Aggregation Operators, Vector Matching -- on()/ignoring(), and PromQL Language Syntax Reference sections.

Answer : B

The Grafana Heatmap panel is best suited for visualizing histogram metrics collected from Prometheus. Histograms provide bucketed data distributions (e.g., request durations, response sizes), and the heatmap effectively displays these as a two-dimensional density chart over time.

In Prometheus, histogram metrics are exposed as multiple time series with the _bucket suffix and the label le (less than or equal). Grafana interprets these buckets to create visual bands showing how frequently different value ranges occurred.

Counters, gauges, and info metrics do not have bucketed distributions, so a heatmap would not produce meaningful output for them.

Verified from Grafana documentation -- Heatmap Panel Overview, Visualizing Prometheus Histograms, and Prometheus documentation -- Understanding Histogram Buckets.

Answer : D

Symptom-based alerting focuses on user-visible problems or service-impacting symptoms rather than low-level resource metrics. In Prometheus and Site Reliability Engineering (SRE) practices, alerts should signal conditions that affect users' experience --- such as high latency, request failures, or service unavailability --- instead of merely reflecting internal resource states.

Among the options, API latency directly represents the performance perceived by end users. If API response times increase, it immediately impacts user satisfaction and indicates a possible service degradation.

In contrast, metrics like disk space, CPU usage, or database memory utilization are cause-based metrics --- they may correlate with problems but do not always translate into observable user impact.

Prometheus alerting best practices recommend alerting on symptoms (via RED metrics --- Rate, Errors, Duration) while using cause-based metrics for deeper investigation and diagnosis, not for immediate paging alerts.

Verified from Prometheus documentation -- Alerting Best Practices, Symptom vs. Cause Alerting, and RED/USE Monitoring Principles sections.

Answer : A

In Prometheus, histograms and summaries expose metrics with _sum and _count suffixes to represent total accumulated values and sample counts, respectively. To compute the average request duration over a given time window (for example, 5 minutes), you divide the rate of increase of _sum by the rate of increase of _count:

\text{Average duration} = \frac{\text{rate(http_request_duration_seconds_sum[5m])}}{\text{rate(http_request_duration_seconds_count[5m])}}

Here,

http_request_duration_seconds_sum represents the total accumulated request time, and

http_request_duration_seconds_count represents the number of requests observed.

By dividing these rates, you obtain the average request duration per request over the specified time range.

Extracted and verified from Prometheus documentation -- Querying Histograms and Summaries, PromQL Rate Function, and Metric Naming Conventions sections.

Answer : A

In PromQL, the offset modifier allows you to query metrics as they were at a past time relative to the current evaluation. To retrieve the value of node_memory_MemAvailable_bytes as it was 10 minutes ago, you place the offset keyword inside the aggregation function's argument, not after it.

The correct query is:

sum(node_memory_MemAvailable_bytes offset 10m)

This computes the total available memory across all instances, based on data from exactly 10 minutes in the past.

Placing offset after the aggregation (as in option B) is syntactically invalid because modifiers apply to instant and range vector selectors, not to complete expressions.

Verified from Prometheus documentation -- PromQL Evaluation Modifiers: offset, Aggregation Operators, and Temporal Query Examples.