PCA Prometheus Fundamentals Practice Test 4 — 15 Questions

Question 1

Which THREE of the following are valid Prometheus TSDB file types?

Accepted Answer

chunks. Option A (chunks) is correct because Prometheus stores compressed time-series samples in chunk files (e.g., 000001) within each block directory in its TSDB. Option C (index) is correct because each TSDB block contains an index file that maps series labels to their chunk locations, enabling efficient lookups. Option E (wal) is correct because Prometheus uses a write-ahead log (the wal directory with segment files like 00000000) to durably record incoming samples before they are compacted into persistent blocks. Options B (sql) and D (json) are not valid Prometheus TSDB file types: Prometheus does not use SQL database files for its storage engine, and JSON is used only for configuration, API responses, and exposition formats, not as an internal TSDB file format.

Answer

sql

Answer

json

Question 2

Which TWO of the following are valid ways to configure target discovery in Prometheus?

Accepted Answer

dns_sd_configs. Option D, dns_sd_configs, is correct because Prometheus natively supports DNS-based service discovery, allowing it to periodically query A, AAAA, or SRV records to discover targets dynamically. Option E, file_sd_configs, is correct because Prometheus can read target lists from JSON or YAML files on disk and automatically reload them when the files change, making it a valid and commonly used discovery mechanism. The other options are not valid: ftp_sd_configs (A), sql_sd_configs (B), and ldap_sd_configs (C) are not service discovery integrations implemented in Prometheus; Prometheus supports mechanisms such as static_configs, dns_sd_configs, file_sd_configs, and cloud/container SD configs like kubernetes_sd_configs, consul_sd_configs, and ec2_sd_configs, but not FTP, SQL, or LDAP discovery.

Answer

ftp_sd_configs

Answer

sql_sd_configs

Answer

ldap_sd_configs

Question 3

Which TWO of the following are core responsibilities of the Prometheus server?

Accepted Answer

Evaluating rules. Option E is correct because the Prometheus server's primary function is to actively scrape (pull) time-series metrics from instrumented targets over HTTP at configured intervals, storing them in its local TSDB. Option C is correct because the Prometheus server evaluates recording rules and alerting rules against the scraped data; recording rules precompute new time series, and alerting rules generate alerts that are pushed to Alertmanager. Option A is not a Prometheus responsibility—Prometheus only forwards firing alerts to Alertmanager, which handles notification routing and integrations such as SMS or email. Option B is incorrect because the Prometheus server exposes only a basic expression browser, while rich dashboards are provided by external tools like Grafana. Option D is incorrect because Prometheus has no built-in user authentication or authorization; access control is typically handled by a reverse proxy or an identity-aware proxy in front of it.

Answer

Sending SMS alerts

Answer

Hosting the dashboard UI

Answer

Managing user auth

Question 4

Which THREE of the following metrics are automatically added to all scraped targets?

Accepted Answer

up. Option B, up, is correct because Prometheus automatically synthesizes this metric for every scrape target, reporting 1 if the target was reachable and scraped successfully and 0 otherwise. Option D, scrape_samples_scraped, is correct because Prometheus automatically records the number of samples exposed by the target during each scrape. Option E, scrape_duration_seconds, is correct because Prometheus automatically measures and exposes the duration of each scrape in seconds. Options A and C, cpu_usage and memory_usage, are not automatically added by Prometheus; such host or application metrics must be exposed by the target itself (for example, via node_exporter or a client library) and are not synthesized by the scrape process.

Answer

cpu_usage

Answer

memory_usage

Question 5

Which TWO of the following are valid Alertmanager configuration blocks?

Accepted Answer

route. Option A, route, is a valid top-level Alertmanager configuration block that defines the routing tree, specifying how alerts are grouped, matched, and dispatched to receivers. Option B, receivers, is also a valid top-level Alertmanager block that lists named notification integrations (such as email, Slack, or PagerDuty) that routes can reference. Options C (scrape_configs), D (targets), and E (rules) are not Alertmanager configuration blocks: scrape_configs and targets belong to Prometheus's scrape configuration, and rules is a Prometheus/recording-and-alerting rule file concept, not an Alertmanager config block.

Answer

scrape_configs

Answer

targets

Answer

rules

Question 6

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 7

Which THREE conditions cause a scrape to be unsuccessful?

Accepted Answer

Invalid metric format. In Prometheus, a scrape is unsuccessful when the target cannot be reached or its response cannot be parsed. Option B (Invalid metric format) is correct because Prometheus requires the exposition format to be valid; malformed metric lines, bad labels, or non-numeric values cause the scrape to fail with a parse error. Option C (HTTP 500 status code) is correct because Prometheus treats any non-2xx HTTP response from the /metrics endpoint as a failed scrape, recording it as such in up and scrape_duration_seconds. Option E (Network connection timeout) is correct because if the scrape cannot establish a TCP connection or exceeds the configured scrape_timeout, the scrape fails with a context deadline exceeded error. Options A (High memory usage) and D (Disk space low) do not directly cause a scrape to fail; they may affect the Prometheus server or target host generally, but they are not scrape-level failure conditions recognized by the scrape loop.

Answer

High memory usage

Answer

Disk space low

