PCA — Prometheus Certified Associate

The Prometheus Certified Associate is the CNCF’s badge for the most load-bearing tool in cloud native operations. Almost every platform you will build scrapes metrics with Prometheus, stores them as labelled time series, queries them with PromQL and pages a human through Alertmanager — and PCA certifies you can do all four properly rather than by copy-paste. It is knowledge-based, not a lab, but it is no soft exam: more than a quarter of it is PromQL, which punishes anyone who has only ever pasted queries from a blog post. This page reproduces the five official domains and weights exactly as the CNCF publishes them, says honestly when to skip the cert, and maps every domain to lessons you can start reading here today.

What the PCA is — and who it is for

☺ Like you’re 10: It’s an online multiple-choice test about Prometheus — how it collects numbers, how you ask it questions, and how it raises an alarm.

PCA is a knowledge-based, multiple-choice certification from the CNCF and The Linux Foundation, delivered online and remote-proctored. There is no live cluster and no terminal: you are not asked to install Prometheus under a clock, you are asked whether you understand it. That changes what “studying” means. Having helm install kube-prometheus-stack in your shell history will not pass it. Reading a PromQL expression and saying what it returns, reading an exposition-format payload and naming the metric type, reading an alerting rule and saying who it wakes and why — that will.

Who should sit it

• Platform and SRE engineers who own the monitoring stack and want the gaps in their self-taught PromQL closed properly.
• Developers instrumenting their own services — Dot the Duck’s people, who are asked to “add metrics” and would like to know which type to reach for.
• Anyone on call. The alerting domain is, quietly, a course in not destroying your team with pages.

What it deliberately does not test

PCA is scoped tightly. It is not a Kubernetes exam — you will not debug a Pod — and not a Grafana exam either, though “dashboarding basics” is in the blueprint. Nor does it test running Prometheus at scale: long-term storage, federation and HA designs are things an associate should know exist and why, not architect. The curriculum does list “Understanding Prometheus Limitations” as an explicit competency, which is the exam politely telling you it will ask what Prometheus is bad at.

Why a platform engineer might take it — and when to skip it

☺ Like you’re 10: If you build platforms, you will use this tool every week. But if you already use it every week, the badge might not teach you much.

The honest case for taking it

Observability is not a bolt-on; it is one of the planes in the reference architecture, and Prometheus is what fills it. Most engineers’ Prometheus knowledge is a patchwork: strong on installing the operator, weak on rate() versus increase(), hazy on why their histogram quantile is a lie, and absent on cardinality until the day the TSDB falls over. PCA’s blueprint is unusually good at forcing you across all of it in one pass. The alerting domain alone — when, what and why to alert — is worth the study time even if you never sit the exam, because it is the difference between an on-call rotation people tolerate and one they quit over.

When to skip it

Skip PCA if you already write multi-line PromQL from memory, have tuned a cardinality problem in anger, and can explain a counter versus a gauge without notes — you will pass it cold, so the badge signals nothing your work history doesn’t. Skip it too if metrics are somebody else’s job and you are being pulled toward delivery or security: CGOA, KCSA or CKS pay back faster. And skip it if a job description names a different credential; chase the named cert, not the shelf.

How it relates to the CNPE

The CNPE has an Observability & Operations domain worth 20%, and it is performance-based: you build and wire the stack rather than describe it. The two point in opposite directions on the same material, which makes them complementary rather than redundant — PCA gives you the depth (query language, data model, alerting philosophy) that stops CNPE’s observability tasks from being guesswork under a clock.

The official domains and their weights

☺ Like you’re 10: The test has five parts and they are not the same size. The biggest single part is the question language, PromQL.

The names, percentages and competency lists below are transcribed from the CNCF’s Prometheus Certified Associate (PCA) Exam Curriculum — not our interpretation of it. Five domains, 26 competencies, and the weights sum to exactly 100%; if a study guide you find elsewhere doesn’t add up, it has been paraphrased. Check the current version in the official CNCF curriculum repository before you build a plan on it:

Every competency, domain by domain

Where the weight really sits

