PCA Practice Test 2 — 30 Questions

Question 1

A developer adds a 'user_id' label to an HTTP request counter. What is the operational risk?

Accepted Answer

High cardinality will consume excessive memory.. Adding a 'user_id' label to an HTTP request counter creates a label with unbounded, per-user values. Each unique combination of label values produces a distinct time series in Prometheus, so a user_id label can generate thousands or millions of series. Prometheus holds all active series in memory (head block), so this high cardinality rapidly consumes RAM and can destabilize or crash the server.

Answer

The query speed will increase.

Answer

Prometheus will reject the metric.

Answer

The metric will stop recording.

Question 2

Which THREE of these are recommended practices for an observability strategy?

Accepted Answer

Maintain logs for granular incident analysis.. Option A is correct because logs provide the high-cardinality, event-level detail needed for granular incident analysis and root-cause investigation, complementing the aggregate view from metrics and traces. Option B is correct because alerting on symptoms (user-visible impact such as latency or error rate) rather than internal causes reduces noise and false pages, since causes can vary while the symptom reliably indicates user pain. Option E is correct because the Four Golden Signals — latency, traffic, errors, and saturation — are a widely recommended Google SRE framework for monitoring request-driven systems and catching the most important failure modes. Option C is not recommended because a zero threshold would fire alerts constantly on any nonzero value, producing alert fatigue rather than meaningful signal. Option D is not recommended because metrics are cheap and aggregatable but lose per-event context; logs and traces are still required for detailed debugging, so 'metrics for everything' is an overreach.

Answer

Always set alert thresholds to zero.

Answer

Use metrics for everything.

Question 3

Why would you choose to create a recording rule for a complex PromQL query?

Accepted Answer

To reduce dashboard query latency. Recording rules pre-calculate complex queries, making dashboards load faster by querying the pre-computed series instead of re-calculating the entire expression.

Answer

To increase metric resolution

Answer

To bypass authentication

Answer

To enable cross-server alerting

Question 4

Which TWO of the following can be configured globally?

Accepted Answer

scrape_interval. Options C (scrape_interval) and D (evaluation_interval) are correct because both are global configuration parameters in the Prometheus configuration file's top-level `global:` block, where scrape_interval sets the default interval between scraping targets and evaluation_interval sets how often alerting and recording rules are evaluated. These values apply to all scrape jobs and rule groups unless overridden at the job or group level, making them genuinely global settings. The other options do not belong: alertmanager_host is not a valid Prometheus global setting (Alertmanager targets are configured under `alerting: alertmanagers:` with host/port details), storage_path is a command-line flag (`--storage.tsdb.path`) rather than a global config option, and target_labels is not a global configuration directive (labels are applied per scrape job or via relabeling).

Answer

alertmanager_host

Answer

storage_path

Answer

target_labels

Question 5

When evaluating a PromQL query involving arithmetic operators, such as 'vector1 + vector2 * vector3', which operator has the highest precedence?

Accepted Answer

* (Multiplication). In PromQL, arithmetic operators follow standard mathematical precedence: multiplication (*), division (/), and modulo (%) bind tighter than addition (+) and subtraction (-). Therefore in 'vector1 + vector2 * vector3', the multiplication of vector2 and vector3 is evaluated first, and the result is then added to vector1. This mirrors conventional arithmetic rules rather than left-to-right evaluation.

Answer

Both have equal precedence and are evaluated left-to-right.

Answer

+ (Addition)

Answer

Precedence is determined by the order of labels.

Question 6

When using 'irate', what is the impact of choosing a range vector that is too small (e.g., [10s])?

Accepted Answer

It captures high-frequency spikes but can be volatile.. Using a very small range vector with irate, such as [10s], means irate calculates the per-second rate based on only the last two data points within that short window. This can capture rapid changes but makes the result highly sensitive to scrape timing and outliers, leading to volatile output.

Answer

It returns an error if no data points are found.

Answer

The result becomes a scalar.

Answer

The value is capped at 1.

Question 7

When using the Pushgateway, what happens if you push a metric with the same name and labels as an existing one?

Accepted Answer

It overwrites the old value. The Pushgateway overwrites the existing metric with the new value provided in the push request.

Answer

It creates a new series

Answer

It rejects the push

Answer

It adds to the existing value

Question 8

When designing a monitoring strategy, why should you avoid monitoring 'everything'?

Accepted Answer

It leads to signal noise and high resource costs.. Excessive metric collection leads to high storage costs, increased query latency, and signal-to-noise ratio degradation (alert fatigue).

Answer

Logs are always better for everything.

Answer

The network will be saturated.

Answer

Prometheus cannot handle many metrics.

Question 9

You are creating a recording rule to calculate the rate of requests over 5 minutes. Why would you prefer a recording rule over a direct dashboard query?

Accepted Answer

To reduce query latency on dashboards. Recording rules precompute expensive queries, reducing the load on Prometheus and speeding up dashboard loading times.

Answer

To bypass the retention settings of Prometheus

Answer

To increase the resolution of the data

Answer

To automatically send alerts to PagerDuty

Question 10

When configuring Alertmanager to send notifications to Slack, which block defines the routing tree?

Accepted Answer

route. In Alertmanager's configuration, the route block defines the routing tree that determines how alerts are grouped and which receiver they are sent to. It is the top-level entry point (with child routes for matching) that evaluates alert labels against matchers and dispatches notifications accordingly.

