PCA Prometheus Certified Associate Exam Questions and Answers

Themaxoperator in PromQL is anaggregation operator, not abinary 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 inbinary 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.

The fundamental difference betweenPrometheus client librariesandexporterslies inhowandwherethey are used.

Client librariesare integrated directly into theapplication’s codebase. They allow developers toinstrumenttheir own code to define and expose custom metrics. Prometheus provides official client libraries for multiple languages, including Go, Java, Python, and Ruby.

Exporters, on the other hand, arestandalone processesthat run alongside the applications or systems they monitor. They use client libraries internally to collect and expose metrics from software that cannot be instrumented directly (e.g., operating systems, databases, or third-party services). Examples include the Node Exporter (for system metrics) and MySQL Exporter (for database metrics).

Thus, exporters are typically used forexternal systems, while client libraries are used forself-instrumented applications.

In Prometheus, the partbefore the curly braces {}represents themetric name. Therefore, in the metric api_http_requests_total{method="POST", handler="/messages"}, the term api_http_requests_total is themetric name. Metric names describe the specific quantity being measured — in this example, the total number of HTTP requests received by an API.

The portion within the braces defineslabels, which provide additional dimensions to the metric. Here, method="POST" and handler="/messages" are labels describing request attributes. The metric name should follow Prometheus conventions: lowercase letters, numbers, and underscores only, and ending in _total for counters.

This naming scheme ensures clarity and standardization across instrumented applications. The metric type (e.g., counter, gauge) is declared separately in the exposition format, not within the metric name itself.

The key difference between acounterand agaugein Prometheus lies in how their values change over time. Acounteris a cumulative metric thatonly increases—it resets to zero only when the process restarts. Counters are typically used for metrics like total requests served, bytes processed, or errors encountered. You can derive rates of change from counters using functions like rate() or increase() in PromQL.

Agauge, on the other hand, represents a metric that cango up and down. It measures values that fluctuate, such as CPU usage, memory consumption, temperature, or active session counts. Gauges provide a snapshot of current state rather than a cumulative total.

This distinction ensures proper interpretation of time-series trends and prevents misrepresentation of one-time or fluctuating values as cumulative metrics.

Therate()function calculates theaverage per-second rate of increaseof a counter over the specified range. It smooths out short-term fluctuations and adjusts for counter resets.

Example:

rate(http_requests_total[5m])

returns the number of requests per second averaged over the last five minutes. This function is frequently used in dashboards and alerting expressions.

Prometheus supports integration withmultiple Alertmanager instancesfor redundancy and high availability. The alerting section of the Prometheus configuration file (prometheus.yml) allows specifyinga list of Alertmanager targets, enabling Prometheus to send alerts to several Alertmanager nodes simultaneously.

There isno hard-coded limiton the number of Alertmanagers that can be added. The typical best practice is to runa minimum of three Alertmanagersin a clustered setup to achieve fault tolerance and ensure reliable alert delivery, but Prometheus can be configured withmore than threeif desired.

Each Alertmanager node in the cluster communicates state information (active, silenced, inhibited alerts) with its peers to maintain consistency.

In PromQL, range vector functions like max_over_time() compute an aggregate value (in this case, themaximum) over all samples within a specified time range. The functionignores NaN (Not-a-Number) valueswhen computing the result.

Given the range vector foo[5m] containing samples [1, 1, NaN], the maximum value among the valid numeric samples is 1. Therefore, max_over_time(foo[5m]) returns 1.

Prometheus functions handle missing or invalid data points gracefully—ignoring NaN ensures stable calculations even when intermittent collection issues or resets occur. The function only errors if the selector is syntactically invalid or if no numeric samples exist at all.

Theincrease()function computes thetotal increase in a counter metricover a specified range vector. It accounts for counter resets and only measures the net change in the counter’s value during the time window.

Example:

increase(http_requests_total[5m])

This query returns how many HTTP requests occurred in the last five minutes. Unlike rate(), which provides a per-second average rate, increase() gives theabsolute number of increments.

