PCA Instrumentation And Exporters Practice Test 3 — 15 Questions

Question 1

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 2

What is the recommended approach for metrics that only need to be exposed periodically?

Accepted Answer

Expose consistently. The recommended approach is to expose metrics consistently, because Prometheus is a pull-based system that scrapes targets at fixed intervals regardless of whether the underlying value has changed. Consistently exposing the metric ensures that every scrape returns a current value, preserving continuity in the time series and enabling reliable rate(), delta(), and alerting calculations. Intermittent exposure creates gaps that break PromQL functions and trigger false staleness.

Answer

Only export when changing

Answer

Use Pushgateway

Answer

Delete the metric

Question 3

Which THREE of the following are valid metric types in Prometheus?

Accepted Answer

Gauge. Prometheus defines exactly four core metric types, and three of them appear here. Option A, Gauge, is correct because a gauge represents a value that can arbitrarily go up or down, such as temperature or current memory usage. Option C, Counter, is correct because a counter is a cumulative metric that only increases (or resets to zero on restart), typically used for counts like total requests served. Option D, Histogram, is correct because a histogram samples observations and counts them into configurable buckets, exposing _bucket, _sum, and _count series for distributions and quantile estimation. Option B, Set, is not a Prometheus metric type; it is not part of the client library metric primitives (the fourth valid type is Summary, which is absent here). Option E, Queue, is also not a metric type; it is merely a data structure concept and has no corresponding Prometheus instrumentation primitive.

Answer

Set

Answer

Queue

Question 4

What does the `_count` suffix denote in a summary or histogram?

Accepted Answer

The total number of samples. The _count suffix represents the total number of observations made for that specific metric.

Answer

The maximum value

Answer

The sum of values

Answer

The current bucket value

Question 5

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 6

Which tool would you use to monitor the availability of a website from various geographic locations?

Accepted Answer

blackbox_exporter. The blackbox_exporter is the standard tool for probing the availability of HTTP, TCP, or DNS services.

Answer

node_exporter

Answer

Pushgateway

Answer

Prometheus API

Question 7

When instrumenting an application, why is it recommended to use a fixed set of label names?

Accepted Answer

To avoid cardinality explosion. Dynamically changing label names creates new time series, which can lead to cardinality explosion and storage issues.

Answer

To increase resolution

Answer

For better formatting

Answer

To simplify coding

Question 8

Which TWO of the following are common reasons to use the Pushgateway?

Accepted Answer

For batch jobs that run for seconds. Option A is correct because short-lived batch jobs that run only for seconds may finish before Prometheus can scrape them, so they push their final metrics to the Pushgateway where Prometheus can collect them later. Option E is correct because when the application or its metrics endpoint cannot be reached directly by the Prometheus server—due to network segmentation, firewalls, or NAT—the application can push metrics to a Pushgateway that Prometheus is able to scrape. Option B is wrong because long-running servers are the standard use case for direct Prometheus scraping, not the Pushgateway. Option C is wrong because the Pushgateway is a metrics cache, not a reverse proxy for arbitrary traffic. Option D is wrong because Prometheus and the Pushgateway store metrics in their own time-series format, not in SQL databases.

Answer

To monitor long-running servers

Answer

To act as a reverse proxy

Answer

When metrics need to be stored in SQL

Question 9

Which TWO of the following are true about the node_exporter?

Accepted Answer

It runs on port 9100 by default. Option C is correct because node_exporter's default listen address is :9100, so Prometheus scrapes host metrics from http://<host>:9100/metrics unless overridden with --web.listen-address. Option E is correct because node_exporter's collectors read from /proc and /sys on Linux to expose kernel-level metrics such as node_cpu_seconds_total, node_memory_MemAvailable_bytes, node_load1, and node_disk_io_time_seconds_total. Option A is wrong because node_exporter is a host/OS metrics exporter, not a database exporter; database monitoring uses exporters like mysqld_exporter, postgres_exporter, or oracledb_exporter. Option B is wrong because node_exporter is a passive exporter that only responds when Prometheus scrapes its /metrics endpoint; active probing is done by blackbox_exporter. Option D is wrong because node_exporter is designed for Unix-like systems (Linux, BSD, macOS) and does not support Windows out of the box; Windows host metrics require windows_exporter.

Answer

It is for database monitoring

Answer

It performs active monitoring

Answer

It supports Windows out of the box

Question 10

Which TWO of the following are true regarding Prometheus Histograms?

Accepted Answer

