Why observability has its own certification track in 2026

Prometheus started as a monitoring system built by SoundCloud in 2012 and was open-sourced in 2015. By 2016 it had become the second project to join the CNCF after Kubernetes. In 2026 it is the de facto standard for metrics collection in cloud-native environments — present in virtually every Kubernetes cluster, integrated with every major service mesh (Istio, Linkerd, Envoy), and the backend behind the Grafana dashboards that SRE teams watch at 2 a.m. during incidents. The Prometheus Certified Associate (PCA) validates that a practitioner understands the system at a professional level — not just that they can read a Grafana dashboard, but that they can instrument applications, write production-grade PromQL, design alerting trees, and architect Prometheus deployments for reliability at scale.

The PCA was launched by The Linux Foundation and CNCF as part of the same certification family as the CKA, CKAD, CKS, KCNA, and CGOA. It occupies the observability pillar of that family: while CKA holders know how to manage the cluster that Prometheus runs on, PCA holders know how to make Prometheus produce actionable signal from that cluster. At organisations operating Kubernetes in production, both credentials together are increasingly the baseline expectation for platform and SRE team members. The PCA exam is online-proctored, delivered through the Linux Foundation’s PSI Secure Browser environment, and can be taken from any location with a stable internet connection.

The exam consists of multiple-choice questions delivered in a 90-minute window. Unlike the CKA, CKAD, and CKS, the PCA is not a performance-based (hands-on terminal) exam — it is a knowledge-based multiple-choice exam. This means that preparation strategies differ from Kubernetes certifications: the PCA requires conceptual depth and PromQL pattern recall rather than the time-limited kubectl muscle memory that CKA preparation develops. Candidates who have operated Prometheus in production report that hands-on exposure to the full stack (Prometheus + Alertmanager + Grafana + exporters) is still essential for answering scenario-based questions correctly, even without a terminal component.

The five PCA domains

Domain 1 — Observability Concepts (~18%)

The foundational domain establishes the conceptual vocabulary that the rest of the exam builds on. Candidates who treat this as review material often underscore it — the PCA tests these concepts with precision, not at a surface level.

  • The three pillars of observability: metrics, logs, and traces serve different diagnostic purposes. Metrics quantify system state over time (request rate, error rate, latency percentiles, resource utilisation). Logs capture discrete events with context. Traces follow a request through distributed services to identify where latency originates. Prometheus handles metrics exclusively; understanding where its scope ends and where distributed tracing (Jaeger, Tempo) begins is testable.
  • Pull versus push model: Prometheus’s pull model scrapes metrics from instrumented endpoints on a configured interval, inverting the assumption of most traditional monitoring systems that send data to a central collector. The pull model gives Prometheus control over scrape frequency, makes it easy to detect when a target goes down (a scrape simply fails), and eliminates the coordination overhead of configuring each service to know its monitoring endpoint. The PCA tests when the Pushgateway provides a necessary exception — short-lived batch jobs that complete before the next scrape interval can push metrics to the gateway before they exit.
  • RED and USE methods: The RED method (Rate, Errors, Duration) structures monitoring for request-driven services: how many requests per second, how many fail, how long they take. The USE method (Utilisation, Saturation, Errors) structures monitoring for resources: how busy is the resource, how much demand is queued above its capacity, and how many errors is it producing. PCA questions regularly ask candidates to identify which metrics satisfy which method for a given service architecture.
  • Cardinality: Prometheus stores time series, not just metric names — each unique combination of label values creates a separate time series. High cardinality (labels with many possible values such as user IDs, request UUIDs, or unbounded IP addresses) causes the Prometheus TSDB to grow rapidly and degrade query performance. Understanding cardinality as an architectural constraint is a recurring PCA topic.

Domain 2 — Prometheus Fundamentals (~20%)

The architecture domain covers how Prometheus is built and how its components interact. Understanding the data flow from instrumented application to stored time series is the prerequisite for every other domain.

  • Prometheus server components: the Prometheus server has three internal components: the retrieval subsystem (scrapes targets), the TSDB (stores time series data on local disk in compressed blocks), and the HTTP API (serves PromQL queries and exposes the web UI). The server is intentionally simple and stateless with respect to alerting and long-term storage — those responsibilities are delegated to Alertmanager and remote storage backends respectively. The PCA tests this separation of concerns as a design principle.
  • Scrape configuration: scrape_configs in prometheus.yml defines the targets Prometheus pulls metrics from. Each scrape config specifies a job name, scrape interval (overrides global default), target endpoints (static or dynamically discovered), relabeling rules, and metric relabeling rules. The PCA tests the evaluation order of relabeling stages and the difference between target relabeling (applied before the scrape, determines whether the target is scraped and under what labels) and metric relabeling (applied after the scrape, filters and transforms the scraped metrics).
  • Service discovery: Prometheus supports native service discovery integrations for Kubernetes, EC2, GCE, Azure, Consul, DNS SRV records, and file-based SD (a JSON or YAML file listing targets). Kubernetes service discovery automatically discovers Pods, Services, Endpoints, Ingresses, and Nodes as scrape targets. The PCA tests the Kubernetes SD role types and the annotations (prometheus.io/scrape, prometheus.io/port, prometheus.io/path) that control whether a Pod is scraped and where.
  • Storage and retention: the local TSDB stores data in two-hour blocks that are periodically compacted into larger blocks. The default retention period is 15 days. Remote write sends scraped data to compatible remote storage systems (Thanos, Cortex, VictoriaMetrics) for long-term retention beyond what local storage can hold. The PCA tests the trade-off between local simplicity and remote durability — Prometheus is designed to be a reliable short-term store, not a long-term archive.
  • Pushgateway: the Pushgateway is an intermediary for batch jobs and other short-lived processes that cannot be scraped. Batch jobs push their metrics to the Pushgateway before exiting; Prometheus then scrapes the gateway. The PCA tests when Pushgateway is appropriate and its important limitation: because the gateway persists metrics until they are explicitly deleted, a job that stops running does not cause its metrics to disappear from Prometheus — an operator must delete them. This makes the Pushgateway unsuitable for tracking the health of ongoing services.