Answer

receivers

Answer

inhibit_rules

Answer

global

Question 11

Why are metric names required to follow a specific character set (e.g., alphanumeric and colons)?

Accepted Answer

For compatibility with PromQL. Prometheus metric names must match a regex to ensure they are compatible with the query language and internal storage format.

Answer

For faster scraping

Answer

To save disk space

Answer

To prevent duplicate metrics

Question 12

You are monitoring a legacy batch processing job that runs for only 30 seconds once every 24 hours. Which Prometheus component is necessary to collect these metrics?

Accepted Answer

Prometheus Pushgateway. Since the job is short-lived, Prometheus's standard scrape interval will likely miss it. The Pushgateway allows the job to push metrics before exiting.

Answer

Prometheus Exporter

Answer

Prometheus Federation

Answer

Prometheus Alertmanager

Question 13

Which file format does Prometheus use for its main configuration?

Accepted Answer

YAML. Prometheus configuration is strictly defined in YAML format.

Answer

XML

Answer

JSON

Answer

TOML

Question 14

Which THREE labels are often considered part of the default Prometheus ecosystem metrics?

Accepted Answer

le. Option B (le) is correct because it is the standard label Prometheus attaches to histogram bucket series to indicate the inclusive upper bound of each bucket (e.g., le="0.5"), and it is essential for histogram_quantile() calculations. Option D (job) is correct because Prometheus automatically adds a job label to every scraped target, derived from the scrape configuration's job_name, identifying the logical service or scrape group. Option E (instance) is correct because Prometheus automatically attaches an instance label representing the specific target endpoint (host:port) that was scraped, distinguishing individual replicas within a job. Options A (group) and C (owner) are not part of the default Prometheus ecosystem labels; they are not injected by Prometheus during scraping and are not standard conventions used by PromQL functions or service discovery metadata.

Answer

group

Answer

owner

Question 15

When performing a vector-to-vector binary operation between two instant vectors of different label sets, which modifier allows matching on a subset of common labels?

Accepted Answer

on(...). The 'on(...)' modifier in PromQL allows vector-to-vector binary operations to match on a specified subset of labels, ignoring all other labels. When two instant vectors have different label sets, 'on(label1, label2)' restricts matching to only those labels, enabling the operation to proceed. This is the correct modifier for matching on a subset of common labels.

Answer

group_left(...)

Answer

ignoring(...)

Answer

matching(...)

Question 16

Which regular expression matcher selects all time series where the status label begins with the digit 5?

Accepted Answer

http_requests_total{status=~"^5.*"}. The =~ operator combined with a regular expression starting with ^5 matches labels beginning with 5.

Answer

http_requests_total{status=@"5*"}

Answer

http_requests_total{status=^"5"}

Answer

http_requests_total{status=~"5$"}

Question 17

Which THREE of the following are components of a Prometheus alert state?

Accepted Answer

inactive. In Prometheus, an alert rule transitions through three defined states: B. inactive, meaning the alert's expression evaluates to false and no alert is active; D. pending, meaning the expression has become true but the alert has not yet been true for the configured 'for' duration; and C. firing, meaning the condition has remained true for the full 'for' duration and the alert is now actively firing and sent to Alertmanager. These three states (inactive, pending, firing) are the complete set of alert states tracked by the Prometheus alerting engine. The unmarked options A. muted and E. sleeping are not Prometheus alert states; muting is an Alertmanager concept (silences/mute timers) applied to notifications, and 'sleeping' is not a Prometheus alert state at all.

Answer

muted

Answer

sleeping

Question 18

A team is transitioning from a traditional logging system to a metrics-based monitoring approach. Which category of observability data should the team prioritize to specifically identify the 'Latency' golden signal?

Accepted Answer

Time-series metrics. The 'Latency' golden signal is one of the four golden signals (latency, traffic, errors, saturation) defined in Google's SRE book. Latency is fundamentally a time-based measurement—how long a request takes to complete. Time-series metrics are specifically designed to capture numeric values over time, making them the ideal data category for tracking latency percentiles (e.g., p50, p95, p99) and alerting on thresholds. Metrics allow efficient aggregation and long-term trend analysis, which is essential for monitoring latency as a key performance indicator.

Answer

Infrastructure events

Answer

Structured application logs

Answer

Distributed traces

Question 19

Why does the 'rate()' function in PromQL behave unexpectedly on counter resets?

Accepted Answer

It detects the reset and ignores the wrap-around.. PromQL's rate() function is specifically designed to handle counter resets: when a counter decreases (indicating a process restart or counter wrap), rate() treats the drop as a reset and extrapolates the increase across the interval, effectively ignoring the wrap-around. This is why rate() is the recommended way to compute per-second rates on counters, rather than using deriv() or manual subtraction. The function assumes the counter only increases between resets and compensates accordingly.

Answer

It returns an error.

Answer

It requires a manual offset.

Answer

It stops recording the metric.

Question 20

Which aggregation operator would you use to calculate the total sum of a metric across all instances?

Accepted Answer

sum(). The sum() aggregation operator in PromQL takes an instant vector and aggregates all matching time series into a single value by summing their current sample values. When applied across all instances of a metric (e.g., sum(node_cpu_seconds_total)), it produces the total across every series returned by the selector. This is exactly the semantics needed to compute a fleet-wide total of a metric.

Answer

avg_over_time()

Answer

total()

Answer

count()