PCA Prometheus Certified Associate Exam Topics and Questions

Observability Concepts sets the theoretical foundation for everything that follows. Before you can use Prometheus well, you need a precise mental model of what observability means in practice and where its different signals apply. This topic is where abstract vocabulary becomes exam vocabulary. Expect to pay for any fuzziness between metrics, logs, traces, and events, and for any confusion about how reliability targets translate into measurable indicators.

– Signals: what they are and where each one fits

Metrics are time-series numbers. That sounds obvious, but the exam tests whether you know what makes a good metric versus a log entry versus a trace span. Logs capture discrete events with arbitrary structure; metrics aggregate state over time. Events sit closer to logs: they mark that something happened at a point in time, whereas a metric records how often or how much. Tracing adds a causal chain across service boundaries, and a span is one named, timed segment within that chain. The exam will probe whether you can identify which signal type belongs to a given scenario, so keep the distinctions sharp and resist conflating them.

– Collection model and service location

Prometheus pulls metrics from targets rather than waiting for targets to push data to it. That architectural choice has consequences: targets must be reachable at scrape time, and short-lived jobs that finish before a scrape arrives need the Pushgateway as an intermediary. Service discovery is what lets Prometheus find targets dynamically in environments where IP addresses and ports change. You need to understand why the pull model was chosen and what it means for network topology and firewall rules, because the exam asks about trade-offs, not just mechanics. Push-based systems shift the burden to the sender; pull-based systems shift it to the collector. Know which problems each model handles better.

– Reliability targets: SLOs, SLAs, and SLIs

An SLI is a measurement: the ratio of good requests to total requests, for example. An SLO is the internal target you set for that measurement. An SLA is the contractual commitment you make to a customer, typically looser than the SLO so you have a buffer. The exam tests the relationships between these three, not just the definitions. A common trap is treating SLO and SLA as interchangeable. The practical consequence matters too: when an SLI breaches an SLO, you have consumed error budget. Knowing which metric feeds which indicator, and which indicator drives which agreement, is the level of precision the exam expects.

How Observability Concepts is tested

At 18%, this topic appears often enough to swing a borderline result. Items here tend to be scenario-based: a description of a monitoring problem, and you choose which signal type or collection model addresses it. The demand is discrimination, not recall. You are not asked to define a span; you are asked which approach suits a situation where you need to trace a slow request across three microservices.

The most common place candidates lose marks is on the SLO/SLA/SLI relationships. The three terms feel similar enough that a hurried reader picks the wrong one. Slow down on those items and reconstruct the chain: measurement first, internal target second, external commitment third.

Push versus pull items reward knowing the architectural reasons behind Prometheus's design decision, not just the fact of it. Items also appear on service discovery, where the trap is assuming static configuration is always sufficient. Treat every scenario as a signal to identify the right tool, and you will handle this topic cleanly.

Where Observability Concepts dealt in principles, Prometheus Fundamentals deals in the actual system you will configure and operate. At 20% this is the second-heaviest topic on the exam, and it covers the parts that every other topic assumes you already understand. Gaps here compound: a shaky data model makes PromQL harder, and a vague picture of the scrape cycle makes instrumentation harder. Get this topic solid before moving forward.

– Architecture and the scrape cycle

Prometheus is a single binary that scrapes HTTP endpoints at configured intervals, stores the resulting time-series data locally, and evaluates rules against that data. The exam expects you to know what each component does and, more importantly, what it does not do. The Pushgateway is not a general-purpose ingestion layer; it is a workaround for batch jobs. Alertmanager is separate from the Prometheus server. Understanding the data flow from target to storage to query engine is what lets you reason about latency, staleness, and failure modes. Architecture questions often describe a broken or suboptimal setup and ask what is wrong.

– Configuration, scraping, and the data model

Prometheus configuration lives in a YAML file. The scrape configuration defines which targets to hit, how often, and with what timeout. Labels are the core of the data model: every time series is identified by a metric name plus a set of key-value label pairs. Two series that share a name but differ in any label are distinct series. This matters because cardinality explodes when labels take on unbounded values, such as user IDs or request URLs. The exam tests whether you understand that a label is not just metadata but the primary dimension of the data model, and that poor label choices create performance problems.

The exposition format is what a scrape target returns: plain text, one metric per line, following a specific syntax. You need to recognise valid exposition format and know what the HELP and TYPE comment lines do.

– Limitations

Prometheus makes deliberate trade-offs, and the exam tests whether you know where the system stops being the right tool. It is not designed for long-term storage at scale; that is what remote write and solutions like Thanos or Cortex address. It does not guarantee perfect accuracy for all query types, particularly around staleness windows and counter resets. Event-level detail is outside its scope. Knowing the limitations is not pessimism; it is the knowledge that tells you when to reach for something else, and the exam will present scenarios designed to catch candidates who think Prometheus solves every observability problem.