Thederiv()function in PromQL calculates theper-second derivativeof a time series using linear regression over the provided time range. It estimates theinstantaneous rate of changefor metrics that can both increase and decrease — which are typicallygauges.

Because counters can only increase (except when reset), rate() or increase() functions are more appropriate for them. deriv() is used to identify trends in fluctuating metrics like CPU temperature, memory utilization, or queue depth, where values rise and fall continuously.

In contrast,summariesandhistogramsconsist of multiple sub-metrics (e.g., _count, _sum, _bucket) and are not directly suited for derivative calculation without decomposition.

According toPrometheus metric naming conventions, a metric name must clearly describewhat is being measuredand include aunit suffixthat specifies the base unit of measurement, following SI standards. For durations, the suffix _seconds is mandatory.

Therefore, the correct and standards-compliant name for a metric tracking HTTP request duration is:

http_request_duration_seconds

This name communicates:

http_request→ the subject being measured (HTTP requests),

duration→ the aspect being measured (the latency or time taken),

_seconds→ the unit of measurement (seconds).

This metric name typically corresponds to ahistogram or summary, exposing submetrics such as _count, _sum, and _bucket. These represent the number of observations, total duration, and distribution across time buckets respectively.

Options A, B, and C fail to fully comply with Prometheus naming standards — they either omit the http_ prefix, use invalid separators (dots), or lack the required unit suffix.

Metamonitoringrefers tomonitoring the monitoring system itself—ensuring that Prometheus, Alertmanager, exporters, and dashboards are functioning properly. In other words, it’s the observability of your observability stack.

This practice helps detect issues such as:

Prometheus not scraping targets,

Alertmanager being unreachable,

Exporters not exposing data, or

Storage being full or corrupted.

Without metamonitoring, an outage in the monitoring system could go unnoticed, leaving operators blind to actual infrastructure problems. A common approach is to usea secondary Prometheus instance(or external monitoring service) to monitor the health metrics of the primary Prometheus and related components.

The most widely usedopen-source visualization and dashboarding platformfor Prometheus data isGrafana. Grafana provides native integration with Prometheus as a data source, allowing users to createreal-time, interactive dashboardsusing PromQL queries.

Grafana supports advanced visualization panels (graphs, heatmaps, gauges, tables, etc.) and enables users to design custom dashboards to monitor infrastructure, application performance, and service-level objectives (SLOs). It also provides alerting capabilities that can complement or extend Prometheus’s own alerting system.

WhileKibanais part of the Elastic Stack and focuses on log analytics,Thanosextends Prometheus for long-term storage and high availability, andLokiis a log aggregation system. None of these tools serve as the primary dashboarding solution for Prometheus metrics the way Grafana does.

Grafana’s seamless Prometheus integration and templating support make it thede facto standard visualization toolin the Prometheus ecosystem.

In Prometheus, thehistogram_quantile()function is specifically designed to computequantiles (such as tp90, tp95, or tp99)from histogram bucket data. A histogram metric records cumulative bucket counts for observed values under specific thresholds (le label).

The function works by interpolating between buckets based on the target quantile. For example, to compute the 90th percentile latency from a histogram named http_request_duration_seconds_bucket, you would use:

histogram_quantile(0.9, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

Here, 0.9 represents the tp90 quantile, and rate() converts counter increments into per-second rates.

Other options are incorrect:

histogram() is not a valid PromQL function.

predict_linear() forecasts future values of a time series.

avg_over_time() computes a simple average over a time window, not quantiles.

In PromQL, theoffset modifierallows you to query metricsas they were at a past timerelative to the current evaluation. To retrieve the value of node_memory_MemAvailable_bytes as it was10 minutes ago, you place the offset keywordinside 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 toinstant and range vector selectors, not to complete expressions.

To calculate a percentile (e.g., 95th percentile) from histogram data in Prometheus, the correct function ishistogram_quantile(). It estimates quantiles based on cumulative bucket counts.

Example:

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

This computes the 95th percentile request duration across all observed instances over the last 5 minutes.