Prometheus Certified Associate (PCA)

Every burn-rate alert, every recording rule, every dashboard panel this course has put in front of you assumes one tool is running underneath it and quietly doing its job: Prometheus. This course teaches what to do with what Prometheus produces — how to turn a query into an SLI, how to turn an SLI into an alert that pages someone at the right moment — but it has never asked you to prove you can operate the query language, the data model, and the service-discovery machinery yourself, cold, under exam conditions. The Prometheus Certified Associate (PCA) is exactly that proof. It's a knowledge-based credential developed by the Linux Foundation in partnership with the Prometheus community and endorsed by the CNCF, and it tests the single most load-bearing tool in this course's entire toolchain in isolation from everything built on top of it. This page covers what the exam is, its format and cost, the domains it tests, the PromQL and relabeling mechanics you actually need cold, and how it maps onto a course that has assumed Prometheus fluency on every page since monitoring & observability.

What the PCA is, and who it's for

☺ Like you're 10: A roughly ninety-minute, multiple-choice test of Prometheus's core mechanics — not a hands-on lab where you build a monitoring stack live.

The Prometheus Certified Associate sits in the same family as OpenTelemetry's own associate credential and the CNCF's Kubernetes and Cloud Native Associate (KCNA): all three are Linux Foundation Training & Certification exams, developed with deep involvement from the specific open-source project's own community, and delivered as remotely proctored, knowledge-based multiple-choice exams rather than the live-cluster, performance-based format used by the CKA, CKAD, and CKS. There is no terminal, no cluster to break, and nothing graded on end state — you are answering questions about Prometheus's architecture, its query language, and its configuration surface, not operating a running instance of it.

It targets engineers who instrument services, write PromQL, configure scrape targets and alerting rules, or simply consume dashboards and alerts built on Prometheus data day to day — which, on a team running any serious SLO program, is close to everyone touching production. It assumes you've actually used Prometheus, or at minimum read a /metrics endpoint and written a handful of queries against it; it does not assume Kubernetes fluency, container orchestration knowledge, or experience with any specific long-term-storage backend.

Format, cost, and prerequisites — verify before you sit it

☺ Like you're 10: Here's the shape of the test as best it's publicly known right now — and Linux Foundation exams get revised on their own schedule, so double-check before you pay.

The table below reflects the Linux Foundation's own published certification page as of this writing. Treat every number as a planning aid rather than a guarantee — associate-tier Linux Foundation exams in this family have had their pricing, timing, and curricula revised before, and the PCA is young enough as a credential that it's likely to keep changing faster than the long-established CKA has.

The exam domains

☺ Like you're 10: Six topic areas, and the query language alone carries as much weight as any two of the others combined.

What follows is the current domain structure and approximate weighting as generally published for the PCA curriculum. Unlike the CNCF's Kubernetes exams, which anchor to a numbered curriculum version you can pin down and cite, PCA's domain list is a newer, less exhaustively documented artifact — treat the percentages below as a study-planning approximation rather than a transcription you should quote back verbatim, and confirm the exact current breakdown on the Linux Foundation's own exam page before you build a study plan around any single number.

PromQL — the single largest domain

Selectors and label matchers (=, !=, =~, !~), instant vectors versus range vectors, the counter functions (rate(), irate(), increase()) and why they must never be read raw, aggregation operators (sum, avg, max, count) with by and without clauses, histogram_quantile(), and time-shifting with offset and subqueries.

Instrumentation and Exposition

The plain-text exposition format, the four native metric types (Counter, Gauge, Histogram, Summary) and which functions each one supports, client-library basics, and metric- and label-naming conventions — including why an unbounded label value is a cardinality incident waiting to happen.

Service Discovery and Relabeling

Static versus dynamic target discovery (static_configs, file_sd_configs, kubernetes_sd_configs, consul_sd_configs, cloud-provider discovery), and the relabel_configs pipeline that runs before scraping — keep, drop, replace, labelmap, and labeldrop actions against the __meta_* labels discovery attaches.

Alerting and Alertmanager