How Prometheus Fundamentals is tested

Twenty percent of the exam comes from this topic, so a strong performance here meaningfully improves your overall score. Items range from configuration recognition to architectural reasoning. You may be shown a scrape configuration and asked what it produces, or a data model scenario and asked which label strategy causes a cardinality problem.

The exposition format appears in items that require you to identify valid or invalid metric output. The trap is treating HELP and TYPE lines as optional decoration; they carry semantic meaning that affects how clients interpret the data.

Limitations items are the ones candidates most often underestimate. The exam rewards knowing what Prometheus cannot do in a given scenario, and candidates who treat it as universally applicable will pick options that fit the tool to the wrong job. On data model questions, the key is remembering that labels define identity, not just context. Two otherwise identical series with different label sets are different series entirely, and that distinction drives several item types.

PromQL is the single largest topic on this exam at 28%, and it is the one most likely to separate candidates who pass from those who do not. The query language is Prometheus-specific, so there is no transferable SQL intuition to lean on. Every concept here requires deliberate study. If you have been skimming the other topics, stop skimming here. The cost of a weak PromQL result is too high to absorb with strong scores elsewhere.

– Selecting and filtering data

Every PromQL expression starts with a selector. An instant vector selector picks the most recent sample for each matching series. A range vector selector picks all samples within a lookback window, written with a duration in square brackets. The exam tests whether you can read a selector and predict what it returns, including the effect of label matchers. Equality matchers, negative matchers, and regex matchers each behave differently, and combining them changes which series are included. Timestamp metrics are a specific pattern where the metric value encodes a Unix timestamp rather than a measurement; queries against them require awareness of what the number actually represents.

– Rates, derivatives, and time-based aggregation

rate() and irate() both compute per-second rates from a counter, but they use different sample windows and behave differently under sparse data. irate() uses only the last two samples; rate() uses all samples in the range. The exam exploits this difference in scenarios involving gaps or high-churn series. increase() gives you the total rise over the range rather than a per-second rate. deriv() fits a least-squares line to a gauge and returns its slope; it is appropriate for gauges, not counters. Aggregation over time uses functions like avg_over_time(), max_over_time(), and min_over_time() applied to a range vector. Knowing when to use a time-based aggregation versus a label-based one is a skill the exam tests directly.

– Aggregating over dimensions and binary operators

Label-based aggregation collapses multiple series into fewer series using operators like sum(), avg(), count(), and topk(). The by() and without() clauses control which labels survive the aggregation. Getting this wrong means either collapsing too aggressively and losing information, or failing to collapse and producing a cardinality explosion downstream. Binary operators combine two instant vectors, and the matching rules are where most candidates lose marks. One-to-one matching requires the label sets to align; many-to-one and one-to-many matching require on() or ignoring() plus group_left() or group_right(). The exam will present mismatched vector operations and ask what happens, or ask which operator and modifier produces a specific result.

– Histograms

Prometheus histograms are stored as multiple time series: one per bucket (with an le label), a _sum series, and a _count series. histogram_quantile() reconstructs a quantile estimate from those buckets. The accuracy of the estimate depends on bucket boundaries; if the true value falls outside the configured buckets, the estimate is clamped to the boundary. The exam tests whether you understand how histogram_quantile() works and what makes a quantile estimate unreliable. A common trap is treating the result of histogram_quantile() as precise. It is an interpolated estimate, and the exam rewards knowing the difference between an estimate and a measurement.

How PromQL is tested

At 28%, PromQL items make up more than a quarter of your exam. They are also among the most technically demanding items on the paper. You will be shown expressions and asked what they return, or shown a requirement and asked which expression satisfies it. The demand is functional fluency: you need to read and reason about PromQL, not just recognise keywords.

Binary operator matching is the area where the most marks are lost. Candidates who have not practised vector matching under different label configurations will find those items opaque. The trap is assuming that two vectors with the same metric name will match cleanly; label set alignment is what actually matters.

Histogram quantile items reward understanding interpolation limits. Rate versus irate items reward knowing the sample-window behaviour under sparse data. Aggregation items reward precision about what by() and without() do to the output label set.

Read every expression carefully. A single changed function or a missing label matcher changes the result entirely, and the exam is written to exploit exactly that level of inattention.

PromQL tells you how to query data that already exists. Instrumentation and Exporters is about where that data comes from in the first place. At 16%, this topic is smaller than PromQL but connects directly to it: a poorly instrumented metric produces data that no query can save. The practical focus here is on choices made before Prometheus ever scrapes a target, and those choices have lasting consequences for your data model.

– Client libraries and instrumentation

