PCA Hard Questions — 25 Difficult Questions

Question 1

Which TWO are common causes of high-cardinality in Kubernetes environments?

Accepted Answer

Using a unique transaction ID as a label.. High cardinality occurs when a metric label takes on a very large number of distinct values, multiplying the number of time series. Option B is correct because a unique transaction ID as a label creates a new series for every transaction, producing unbounded cardinality. Option C is correct because the pod name in a metric label changes with every pod restart or rollout, generating a new series per pod instance and causing cardinality to grow continuously. Options A, D, and E are not common causes of high cardinality: deployment names, cluster regions, and service names are relatively stable, low-cardinality dimensions with a limited set of values.

Answer

Using a deployment name label.

Answer

Using a cluster region label.

Answer

Using a service name label.

Question 2

You need to prevent an alert from firing if a maintenance window is active. How should you approach this in Alertmanager?

Accepted Answer

Use a Silence. Silences are the standard way to prevent specific alerts from firing during a known maintenance period.

Answer

Delete the alerting rule

Answer

Modify the routing tree

Answer

Add a 'skip' label to the rule

Question 3

Which THREE of the following are valid label matchers?

Accepted Answer

!~. In Prometheus-style label matching, the valid matchers are = (equality), != (inequality), =~ (regex match), and !~ (negative regex match), so C (!~), D (=~), and E (!=) are all correct. C (!~) is right because it selects series whose label value does not match the given regular expression, e.g. job!~"api.*". D (=~) is right because it selects series whose label value matches the regular expression, e.g. job=~"api.*". E (!=) is right because it selects series whose label value differs from the given string, e.g. job!="api". Options A (>>) and B (==) are not valid matchers: >> is not a PromQL label operator at all, and == is a comparison operator used in expressions, not a label matcher.

Answer

>>

Answer

==

Question 4

How does Prometheus handle subqueries embedded within an instant query, such as rate(http_requests_total[5m])[30m:1m]?

Accepted Answer

It runs the inner instant query at multiple evaluation timestamps over the specified range at the given resolution, returning a range vector.. Prometheus evaluates subqueries by running the inner instant query at each step of the outer range, using the specified resolution (1m) and range (30m). This produces a range vector that can then be used by outer functions like rate(). The subquery syntax [30m:1m] means evaluate the inner expression over the last 30 minutes at 1-minute intervals.

Answer

It caches the inner query results in memory for 30 minutes.

Answer

It increases the global scrape interval to 1 minute for the next 30 minutes.

Answer

It converts the range vector into a scalar through statistical interpolation.

Question 5

Which TWO of the following statements regarding PromQL subqueries are correct? (Choose two)

Accepted Answer

Subqueries allow instant vector queries to be passed as range vector inputs to functions like max_over_time().. Option B is correct because a PromQL subquery wraps an instant vector expression and evaluates it over a time range, producing a range vector that can be fed into range-vector functions such as max_over_time(), avg_over_time(), or rate(). Option C is correct because the subquery syntax is exactly [:], for example max_over_time(rate(http_requests_total[5m])[1h:1m]). Option A is wrong because subqueries do not bypass the storage engine; they still query TSDB data and typically add overhead by evaluating the inner expression at each resolution step. Option D is wrong because subqueries operate on instant vector expressions (the inner expression must return an instant vector), not exclusively on range vectors. Option E is wrong because the resolution parameter is optional; when omitted, Prometheus uses the global evaluation_interval as the default step.

Answer

Subqueries execute faster than standard instant queries because they bypass the storage engine.

Answer

Subqueries can only be executed against range vectors, never instant vectors.

Answer

The resolution parameter in a subquery is mandatory.

Question 6

You need to send critical alerts to a specific Slack channel while warning alerts go to email. Where should this routing logic be defined?

Accepted Answer

In the Alertmanager 'route' configuration. The Alertmanager 'route' configuration is where routing logic is defined. It uses a tree of routes with matchers (e.g., severity='critical') to direct alerts to specific receivers (e.g., Slack for critical, email for warning). This is the core mechanism for conditional alert routing in Prometheus-based monitoring.

Answer

In the Alertmanager 'receivers' configuration

Answer

In the Grafana 'Alerting' UI

Answer

In the Prometheus 'alerting' rule file

Question 7

In Alertmanager, what is the role of the 'continue' field in a route?

Accepted Answer

To force the alert to be sent to multiple routes. The 'continue' field in an Alertmanager route, when set to true, allows the alert to continue matching subsequent sibling routes. This means the alert can be sent to multiple receivers, effectively forcing it to be routed to multiple destinations.