Writing alerting rules in PromQL with a for duration, and everything Alertmanager does once a rule fires: grouping alerts into one notification, routing by label to the right receiver, silencing planned work, and inhibition — suppressing a downstream symptom alert when its root-cause alert is already firing.

Prometheus Architecture

The pull model end to end — scrape loop, write-ahead log, on-disk TSDB blocks, default local retention — plus where Prometheus's own storage stops and the remote_write ecosystem (Thanos, Mimir, Cortex, VictoriaMetrics) picks up for anything that needs to outlive a couple of weeks.

Prometheus Fundamentals

What problem Prometheus solves, pull versus push and the tradeoffs of each, where Prometheus sits in the CNCF landscape, and the vocabulary — target, job, instance, scrape interval — everything else on this page is built out of.

The mechanics underneath: the data model, PromQL, and relabeling

☺ Like you're 10: Every time series is a name plus a set of labels plus a number at a point in time — and the exam wants you fluent in reading and writing all three parts without a reference open next to you.

Prometheus's data model is deceptively small: every sample is a metric name, an unordered set of {label="value"} key-value pairs that together identify one specific time series, a timestamp, and a float64 value. http_requests_total{job="api",instance="10.0.1.4:8080",code="200"} and the same metric with code="500" are two entirely distinct series as far as Prometheus's storage is concerned — which is exactly why sum() or rate() with the right by/without clause is doing real work, not cosmetic formatting, and why an SRE debugging a burn-rate alert needs to be able to read a query and know precisely which dimension it collapsed and which it kept.

# label matchers: exact, negated, and regex (both directions)
http_requests_total{job="checkout-api", code=~"5.."}
http_requests_total{job="checkout-api", code!~"2..|3.."}

# counters are meaningless raw — always wrap them
rate(http_requests_total{job="checkout-api"}[5m])

# aggregate away the instance dimension, keep job and code
sum by (job, code) (rate(http_requests_total[5m]))

# the exam's favorite function: p99 latency from a histogram
histogram_quantile(0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket{job="checkout-api"}[5m]))
)

# compare current error rate to the same window an hour ago
(
  sum(rate(http_requests_total{code=~"5.."}[5m]))
  /
  sum(rate(http_requests_total[5m]))
) offset 1h

