PCA Observability Concepts Practice Test 2 — 15 Questions

Question 1

You are seeing 'Too many active series' in your Prometheus logs. Which action should be your first priority to address this?

Accepted Answer

Analyze the number of active series per label name.. Identifying which labels are causing the high cardinality is the standard first step to prevent OOM (Out Of Memory) crashes.

Answer

Switch to a different monitoring tool.

Answer

Disable all alerting rules.

Answer

Increase Prometheus memory limits.

Question 2

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 3

Which of these is considered a 'counter' in Prometheus?

Accepted Answer

Total number of HTTP requests processed.. A counter in Prometheus is a cumulative metric that only increases (or resets to zero on process restart), and 'total number of HTTP requests processed' is the canonical example — it monotonically grows and is typically queried with rate() or increase(). Counters are used to compute rates of events over time.

Answer

Temperature of a server room.

Answer

Average latency over 5 minutes.

Answer

Current memory usage of a process.

Question 4

What is the purpose of a Gauge metric?

Accepted Answer

To track values that fluctuate up and down.. A gauge represents a single numerical value that can arbitrarily go up and down, such as temperature or memory usage.

Answer

To track request rates.

Answer

To track job start times.

Answer

To track request durations.

Question 5

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 6

What is the primary role of the 'Alertmanager'?

Accepted Answer

To manage and route alerts generated by Prometheus.. Alertmanager is responsible for grouping, silencing, and routing alerts to external systems like PagerDuty or email.

Answer

To store long-term metric data.

Answer

To scrape metrics from targets.

Answer

To visualize metrics in dashboards.

Question 7

Why might you use an 'exporter' in Prometheus?

Accepted Answer

To bridge non-Prometheus metrics to Prometheus format.. An exporter in Prometheus is a component that exposes metrics from a system that does not natively speak the Prometheus exposition format, translating them into Prometheus-compatible metrics on an HTTP endpoint. Prometheus then scrapes that endpoint, allowing monitoring of databases, hardware, message queues, and other third-party systems that lack native /metrics support.

Answer

To increase the scrape interval.

Answer

To secure the Prometheus server.

Answer

To push logs to Prometheus.

Question 8

Which metric type would best capture the distribution of request latencies?

Accepted Answer

Histogram. A Histogram is the correct metric type for capturing the distribution of request latencies because it buckets observations into configurable ranges and exposes cumulative counters per bucket, allowing calculation of percentiles (e.g., p50, p95, p99) via histogram_quantile() in PromQL. Latency is inherently a distribution, not a single value, so bucketing is required to observe spread and tail behaviour. Histograms are also aggregatable across instances, which is essential for fleet-wide latency SLOs.

Answer

Summary

Answer

Gauge

Answer

Counter

Question 9

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 10

What is the purpose of 'labels' in Prometheus?

Accepted Answer

To identify unique time series.. Labels provide metadata to metrics, allowing for multi-dimensional querying and filtering (e.g., job='web', instance='1.2.3.4').

Answer

To store the actual data values.

Answer

To define the scrape interval.

Answer

To set the alert threshold.

Question 11

A dashboard shows a latency spike that doesn't correlate with CPU usage. What should you investigate next?

Accepted Answer

Disk I/O and network saturation.. Latency that is decoupled from CPU utilization points to a bottleneck outside of compute processing, most commonly I/O wait or network congestion. Disk I/O saturation (high await, queue depth) and network saturation (packet drops, retransmits, bandwidth limits) can both inflate request latency while CPU sits idle waiting on data. In a Prometheus/Grafana context, you would inspect node_disk_io_time_seconds_total, node_network_transmit_drop_total, or container network metrics to confirm. This is why B is the correct next investigation step.

Answer

Increase the number of replicas.

Answer

Check the memory limit.

Answer

Delete old metrics.

Question 12

What is 'Monitoring Philosophy' regarding alerts?

Accepted Answer

Alert on symptoms, not causes.. The 'Monitoring Philosophy' in Google Cloud's operations suite (formerly Stackdriver) emphasizes alerting on symptoms—user-visible issues like high latency or error rates—rather than on causes such as CPU spikes or disk I/O. This approach reduces alert noise and focuses on what actually impacts users, aligning with SRE principles. By alerting on symptoms, you avoid false positives from normal fluctuations and ensure that alerts are actionable and tied to service level objectives (SLOs).

Answer

Alert on every CPU spike.

Answer

Only alert during business hours.

Answer

Alert on every error log.

Question 13

Which tool would you pair with Prometheus to visualize the collected data?

Accepted Answer

Grafana. Grafana is the standard visualization tool paired with Prometheus. It connects to Prometheus as a data source and allows users to create dashboards, graphs, and alerts based on Prometheus metrics. Grafana's native support for PromQL and its rich visualization capabilities make it the go-to choice for visualizing Prometheus data.

Answer

Kibana

Answer

PromQL

Answer

Alertmanager

Question 14

Which component is responsible for executing queries written in PromQL?

Accepted Answer

Prometheus Server. The Prometheus server itself contains the query engine that processes PromQL expressions.

Answer

Exporter

Answer

Alertmanager

Answer

Grafana

Question 15

Which of the following describes the 'pull' model's benefit regarding service discovery?

Accepted Answer

Targets don't need to know where Prometheus is.. Prometheus can dynamically discover targets (via Kubernetes API, Consul, etc.) and automatically start scraping, removing the need to register every new pod.

Answer

Prometheus is always the first to start.

Answer

Targets push data when they are ready.

Answer

It reduces network traffic.