Client libraries expose metrics from application code. Prometheus maintains official libraries for several languages, and each one provides the four core metric types: counter, gauge, histogram, and summary. Instrumentation means adding those metric types to your code at the right points. A counter tracks monotonically increasing values; resetting it is a signal of a process restart. A gauge tracks values that go up and down. Choosing the wrong type for a measurement is a mistake the exam tests: a response time stored as a gauge cannot be meaningfully aggregated with rate(), for example. The exam also expects you to know that instrumentation happens inside the application, which makes it different from using an exporter.

– Exporters and metric naming

An exporter is a process that translates metrics from a third-party system into Prometheus exposition format. It runs alongside the system it monitors and exposes a scrape endpoint. The exam distinguishes between instrumentation (code you write) and exporters (code that bridges systems you do not control). Metric naming follows conventions that the exam treats as rules: metric names should include a unit, the unit should be unprefixed (seconds not milliseconds), and the name should describe what is being measured in a way that survives label stripping. A well-named metric is self-describing; a poorly named one requires context that may not be available at query time. The exam will present naming choices and ask which one follows the conventions.

How Instrumentation and Exporters is tested

At 16%, this topic is lighter than PromQL but heavier than a topic you can afford to skip. Items here tend to be applied: a scenario describes a system, and you choose the right metric type, the right approach (instrumentation versus exporter), or the right naming pattern.

Metric type selection is where candidates lose marks most often. The four types have specific semantics, and the exam presents plausible-sounding but wrong choices. Counters are for things that only go up; the exam will offer a gauge in a counter scenario and see if you notice.

Naming convention items reward knowing the unit suffix rule and the preference for base units. Items on exporters reward understanding the architectural role of the exporter: it is a translator, not a data store, and it has no memory of previous scrapes beyond what the target system provides.

Client library items may ask about registration, default metrics, or the relationship between a library and the exposition format it produces. Treat those as data-model questions in disguise.

Alerting and Dashboarding is where Prometheus output becomes visible to the people who act on it. At 18%, it matches Observability Concepts in weight and covers two distinct skill areas: writing and configuring alert rules in Prometheus, and operating Alertmanager to route and suppress notifications. Dashboarding is the lighter of the two, but it rounds out the picture. Candidates who have focused entirely on PromQL sometimes underestimate this topic and pay for it.

– Dashboarding and the basics of alerting

Dashboards surface metrics visually, and the exam tests whether you understand what makes a dashboard useful rather than just populated. Choosing the right visualisation for a rate versus a gauge matters. Alerting basics cover when to alert (on symptoms rather than causes, in most cases), what an alert should communicate, and why alert design affects operator response. An alert that fires too often trains people to ignore it; an alert that fires too late is useless. The exam tests judgment about alert design, not just syntax. Knowing that alerts should be actionable and scoped to the right audience is the kind of principle that appears in scenario items.

– Configuring alert rules in Prometheus

Alert rules live in Prometheus, not in Alertmanager. A rule specifies a PromQL expression, a duration for which the expression must be true before the alert fires (the for clause), and labels and annotations to attach to the alert. The for clause is a common exam focus: an alert in a pending state has not yet held true for the required duration. An alert in a firing state has. The exam tests whether you can read a rule and predict its behaviour, including what happens when the condition flickers in and out of truth during the for window. Annotations carry human-readable context; labels carry machine-readable routing information.

– Alertmanager: routing, grouping, and silencing

Alertmanager receives alerts from Prometheus (and other sources) and decides what to do with them. Its three main mechanisms are routing (sending alerts to the right receiver based on label matching), grouping (batching related alerts into a single notification to reduce noise), and inhibition and silencing (suppressing notifications when conditions are met). The exam tests the difference between a silence and an inhibition rule: a silence is time-bounded and manual; an inhibition rule is automatic and condition-based. Routing configuration uses a tree of routes with label matchers; the first matching route wins. Knowing the matching order prevents a common mistake where a more specific route is never reached because a broader one intercepts it first.

How Alerting & Dashboarding is tested

At 18%, this topic carries the same weight as Observability Concepts, and it is tested with a similar mix of conceptual and applied items. Alert rule items reward precise reading of the for clause and the distinction between pending and firing states. Candidates who treat the for clause as cosmetic will misread scenario items about alert timing.

Alerting basics items reward understanding the design intent behind an alert. Items may describe an alert configuration and ask whether it is well-designed, and the strongest option will reflect the principle that alerts should be actionable and appropriately scoped.

Alerter manager items reward knowing the difference between routing, grouping, inhibition, and silencing. The trap is conflating inhibition with silencing: they achieve similar outcomes by different mechanisms, and the exam distinguishes them. Route-matching order is another source of lost marks; candidates who do not know that the first matching route wins will pick the wrong behaviour in ordering scenarios.

Dashboarding items are typically the least technically demanding in this topic, but they still require knowing which visualisation type suits which metric type.