Read the shape rather than the list. PromQL plus Prometheus Fundamentals is 48%; add Instrumentation and Exporters and 64% of the exam is Prometheus proper. The remaining 36% splits between vendor-neutral observability theory and the alerting-and-dashboarding layer on top — and that is where careless candidates lose marks, because Observability Concepts reaches beyond metrics entirely, into logs, events, tracing and spans and the SLO/SLA/SLI vocabulary. It feels like reading rather than studying, so it gets skipped.

What you actually need to know

☺ Like you’re 10: Here’s the real stuff — how the numbers are shaped, how you ask questions about them, and how an alarm gets raised.

The data model, exposition format and the four metric types

Everything starts with the data model. A Prometheus time series is a metric name plus a set of labels, and every unique combination of label values is a separate series. That one sentence explains both Prometheus’ power (slice any dimension you recorded) and its most famous failure mode (put a user ID or request ID in a label and you create millions of series — a cardinality explosion that eats memory and takes the server down). Targets expose metrics over plain HTTP in the exposition format, a text payload scraped on an interval.

# What a target actually serves at /metrics — the exposition format.
# HELP http_requests_total Total HTTP requests served.
# TYPE http_requests_total counter
http_requests_total{code="200",method="get"} 42981
http_requests_total{code="500",method="get"} 17

# A gauge can go up AND down.
# TYPE node_memory_MemAvailable_bytes gauge
node_memory_MemAvailable_bytes 3.221225472e+09

# A histogram is really several series: cumulative _bucket, plus _sum and _count.
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"}   41230
http_request_duration_seconds_bucket{le="0.5"}   42800
http_request_duration_seconds_bucket{le="+Inf"}  42998
http_request_duration_seconds_sum   3120.5
http_request_duration_seconds_count 42998

The histogram-versus-summary distinction is both a reliable exam question and a reliable production mistake: buckets are cumulative and aggregatable, so you can compute a fleet-wide p99, while client-side summary quantiles are not, so averaging them across ten pods produces a meaningless number. Naming matters too — base units as a suffix (_seconds, _bytes), counters ending in _total, and a name that describes the thing measured rather than the dashboard you plan to build.

PromQL — the 28%

PromQL has two core value types and almost everything follows from telling them apart. An instant vector is one sample per series at one moment. A range vector — created by a duration selector like [5m] — is every sample in a window, and it cannot be graphed directly; it must be passed through a function that collapses it back down.

# SELECTING DATA — an instant vector, filtered by label matchers
# = equals  != not-equals  =~ regex-match  !~ regex-not-match
http_requests_total{job="checkout", code=~"5.."}

# A RANGE VECTOR — every sample in the last 5 minutes
http_requests_total{job="checkout"}[5m]

# RATES — rate() gives the per-second average increase of a COUNTER,
# and it handles counter resets for you. Always rate() BEFORE you sum():
sum by (code) (rate(http_requests_total{job="checkout"}[5m]))

# BINARY OPERATORS — matching series by their labels gives an error RATIO
  sum(rate(http_requests_total{job="checkout", code=~"5.."}[5m]))
/ sum(rate(http_requests_total{job="checkout"}[5m]))

# HISTOGRAMS — 99th-percentile latency in seconds. Keep `le` when aggregating!
histogram_quantile(0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket{job="checkout"}[5m])))

# AGGREGATING OVER TIME (a range vector collapses to one value per series)
min_over_time(node_memory_MemAvailable_bytes[1h])

# AGGREGATING OVER DIMENSIONS (collapse labels, keep the ones you name)
topk(5, sum by (pod) (rate(container_cpu_usage_seconds_total[5m])))

# TIMESTAMP METRICS — hours since the last successful backup
(time() - platform_backup_last_success_timestamp_seconds) / 3600

Four traps carry most of the marks. One: rate() and increase() take a range vector and are for counters only — meaningless on a gauge, and applying rate() to an already-summed series discards the reset handling. Two: the range must span several scrape intervals; rate(x[15s]) with a 15-second scrape gives you nothing usable. Three: by keeps the labels you list and without does the reverse — and histogram_quantile needs le kept. Four: binary operations match on identical label sets, which is why an otherwise-correct ratio returns empty when one side carries a label the other doesn’t.