Domain 3 — PromQL (~28%)

PromQL is the heaviest domain by exam weight and the skill that most clearly separates practitioners who have operated Prometheus in production from those who have only read about it. Writing correct PromQL requires understanding the type system, label semantics, and the behaviour of functions that are easy to misuse.

  • Data types and selectors: PromQL has four data types: instant vector (a set of time series at a single point in time), range vector (a set of time series over a time window), scalar (a single numeric value), and string (rarely used). A selector like http_requests_total{job="api-server", status="200"} returns an instant vector; appending a range selector like [5m] returns a range vector required by functions like rate(). Label matchers include equality (=), inequality (!=), regex match (=~), and regex non-match (!~). The PCA tests selector construction for both filtering and negative filtering scenarios.
  • rate() and irate(): rate(counter[5m]) calculates the per-second rate of increase of a counter over a five-minute window, smoothed across multiple samples. irate(counter[5m]) calculates the instantaneous rate using only the last two samples in the window, producing a more responsive but noisier result. The PCA tests when to use each: rate() for alerting and dashboards (smoothed signals are more reliable), irate() for detecting short-lived spikes. Both functions handle counter resets (a counter resetting to zero on process restart) correctly by detecting and adjusting for the reset.
  • Aggregation operators: aggregation collapses a set of time series into a smaller set by combining their values. sum(metric) by (label) sums across all series and groups the result by label. avg(), max(), min(), count(), topk(), and quantile() follow the same pattern. The PCA tests the by and without clauses that control which labels are preserved versus dropped in the aggregation result.
  • histogram_quantile(): Prometheus histograms accumulate observations into configurable buckets. histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) computes the 95th percentile request duration from a histogram metric. The PCA tests the construction of this expression and the important limitation: the quantile is an approximation bounded by the configured bucket boundaries. A histogram with too-coarse bucket boundaries produces inaccurate high-percentile estimates.
  • Recording rules: recording rules pre-compute expensive or frequently-needed PromQL expressions and store the results as new time series. They are defined in rule files loaded by Prometheus and evaluated on a configurable interval. Recording rules dramatically reduce query latency for complex dashboards that would otherwise recompute expensive aggregations on every panel refresh. The PCA tests the naming convention for recording rules (level:metric:operations) and when to create them.

Domain 4 — Instrumentation & Client Libraries (~16%)

Instrumentation is how applications expose metrics to Prometheus. Understanding the four metric types and how they map to application behaviour is the foundation for writing meaningful observability, not just collecting data.

  • Counter: a Counter is a monotonically increasing cumulative value that resets to zero on process restart. Counters are correct for values that only go up: request counts, error counts, bytes sent, events processed. The rate() and increase() functions turn raw counter values into per-second rates and total increases over windows. A common instrumentation mistake is using a Gauge for values that should be Counters — a Gauge loses the ability to detect process restarts and makes rate calculations unreliable.
  • Gauge: a Gauge is a value that can go up and down, representing a current state. Memory usage, active connection count, queue depth, temperature, and CPU utilisation are Gauges. Gauges are used directly in PromQL without rate() because their value is meaningful at any point in time. The PCA tests distinguishing Gauge from Counter for a given measurement as an instrumentation design decision.
  • Histogram: a Histogram samples observations (typically request durations or response sizes) and counts them in configurable buckets. Each histogram metric produces three time series: _bucket with bucket counts, _count with the total number of observations, and _sum with the sum of all observed values. Histograms enable percentile calculations via histogram_quantile() and are the correct metric type for measuring latency distributions. Bucket boundary configuration is a design decision: too few buckets produce inaccurate quantiles; too many increase cardinality.
  • Summary: a Summary also samples observations and can calculate quantiles, but it does so client-side at the application level rather than server-side in PromQL. Summaries pre-compute configurable quantiles (e.g., 0.5, 0.9, 0.99) and expose them as separate time series. Unlike Histograms, Summaries cannot be aggregated across instances — sum() of 0.99th-percentile summaries from multiple instances does not produce the 0.99th percentile of the combined distribution. The PCA tests this aggregation limitation as the primary reason to prefer Histograms over Summaries for microservice deployments where aggregation across instances is needed.
  • Client libraries and exposition format: Prometheus client libraries exist for Go, Java, Python, Ruby, Rust, and many other languages. All libraries expose metrics in the Prometheus text-based exposition format at a /metrics HTTP endpoint. The format is human-readable: each metric is preceded by # HELP (description) and # TYPE (metric type) comment lines, followed by one line per time series with its label set and current value. The PCA tests the exposition format and the role of the Content-Type header in distinguishing text format from the binary protobuf format.