Question 8

Which TWO of the following are true about the Pushgateway?

Accepted Answer

Metrics must be deleted manually. Option D is correct because the Pushgateway never expires or garbage-collects pushed metrics on its own; pushed time series persist until they are explicitly removed, typically with an HTTP DELETE to a path such as /metrics/job/<job> (or via the pushgateway's admin API), so operators must delete stale metrics manually. Option E is correct because the Pushgateway exists specifically for short-lived, batch, or cron-style jobs that cannot be scraped reliably during their brief runtime; such jobs push their final metrics to the gateway, which then exposes them for Prometheus to scrape. Option A is wrong because the Pushgateway is not a drop-in replacement for standard scraping: it only holds pushed metrics and cannot discover or scrape targets, and it lacks the full semantics of a normal Prometheus scrape target. Option B is wrong because the Pushgateway is not a persistent metrics store; it keeps pushed metrics in memory and loses them on restart, with persistence being Prometheus's role. Option C is wrong because the Pushgateway does not automatically expire metrics; there is no built-in TTL, which is exactly why manual deletion is required.

Answer

It is a drop-in for standard scraping

Answer

It stores metrics persistently

Answer

It automatically expires metrics

Question 9

Which TWO of the following are valid ways to run Prometheus?

Accepted Answer

As a container. Option B is correct because Prometheus is commonly deployed as a container (e.g., the official prom/prometheus Docker image) running its server process in an isolated environment. Option C is correct because Prometheus ships as a standalone compiled Go binary that can be downloaded and executed directly on a host without any container runtime. Option A is wrong because Prometheus is a server-side monitoring system, not a browser extension. Option D is wrong because Prometheus is a standalone time-series database and monitoring server, not a library embedded into a database engine. Option E is wrong because Prometheus runs entirely in user space and is never implemented as a kernel module.

Answer

As a browser extension

Answer

As a database engine library

Answer

As a kernel module

Question 10

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 11

Which THREE features are provided by the Prometheus HTTP API?

Accepted Answer

Retrieving alert rules. The Prometheus HTTP API exposes endpoints that let clients retrieve alert rules via /api/v1/rules, so option A is correct because it returns configured alerting and recording rules. Option B is correct because the /api/v1/targets endpoint lists active scrape targets along with their labels, state, and last scrape/error information. Option D is correct because the /api/v1/query and /api/v1/query_range endpoints execute PromQL queries against time series data. Option C is not part of the Prometheus HTTP API; SMTP settings for Alertmanager are configured in Alertmanager's configuration file, not through Prometheus's API. Option E is also not provided, since scrape intervals are defined in the Prometheus configuration file (scrape_configs) and require a config reload or restart, not an API call.

Answer

Configuring SMTP

Answer

Updating scrape interval

Question 12

Which TWO of the following are valid data types in Prometheus?

Accepted Answer

Gauge. In Prometheus, the four core metric types are Counter, Gauge, Histogram, and Summary, so option B (Gauge) is correct because a gauge represents a value that can arbitrarily go up and down, such as temperature or current memory usage, and option C (Counter) is correct because a counter is a cumulative metric that only increases (or resets to zero on restart), such as total HTTP requests. These types are defined in the Prometheus client libraries and exposed via the text exposition format with TYPE annotations like 'counter' and 'gauge'. The other options are not Prometheus metric types: List (A) and Set (D) are not part of the Prometheus data model, and Boolean (E) is not a native metric type either, since boolean-like states are typically represented using a Gauge with values 0 or 1.

Answer

List

Answer

Set

Answer

Boolean

Question 13

Which THREE of the following are common sources of high cardinality?

Accepted Answer

Dynamic URL parameters. Dynamic URL parameters (A) are a classic high-cardinality source because each distinct parameter value (e.g., session tokens, query strings, or path segments) creates a new unique time series or metric label set. Unique user IDs (B) are also high cardinality since every user generates a distinct label value, causing the number of series to scale with the user base. Timestamps in labels (E) are high cardinality because a timestamp label takes a continuously increasing set of unique values, exploding the series count with every scrape or event. Static host names (C) are low cardinality because the set of hosts is small and bounded, and binary flags (D) only ever take two values (true/false or 0/1), so neither meaningfully increases cardinality.

Answer

Static host names

Answer

Binary flags

Question 14

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 15

Which THREE of the following are required to expose a new metric in an application?

Accepted Answer

Register the metric. To expose a new metric in an application, you must first define the metric (E) by declaring it in code with a name, type (counter, gauge, histogram, or summary), and help text, since no metric can be collected without a declared instrument. Next, you must register the metric (C) with the application's metrics registry (e.g., Prometheus's default registry or a custom CollectorRegistry) so the instrumentation library knows to track and report it. Finally, you must expose an /metrics endpoint (D) over HTTP so the Prometheus server can scrape the registered metric values in the standard text exposition format. Enabling remote write (A) is a Prometheus server-side feature for forwarding scraped samples to a remote storage system and is not needed to expose a metric from the application itself. Configuring Alertmanager (B) is only for routing and sending alerts based on alerting rules, which is unrelated to the mechanics of exposing a metric.

Answer

Enable remote write

Answer

Configure Alertmanager