Architecture, scraping and service discovery

Prometheus is a single binary that pulls. On an interval it scrapes HTTP endpoints it discovered, appends samples to a local time-series database, evaluates recording and alerting rules, and forwards firing alerts to Alertmanager, which is a separate process responsible for grouping, silencing, inhibition and routing to receivers. The Pushgateway exists only for short-lived batch jobs that die before they can be scraped — it is a narrow exception, not a general push channel, and knowing that is a classic push vs pull question.

global:
  scrape_interval: 15s        # how often we pull every target
  evaluation_interval: 15s    # how often rules are evaluated

scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs:            # SERVICE DISCOVERY: targets are not static
      - role: pod
    relabel_configs:                  # relabelling runs BEFORE the scrape
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep                  # drop every pod that isn't opted in
        regex: "true"
      - source_labels: [__meta_kubernetes_pod_label_app]
        target_label: app             # promote a pod label to a metric label

alerting:
  alertmanagers:
    - static_configs: [ { targets: ["alertmanager:9093"] } ]

rule_files:
  - /etc/prometheus/rules/*.yaml

Service discovery is why the pull model scales in Kubernetes: nothing has a stable IP, so Prometheus asks the API server what exists and re-derives its target list continuously. Relabelling is the filter in front of that — keep and drop decide what gets scraped at all, while metric_relabel_configs runs after the scrape and is your emergency brake on a high-cardinality metric. And the limitations: Prometheus stores data locally and is not a clustered database, is not built for long-term retention (that is Thanos, Mimir or Cortex), is not for event or per-request logging, and does not give billing-grade accuracy — it samples.

Instrumentation, exporters, alerting and dashboards

Metrics get in two ways. Client libraries (Go, Python, Java, Ruby, Rust and more) instrument your own code directly; exporters translate something that doesn’t speak Prometheus — node_exporter for machines, blackbox_exporter for probes, one for practically every database — into the exposition format.

from prometheus_client import Counter, Histogram, start_http_server

# Name in base units, counters end in _total, labels are LOW cardinality.
REQUESTS = Counter(
    "http_requests_total", "Total HTTP requests served.",
    ["method", "code"],          # NEVER user_id, request_id or raw URL path
)
LATENCY = Histogram(
    "http_request_duration_seconds", "Request duration in seconds.",
    buckets=[0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5],   # chosen up front
)

@LATENCY.time()
def handle(request):
    response = do_work(request)
    REQUESTS.labels(method=request.method, code=response.status).inc()
    return response

start_http_server(8000)          # exposes /metrics for Prometheus to scrape

Alerting is where the exam turns opinionated, rightly. Rules come in two kinds: recording rules precompute an expensive expression on a schedule under a new name (conventionally level:metric:operation), and alerting rules fire when an expression keeps returning series for longer than for:.

groups:
  - name: checkout-slos
    rules:
      # RECORDING rule — precompute once, query it everywhere
      - record: job:http_request_errors:ratio_rate5m
        expr: |
          sum by (job) (rate(http_requests_total{code=~"5.."}[5m]))
            / sum by (job) (rate(http_requests_total[5m]))

      # ALERTING rule — a SYMPTOM, not a cause; `for` survives a blip
      - alert: CheckoutHighErrorRate
        expr: job:http_request_errors:ratio_rate5m{job="checkout"} > 0.05
        for: 10m
        labels:
          severity: page            # Alertmanager routes on labels
        annotations:
          summary: "Checkout is serving {{ $value | humanizePercentage }} errors"
          runbook_url: https://runbooks.example.com/checkout-high-error-rate

The when, what and why competency is the philosophy behind that YAML. Alert on symptoms your users feel — error ratio, latency, saturation — not causes like “CPU is at 80%,” which may be entirely fine. Every page must be actionable and carry a runbook; anything not worth waking a human for is a ticket or a dashboard. In Alertmanager, grouping collapses a storm into one notification, inhibition suppresses downstream alerts when a parent is already firing, and silences mute known work. On the dashboard side: a panel is a PromQL query plus a visualisation, template variables make one dashboard serve many services, and the SLI/SLO/SLA vocabulary matters — an SLI is the measurement, an SLO your internal target, an SLA the contractual promise with consequences, and the error budget the gap between SLO and perfection.

How to prepare using this site

☺ Like you’re 10: Every part of the test already has a page here. Read them in this order and you’ve read the whole syllabus.

This site was written for the CNPE, so its observability material sits one layer above PCA — deeper on how a platform team runs the stack, just as deep on the mechanics. Use the middle column to pass, the right column when a concept refuses to stick.

Three to four weeks is comfortable if you have used Prometheus at all. Week one: fundamentals and the data model, until the exposition format and the four metric types are automatic. Week two: PromQL only — the largest domain and the only one needing daily repetition. Week three: alerting, Alertmanager, dashboards, instrumentation and exporters. Week four: observability concepts beyond metrics, then revise with the flashcards, quiz and glossary.

Exam logistics — and how to verify them

☺ Like you’re 10: It’s an online test you take from home with someone watching through your webcam. The price and length change, so always check the official page before you pay.

Some things about PCA are structural and safe to state; others are exactly the sort of detail The Linux Foundation revises without ceremony. This page separates the two on purpose.

What we can state with confidence

What you must check on the official page

These move: duration, question count, pass mark, price, retake policy, eligibility window and certification validity. Linux Foundation associate exams have historically clustered around a common closed-book shape — roughly a 90-minute sitting of about 60 multiple-choice questions, a price near US$250 including one free retake, a 12-month window in which to sit it, and a credential valid for two years. The question count in particular is a pattern, not a promise — no official page states one — so do not schedule against numbers from any third-party site, including this one. The pass mark is not in that category: the Linux Foundation’s Multiple Choice Exam FAQ states that “a score of 75% or above must be earned to pass the Multiple Choice Exam”, a published requirement that covers every Linux Foundation multiple-choice exam, PCA included. Aim well clear of 75%. Note too that PCA has no documentation allowlist the way the hands-on exams do — it is closed-book, so the Prometheus documentation is study material, not an exam-day resource. Don’t confuse the eligibility window (how long you have to sit the exam after buying it) with the certification validity (how long the credential lasts after you pass); both are on the official page, and both change.

↗ Official PCA page — Linux Foundation ◆ CNCF certification page ◆ Official CNCF curriculum repository

Where PCA sits in the ladder — and what to do next

☺ Like you’re 10: This badge is one specialist rung. From here you either widen to the rest of observability, or climb toward building whole platforms.

PCA is a specialist associate — narrow, deep and immediately useful, unlike the broad associates that survey a whole field. The certifications overview maps the shelf; here are the three sensible directions out.

Widen across observability

Prometheus covers metrics; its natural partner is OTCA, the OpenTelemetry associate, which covers vendor-neutral instrumentation and the traces-and-spans half PCA only touches. Together they make you the person who owns the observability plane — and this site’s OpenTelemetry, Jaeger, Loki and Grafana pages already cover most of it.

Climb toward the platform

If observability is one plane of a platform you want to build, go PCA → CNPA → CNPE: CNPA covers the discipline, CNPE puts your hands on the keyboard, and its 20% observability domain will feel like a gift after this. If the substrate underneath is still blurry, detour through KCNA or CKA first — PCA assumes you know what a Pod and a Service are.

Go build — the part that compounds

A certificate is a signal; a working stack is a skill. Take one real service and give it the full treatment: instrument it with a counter and a histogram, scrape it via a ServiceMonitor, write a recording rule and a symptom-based alert with a runbook link, route it through Alertmanager with sensible grouping, and put a four-panel golden-signals dashboard in front of it. Then define one honest SLO and watch the error budget move. That single loop is the whole PCA blueprint made real — the lab track walks it and the field notes show what it looks like when it goes wrong. And keep an eye on the official curriculum: the version you studied is not guaranteed to be the version you sit.