Domain 5 — Alerting & Alertmanager (~18%)

Alerting is where observability becomes operational. The PCA tests both Prometheus’s alerting rules and the Alertmanager component that handles alert routing, deduplication, grouping, and notification delivery.

  • Alerting rules: alerting rules are defined in rule files alongside recording rules. An alert fires when its PromQL expression evaluates to a non-empty result for a configurable duration (the for clause). The for clause prevents transient spikes from generating notifications — an alert set to for: 5m only fires if the condition is continuously true for five minutes. Labels and annotations are attached to alerts: labels are used by Alertmanager for routing decisions; annotations (such as summary and description) provide human-readable context for notification messages.
  • Alertmanager routing: the Alertmanager route tree defines how alerts are matched to receivers. The root route handles all unmatched alerts; child routes match on label values (e.g., severity: critical routes to PagerDuty; severity: warning routes to Slack). Routes can specify grouping keys that cluster related alerts into a single notification, and timing parameters that control how long Alertmanager waits before sending an initial notification, how long it waits before repeating an unresolved notification, and how long it waits after a change before resending grouped alerts.
  • Deduplication and grouping: Prometheus generates an alert for every individual time series that satisfies an alerting rule — in a large cluster, a single alert condition might fire hundreds of individual alert instances. Alertmanager groups these into a single notification based on configurable grouping labels. Without grouping, a deployment that kills 50 pods simultaneously would generate 50 separate PagerDuty incidents. The PCA tests grouping configuration as a noise-reduction mechanism that is essential for production alerting.
  • Inhibition rules: an inhibition rule silences a set of alerts when another, higher-severity alert is already firing. For example, when a InstanceDown alert fires for a node, inhibition rules suppress all the per-service alerts that would fire as a consequence of the node being down. Without inhibition, a single node failure generates dozens of alert notifications for every service running on it. The PCA tests inhibition as a method for preventing alert storms and maintaining signal clarity during large incidents.
  • Silences: silences mute matching alerts for a defined time window without changing their alerting rule configuration. Silences are appropriate during planned maintenance windows when known conditions will generate expected alerts. They are created through the Alertmanager UI or API and expire automatically at their configured end time. The PCA tests silences as a time-bounded operational tool distinct from disabling alerting rules or modifying routing configuration.

Exam format and preparation strategy

The PCA is a 90-minute multiple-choice exam that does not include a hands-on terminal component. Questions are scenario-based: a realistic configuration snippet, a PromQL expression, or an operational situation is described, and candidates select the correct analysis or action from four options. The exam tests applied knowledge — understanding why rate() requires a counter and what happens if a Gauge is passed to it, not memorisation of function signatures. The Linux Foundation does not publish a passing score, but the exam is reported to require approximately 75% correct answers by candidates who have taken it.

The preparation profile that consistently produces passing scores is hands-on. Running a local Prometheus stack (Prometheus + Alertmanager + Grafana + Node Exporter) using Docker Compose, writing PromQL queries against real data in the Prometheus UI, instrumenting a simple application with a client library, and configuring a complete alerting tree from alert rule through Alertmanager routing to a notification channel builds the intuitive understanding of system behaviour that the exam tests. Candidates who have operated Prometheus in production for six months or more at depth across all five domains typically require three to five weeks of structured exam preparation focused on PromQL edge cases, Alertmanager routing trees, and the cardinality implications of instrumentation choices.

The most common PCA failure pattern: candidates who know Prometheus as a dashboard data source rather than as a system they operate. Reading Grafana panels does not build PromQL fluency, understanding of Alertmanager routing trees, or knowledge of how the TSDB manages cardinality. The exam consistently surprises candidates who are daily Prometheus users but have not had to build or debug the system from its configuration layer.

PCA in the cloud-native certification landscape

Understanding how the PCA fits with adjacent credentials prevents under-investing or over-investing relative to career goals:

Why it matters for cert candidates

The Prometheus PCA fills a specific gap in the cloud-native certification landscape: it validates observability expertise that Kubernetes certifications do not test. For engineers targeting SRE, platform engineering, or DevOps roles at cloud-native organisations, PCA is a high-signal addition to a CKA or CKAD. It demonstrates that the candidate can not only run workloads on Kubernetes but can also instrument them, monitor them, and build the alerting trees that keep them reliable. The official Linux Foundation PCA exam page contains the current domain breakdown, exam curriculum, and registration information.

Practice Prometheus Certified Associate exam questions — PromQL, Alertmanager routing, metric types, instrumentation, and observability concepts.

Practice PCA Questions →