# subquery: a range vector built by re-evaluating an instant query on a step
max_over_time(
  (sum(rate(http_requests_total{code=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))[1h:1m]
)

This is the exact shape of query this course has been asking you to read since monitoring & service level indicators — a "good" count over a "valid" count, wrapped in rate(), aggregated to the right cardinality. Tools like Sloth and Nobl9 generate recording rules in exactly this shape from a declarative SLO spec, which means most practitioners rarely hand-write the query above in production — but the PCA still expects you to read one cold and identify the numerator, the denominator, and which label the aggregation dropped.

Service discovery and relabeling is the other half of the exam that this course has used constantly without ever stopping to name. Static IP lists don't survive a single pod reschedule, so Prometheus discovers targets dynamically and runs every discovered target through a relabel_configs pipeline before it ever gets scraped — the pipeline that decides what to scrape, how to reach it, and what labels the resulting series carry.

scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      # keep only pods that opted in via annotation
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: "true"
      # rewrite __address__ using a port supplied in another annotation
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: '([^:]+)(?::\d+)?;(\d+)'
        replacement: '$1:$2'
        target_label: __address__
      # copy every "app.kubernetes.io/*" pod label onto the resulting series
      - action: labelmap
        regex: __meta_kubernetes_pod_label_app_kubernetes_io_(.+)
      # drop noisy system namespaces outright
      - source_labels: [__meta_kubernetes_namespace]
        action: drop
        regex: 'kube-system|kube-public'

The detail that trips people up: everything prefixed __meta_* and __address__ itself is a temporary label, visible only during the relabeling pipeline and stripped before storage — nothing starting with a double underscore survives into a stored series unless a replace or labelmap rule explicitly copies it into a normal label first. Miss that distinction and a query built around a label you assumed was stored simply returns nothing, with no error to point at why.

Why this course's whole SLO-monitoring stack assumes exactly this underneath

☺ Like you're 10: Every burn-rate alert this course has shown you is a PromQL expression wearing a costume — this exam is what's underneath the costume.

Multi-window, multi-burn-rate alerting — the technique this course treats as the standard way to page someone on error-budget consumption without drowning them in noise — is, mechanically, several PromQL expressions evaluated over different windows and compared against different thresholds, then combined with a boolean and. SLO windows and composite SLOs is the same PromQL fluency applied to rolling versus calendar-aligned windows and to combining several SLIs into one composite indicator. None of that page assumed you'd need to know what a __meta_kubernetes_pod_label_* temporary label is — it assumed you already did, the same assumption the PCA formalizes into a credential. Capstone Part 2 — build the monitoring & alerting is where that assumption gets tested in practice rather than on an exam: you're handed a service and asked to instrument it, discover it, query it, and alert on it, in that order.

It's worth being precise about where Prometheus's job — and therefore the PCA's scope — ends. Prometheus computes and evaluates; Grafana is almost always the layer that renders what it computes into the dashboards this course's on-call readiness checklist assumes exist, and Alertmanager routes what Prometheus decides should page someone into PagerDuty or a similar paging tool, which is where incident management & on-call picks the story up. The PCA tests the layer that makes all of those downstream tools trustworthy in the first place — a beautiful dashboard built on a query that silently dropped the wrong label is still wrong, just wrong in a way that looks confident.

PCA versus the other CNCF-adjacent credentials on this site

☺ Like you're 10: Same test-taking format as the entry-level Kubernetes badge, completely different subject — and a genuinely different beast from the exams where you're handed a broken cluster.

PromQL fluency and OpenTelemetry instrumentation are complementary, not competing — OpenTelemetry increasingly generates the metrics Prometheus scrapes and Prometheus increasingly speaks OTLP natively, so the two credentials sit end-to-end on the same pipeline rather than overlapping. If you're building out this exact corner of your resume, this course's sibling OpenTelemetry Certified Associate page is the natural next stop.

Who should consider it — and who should skip it

☺ Like you're 10: If you'd be the one writing the query at 3am when a burn-rate alert fires, this is worth an afternoon. If you only ever look at a dashboard someone else built, it might not be.

The case for taking it

Take it if you write or review PromQL, own alerting rules, configure scrape targets, or are accountable for an SLO program's monitoring layer — which, in this course's own terms, is most of what monitoring & observability and alert design & alert fatigue ask of an SRE. It's a fast, credible way to prove that fluency to a hiring manager who has neither the time nor the standing to watch you write a query live, and it costs a fraction of what the performance-based CNCF exams do in both money and preparation time.

When to skip it

Deprioritize it if any of these fit. You already write PromQL daily at a senior level — it will confirm what you know and teach you little; spend the study time on multi-window burn-rate alerting instead, which is the harder, less-documented skill built on top of it. Your organization standardized on a different monitoring stack entirely — Datadog, a proprietary APM — and Prometheus specifically isn't part of your day job; a vendor-specific credential or this course's own SRE Practitioner path is a better use of that afternoon. You're brand new to observability concepts — work through monitoring & observability and the Prometheus tool page here first; the PCA rewards fluency, not first exposure.

How to prepare using this site

☺ Like you're 10: This course teaches what to build with Prometheus more than it teaches raw exam trivia — here's the map from each domain to the page that gets you closest.

None of this replaces standing up a real Prometheus instance and breaking it a little — reading exposition text off a live /metrics endpoint, watching a target flip up to 0 when you kill it, writing a relabel rule and watching a target vanish from the discovery list. The exam tests fluency with a live system, and fluency is built by touching the live system, not by memorizing this page.

Pair this page with the Prometheus tool page for the full architecture and multi-window burn-rate alerting for where this exact PromQL fluency gets used under real paging pressure. For a broader credential across the whole SRE discipline, see this course's own SRE Practitioner path. Full comparisons against every other certification on this site live on the certifications hub.