They are cumulative. Option C is correct because Prometheus histograms expose cumulative buckets: each bucket with an upper bound le counts all observations less than or equal to that bound, so the counts are monotonically increasing across buckets. Option D is correct because those cumulative bucket counters are plain time series that can be summed across instances with PromQL aggregation operators such as sum by (le), allowing quantiles to be estimated over aggregated data. Option A is wrong because quantile estimation from histograms is done server-side by PromQL's histogram_quantile() function, not client-side. Option B is wrong because histograms rely on the le label to identify bucket boundaries. Option E is wrong because histograms are their own metric type used for distributions, not a variant of Gauges.

Answer

They calculate quantiles client-side

Answer

They do not use labels

Answer

They are only for Gauges

Question 11

Which TWO of the following are true about the Blackbox exporter?

Accepted Answer

It supports HTTP, TCP, and DNS. Option A is correct because the Blackbox exporter performs active probes over protocols such as HTTP/HTTPS, TCP, ICMP, and DNS, exposing results like probe_success and probe_duration_seconds. Option C is correct because the Blackbox exporter is driven by a target list defined in its configuration (e.g., under modules and targets in blackbox.yml or via relabeling in Prometheus), since it needs to know which endpoints to probe. Option B is wrong because the Blackbox exporter is not a database exporter; database metrics are typically collected by dedicated exporters such as mysqld_exporter or postgres_exporter. Option D is wrong because the Blackbox exporter does not instrument application code; that is the role of client libraries or agents like the Prometheus client libraries. Option E is wrong because the Blackbox exporter is an active prober that initiates connections, not a passive collector that only scrapes already-exposed metrics.

Answer

It is the only exporter for databases

Answer

It automatically instruments application code

Answer

It is a passive metric collector

Question 12

Which THREE components are typically involved in the standard Prometheus instrumentation and scraping process?

Accepted Answer

Client library. The standard Prometheus instrumentation and scraping process involves three core components: client libraries (option B), which are used to instrument application code and expose custom metrics via an HTTP endpoint in the Prometheus exposition format; exporters (option D), which translate metrics from third-party systems (e.g., node_exporter, mysqld_exporter) into that same exposition format; and the Prometheus server (option E), which periodically scrapes those HTTP endpoints, stores the time-series data in its TSDB, and evaluates alerting/recording rules. Grafana (option A) is only a visualization layer that queries Prometheus via PromQL and is not part of instrumentation or scraping. Alertmanager (option C) handles alert routing, grouping, and notification after Prometheus evaluates rules, so it is not involved in the instrumentation/scraping pipeline itself.

Answer

Grafana

Answer

Alertmanager

Question 13

Which THREE of the following are standard ways to handle Prometheus metrics?

Accepted Answer

Use official client libraries. Option B is correct because Prometheus provides official client libraries (for Go, Java, Python, Ruby, etc.) that instrument application code to expose metrics on an HTTP /metrics endpoint in the Prometheus exposition format, which is the canonical way to add custom instrumentation. Option C is correct because the node_exporter textfile collector reads .prom files from a specified directory (--collector.textfile.directory) and exposes their contents as metrics, allowing scripts or batch jobs to publish custom metrics without writing a full exporter. Option E is correct because community-supported exporters (e.g., mysqld_exporter, blackbox_exporter, redis_exporter) are standard, pre-built components that translate a third-party system's metrics into Prometheus format for scraping. Option A is wrong because Prometheus stores metrics in its own TSDB and there is no supported workflow for directly editing its on-disk files; ingestion happens via scraping or the remote-write API. Option D is wrong because writing metrics to a central database is not a Prometheus-native pattern—Prometheus itself is the time-series database, and external storage is handled via remote write/read integrations rather than direct database writes.

Answer

Directly update Prometheus files on disk

Answer

Write metrics to a central database

Question 14

Which THREE of the following are key design considerations when creating a custom exporter?

Accepted Answer

Expose metrics in Prometheus text format. Option B is correct because Prometheus scrapes metrics over HTTP from a /metrics endpoint that must be encoded in the Prometheus text exposition format (or OpenMetrics), so a custom exporter must expose metrics in that format to be consumable. Option C is correct because each unique label value combination creates a separate time series, so high-cardinality labels (e.g., user IDs, request IDs) explode memory and storage usage in Prometheus and must be avoided. Option D is correct because the exporter is scraped on every scrape_interval, so it must respond quickly and efficiently (e.g., cache expensive computations, avoid blocking calls) to prevent scrape timeouts and missed samples. Option A is wrong because exporters should expose current metrics continuously for each scrape rather than only once a day, and Option E is wrong because Prometheus does not ingest JSON as its native metric format—it requires the text-based exposition format.

Answer

Only export metrics once a day

Answer

Use JSON for metric output

Question 15

Which THREE of the following are true about the Prometheus Text Exposition Format?

Accepted Answer

It is line-oriented. It is line-oriented, supports comments starting with #, and each metric line contains the name, optional labels, and value.

Answer

It is a binary protocol

Answer

It requires an XML schema