Free Practice Questions for Linux Foundation PCA Exam

Thedelta()function in PromQL calculates thedifference between the first and last samplesin a range vector over a specified time window. This function is primarily used withgauge metrics, as they can move both up and down, and delta() captures that net change directly.

For example, if a gauge metric like node_memory_Active_bytes changes from 1000 to 1200 within a 5-minute window, delta(node_memory_Active_bytes[5m]) returns 200.

Unlike rate() or increase(), which are designed for monotonically increasing counters, delta() is ideal for metrics representing resource levels, capacities, or instantaneous measurements that fluctuate over time.

Prometheus metric naming best practices require thatevery metric name include a unit suffixthat indicates the measurement type, where applicable. The unit should follow the base name, separated by an underscore, and must usebase SI units(for example, _seconds, _bytes, _total, etc.).

In the case of http_requests_total, while the metric correctly includes the _total suffix—indicating it is a counter—it lacks abase unit of measurement(such as time, bytes, or duration). However, forevent counters, _total is itself considered the unit, representing “total occurrences” of an event. Thus, the naming would be acceptable in strict Prometheus terms, but if this metric were measuring something like duration, size, or latency, then including a specific unit would be mandatory.

However, since the question implies that the missing unit is the issue and not the label schema, the expected answer aligns with ensuring metric names convey measurable units when applicable.

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.

By default, Prometheus stores its time series data in alocal, embedded Time Series Database (TSDB)on disk. The data is organized in block files under the data/ directory inside Prometheus’s storage path.

Each block typically covers two hours of data, containing chunks, index, and metadata files. Older blocks are compacted and deleted based on retention settings.

The metric prometheus_tsdb_lowest_timestamp_seconds provides theoldest stored sample timestampin Prometheus’s local TSDB (in Unix epoch seconds). To determine theage or approximate dateof this timestamp, you compare it with thecurrent time(using time() in PromQL).

The expression:

(time() - prometheus_tsdb_lowest_timestamp_seconds) / 86400

converts the difference between the current time and the oldest timestamp fromseconds into days(1 day = 86,400 seconds). This gives the number of days since the earliest sample was stored, allowing you to infer the time range and approximate month manually.

The other options are invalid because PromQL does not support direct date formatting (format_date) or month() extraction functions.

In Prometheus, histograms and summaries expose metrics with _sum and _count suffixes to represent total accumulated values and sample counts, respectively. To compute theaverage request durationover 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.

In Prometheus alerting rules, you can dynamically reference label values inannotationsandlabelsusing template variables. Each alert has access to its labels via the variable $labels, which allows direct insertion of label data into alert messages or descriptions.

To include the value of the instance label dynamically in the description, replace the placeholder INSTANCE_NAME_HERE with:

description: "Instance {{$labels.instance}} down"

or equivalently:

description: "Instance $labels.instance down"

Both forms are valid — the first follows Go templating syntax and is the recommended format.

This ensures that when the alert fires, the instance label (e.g., a hostname or IP) is automatically included in the message, producing outputs like:

Instance 192.168.1.15:9100 down

Options B, C, and D are invalid because $value, $expr, and $metric are not recognized context variables in alert templates.

Inhibition rulesin Prometheus’sAlertmanagerare used tosuppress (mute) alertsthat would otherwise be redundant when a higher-priority or related alert is already active. This feature helps avoid alert noise and ensures that operators focus on the root cause rather than multiple cascading symptoms.

For example, if a “DatacenterDown” alert is firing, inhibition rules can mute all “InstanceDown” alerts that share the same datacenter label, preventing redundant notifications. Inhibition is configured in the Alertmanager configuration file under the inhibit_rules section.

Each rule defines:

Asource match(the alert that triggers inhibition),

Atarget match(the alert to mute), and

Amatch condition(labels that must be equal for inhibition to apply).

Only when the source alert is active are the target alerts silenced.