Free Practice Questions for Linux Foundation PCA Exam

In Prometheus, arule groupis a logical collection ofrecording and alerting rulesthat areevaluated sequentiallyat a specified interval. Rule groups are defined in YAML files under the groups: key, with each group containing a name, an interval, and a list of rules.

For example:

groups:

- name: example

interval: 1m

rules:

- record: job:http_inprogress_requests:sum

expr: sum(http_inprogress_requests) by (job)

All rules in a group share the same evaluation schedule and are executed one after another. This ensures deterministic order, especially when one rule depends on another’s result.

Following Prometheus’smetric naming conventions, every metric should indicate:

Whatit measures (the quantity or event).

The unitof measurement inbase SI unitsas a suffix.

Since the metric measuresresponse size, the base unit isbytes. Therefore, the correct and compliant metric name is:

grpc_response_size_bytes

This clearly communicates that it measures gRPC response payload sizes expressed in bytes.

The _bytes suffix is the Prometheus-recommended unit indicator for data sizes. The other options violate naming rules:

_total is reserved for counters.

_sum is used internally by histograms or summaries.

Omitting the unit (grpc_response_size) is discouraged, as it reduces clarity.

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.

ThePrometheus naming conventionfor metrics that exposebuild or version informationabout an application binary uses the _info suffix. The standard pattern is:

_build_info

This metric typically includes constant labels such as version, revision, branch, and goversion to describe the build environment.

For example:

app_build_info{version="1.2.3", revision="abc123", goversion="go1.22"} 1

This approach follows the official Prometheus instrumentation guidelines, where metrics ending in _info convey metadata or constant characteristics about the running process.

The other options do not conform to the Prometheus best practice of suffix-based semantic naming.

When Prometheus targets arebehind firewalls or NATand cannot be reached directly by the Prometheus server’s pull mechanism, the recommended component to use isPushProx.

PushProxworks by reversing the usual pull model. It consists of aPushProx Proxy(accessible by Prometheus) andPushProx Clients(running alongside the targets). The clients establish outbound connections to the proxy, which allows Prometheus to “pull” metrics indirectly. This approach bypasses network restrictions without compromising the Prometheus data model.

Unlike the Pushgateway (which is used for short-lived batch jobs, not network-isolated targets), PushProx maintains the Prometheus “pull” semantics while accommodating environments where direct scraping is impossible.

Themin_over_time()function in PromQL returns theminimum sample valueobserved within the specified time range for each time series.

In the given data:

For up{instance="localhost"}, all samples are 1. The minimum value over 5 minutes is therefore1.

For up{instance="server1"}, the sequence is 1 0 0 0 0. The minimum observed value is0.

Thus, the query min_over_time(up[5m]) returns two series — one per instance:

{instance="localhost"} 1

{instance="server1"} 0

This query is commonly used to check uptime consistency. If the minimum value over the time window is 0, it indicates at least one scrape failure (target down).

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.

According to Prometheus naming rules,metric names must match the regex [a-zA-Z_:][a-zA-Z0-9_:]*. This means metric names must begin with a letter, underscore, or colon, and can only contain letters, digits, and underscores thereafter.

The valid metric name among the options isgo_goroutines, which follows all these rules. It starts with a letter (g), uses underscores to separate words, and contains only allowed characters.

By contrast:

go routines is invalid because it contains aspace.

go.goroutines is invalid because it contains adot(.), which is reserved for recording rule naming hierarchies, not metric identifiers.

99_goroutines is invalid because metric namescannot start with a number.

Following these conventions ensures compatibility with PromQL syntax and Prometheus’ internal data model.

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.