Answer

To keep the alert firing after resolution

Answer

To ignore duplicate alerts

Answer

To restart the Alertmanager process

Question 8

Which TWO of the following statements about PromQL label matchers are correct? (Choose TWO)

Accepted Answer

The = operator performs an exact string match.. Option A is correct because in PromQL the '=' label matcher performs an exact string match, selecting time series whose label value is precisely equal to the provided string. Option E is correct because the '!~' operator performs a negative regular expression match, excluding series whose label value matches the given regex. Option B is incorrect because '?=' is not a valid PromQL label matcher operator. Option C is incorrect because '=~' is a positive regular expression match for label values, not a numeric comparison operator. Option D is incorrect because '==' is not a valid label selector operator in PromQL; equality matching uses '='.

Answer

The ?= operator performs fuzzy string matching.

Answer

The =~ operator is used exclusively for numeric comparisons.

Answer

The == operator is valid inside label selectors for filtering.

Question 9

You are joining an instant vector of application metrics with a static configuration instant vector containing target metadata using 'on(instance) group_right'. What does the 'group_right' modifier achieve?

Accepted Answer

It allows the right-hand side to provide more time series than the left-hand side, keeping all right-hand side series and including matched left-hand side data.. In a many-to-one or one-to-many match, group_right causes the metric on the right-hand side to be included for every matching left-hand side, keeping all labels from the right side and supplementing them.

Answer

It reverses the vector matching direction to evaluate from right to left.

Answer

It drops all labels from the left-hand side vector.

Answer

It ensures that the output contains only time series found exclusively on the right side.

Question 10

You need to calculate the 99th percentile of request latency across all instances using a Prometheus histogram metric 'http_request_duration_seconds_bucket'. Which function and setup is correct?

Accepted Answer

histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])). The histogram_quantile() function calculates the $\phi$-quantile from the buckets of a histogram metric. It requires the bucket metric and the quantile as arguments.

Answer

histogram_quantile(http_request_duration_seconds_bucket[5m], 0.99)

Answer

quantile_over_time(0.99, http_request_duration_seconds_bucket[5m])

Answer

rate(histogram_quantile(0.99, http_request_duration_seconds_bucket[5m]))

Question 11

An engineer observes a massive spike in Prometheus memory usage after introducing a new custom label that includes a unique user ID. Which observability concept is being violated?

Accepted Answer

High cardinality. High cardinality occurs when a label has a large number of unique values, such as a unique user ID, which creates a massive number of time series. This leads to increased memory usage, slower queries, and potential instability in Prometheus. The spike in memory usage directly indicates that the cardinality of the metric has exploded due to the new label.

Answer

Data retention policy

Answer

Metric saturation

Answer

Service discovery limits

Question 12

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 13

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 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

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 16

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 17

Which TWO of the following are necessary to successfully inhibit an alert in Alertmanager?

Accepted Answer

target_matchers. Inhibition requires a 'target_matchers' (the alert to be silenced) and 'source_matchers' (the alert that triggers the silence), plus common labels to correlate the two.

Answer

repeat_interval

Answer

group_wait

Answer

group_interval

Question 18

An application is emitting logs that contain '5xx' status codes when a service is unavailable. If you want to create an alert that triggers based on the rate of these errors, what is the best practice for observability?

Accepted Answer

Expose a metric incrementing on every 5xx error and alert on the rate of that metric.. Logs are useful for root cause analysis, but for alerting on rates, you should convert the error occurrence into a metric increment, as metrics are more efficient for long-term calculation and alerting.

Answer

Alert directly on the log stream using a log aggregator.

Answer

Use Prometheus to scrape the log file directly.

Answer

Increase log verbosity to trace the request until the error is resolved.

Question 19

If you are using a Histogram, what is the purpose of the '_sum' metric?

Accepted Answer

To store the sum of observations. The _sum metric provides the sum of all observed values, which allows calculating the average when combined with the _count metric.

Answer

To store the median

Answer

To store the maximum value

Answer

To store the total count

Question 20

What does the 'resolve_timeout' setting in Alertmanager do?

Accepted Answer

It determines how long to wait before sending a resolved notification. If an alert stops firing, Alertmanager waits for the resolve_timeout duration to ensure the alert has truly resolved before notifying about the resolution.

Answer

It sets the timeout for external API calls

Answer

It defines how long to store alert history

Answer

It suppresses duplicate alerts