Key takeaways
- PromQL is the heaviest domain at 28%; practise it every day rather than in one block.
- Most wrong PromQL options break one of a few documented rules: label matching, rate before aggregation, keeping le, or rate over irate in alerts.
- Run a local Prometheus with one exporter; predicting a query result and then checking it is the fastest way to learn the language.
- At 75% you need about 45 of 60 correct, with roughly 90 seconds per question.
- Book when first-attempt accuracy on new questions stays above the pass mark in every domain, PromQL included.
On this page
What PCA tests, in numbers
PCA is delivered online with a remote proctor, like the other CNCF multiple-choice exams. It has 60 questions, 90 minutes and a 75% pass mark; the list price is $250 and the certification is valid for 2 years. The five domain weights below come from the CNCF curriculum and are the best guide to where your hours should go.
| Domain | Weight | Curriculum topics |
|---|---|---|
| Observability Concepts | 18% | Metrics; logs and events; tracing and spans; push vs pull; service discovery; SLOs, SLAs and SLIs |
| Prometheus Fundamentals | 20% | System architecture; configuration and scraping; limitations; data model and labels; exposition format |
| PromQL | 28% | Selecting data; rates and derivatives; aggregating over time and over dimensions; binary operators; histograms; timestamp metrics |
| Instrumentation and Exporters | 16% | Client libraries; instrumentation; exporters; structuring and naming metrics |
| Alerting & Dashboarding | 18% | Dashboarding basics; alerting rules; Alertmanager; alerting basics (when, what and why) |
Observability concepts and Prometheus fundamentals
The two conceptual domains are mostly about knowing where Prometheus fits and where it deliberately stops. Prometheus pulls metrics from targets it discovers; it stores numeric time series identified by a metric name and labels; and it is not a log store, a tracing system or a long-term archive by itself. Questions here test whether you can match a signal to a question and a component to a job.
- Metrics answer "how much and how often", logs answer "what happened", traces answer "where did the time go across services".
- Pull means Prometheus scrapes targets on an interval; push is the exception, for short-lived jobs that cannot be scraped.
- A time series is a metric name plus a unique set of label values, so every new label value creates a new series.
- The text exposition format is what a target returns on its metrics endpoint: HELP and TYPE lines, then samples.
- An SLI is the measurement, an SLO is the target for it, and an SLA is the agreement with consequences if the target is missed.
PromQL: the rules behind most wrong options
PromQL questions usually offer several expressions that look plausible. In most cases the wrong ones break one of a small set of rules the Prometheus documentation states explicitly. Learn these rules as sentences and check every option against them.
Vector matching needs the same labels
The operators page says two entries match if they have the exact same set of labels and corresponding values. Dividing errors labelled by method and code by requests labelled only by method returns nothing until you add ignoring(code) or on(method). When one side has several series per match, group_left or group_right allows many-to-one or one-to-many matching.
Take rate() first, then aggregate
The functions page says that when rate() is combined with an aggregation such as sum(), you should always take rate() first and then aggregate, because rate() cannot detect counter resets otherwise. sum by (job) (rate(http_requests_total[5m])) is the safe shape.
irate() is for graphs, rate() is for alerts
irate() looks only at the last two samples in the range. The documentation says it should only be used when graphing volatile, fast-moving counters, and that rate() should be used for alerts, because brief changes in the rate can reset the for clause.
Keep le for histogram_quantile()
For classic histograms, histogram_quantile() needs the le label, so an aggregation of bucket series must keep it in the by clause: sum by (job, le) (rate(http_request_duration_seconds_bucket[10m])). The histograms page adds the companion fact: summaries cannot be aggregated across instances, histograms can.
Instrumentation, exporters and naming
This domain asks how metrics come into existence: a client library inside your code, or an exporter that translates another system’s state into the exposition format. Naming questions follow the Prometheus naming page closely, so read it once and treat it as a checklist. Expect questions to show two metric names and ask which follows the conventions.
- Use base units in metric names: seconds and bytes, not milliseconds and megabytes.
- Give the unit as a plural suffix, and end counters in _total.
- Do not put high-cardinality values such as user IDs into labels; each value creates a series.
| Choice | Use when |
|---|---|
| Counter | A value only goes up and resets on restart: requests served, errors, bytes sent |
| Gauge | A value goes up and down: memory in use, queue length, temperature |
| Histogram | You need distributions you can aggregate across instances: request durations, sizes |
| Summary | You need precise quantiles from one instance and will not aggregate them |
| Exporter | You cannot change the code of the system you want to measure |
Alerting and dashboarding
Alerting questions are about the path from an expression to a notification. A rule evaluates an expression; while it is true but the for duration has not passed, the alert is pending; once it has stayed true for that long it fires and is sent to Alertmanager, which handles silencing, inhibition and aggregation and sends the notification. Recording rules are separate: they precompute an expression and store the result as a new series.
- Write the expression and check it returns what you expect in the expression browser.
- Add a for duration so short spikes do not page anyone; the alert is pending until it passes.
- Add labels for routing, such as severity, and annotations for the human-readable message.
- Route by labels in Alertmanager, and use grouping so one outage sends one notification.
- For dashboards, record expensive expressions with a recording rule named level:metric:operations.
A four-week PCA plan
The plan gives PromQL attention every week instead of leaving it to the end, because query intuition builds slowly. Each day starts with due reviews and ends with one query you predict, run and compare. GoldenKube has 539 PCA questions, more than you will need to see; the point is to let missed questions return until they stick.
| Week | Main work | Milestone |
|---|---|---|
| 1 | Local Prometheus and node exporter running; concepts and fundamentals; first PromQL selectors | You can explain a scrape config and a series identity in your own words |
| 2 | PromQL: rates, aggregation, vector matching, histograms; daily query predictions | You can say what labels survive an aggregation before running it |
| 3 | Instrumentation and naming; alerting and recording rules; Alertmanager routing | One recording rule and one alerting rule written and loaded |
| 4 | Timed mock exams, review of every miss, light PromQL daily | Every domain above the pass mark on new questions |
How to tell you are ready to book
Readiness is first-attempt accuracy on questions you have not seen, not your score on questions you remember. Take a timed mock in the published format, read the result by domain, and book only when every domain is above the pass mark, PromQL included. If PromQL is still the weakest domain, give it another week; it is the largest domain and the one where a guess is most often wrong.
- Two timed mocks in a row above the pass mark, a few days apart.
- No domain below the pass mark on new questions.
- You can explain why each wrong PromQL option is wrong, not just pick the right one.
Frequently asked questions
Is PCA harder than KCNA?
It is narrower but deeper. KCNA asks about many projects at a high level; PCA asks you to predict what a specific expression returns, what a label set looks like after aggregation or when an alert fires. People who read PromQL daily find it comfortable; people who only look at dashboards usually need the most time on the query domain.
Do I need to write PromQL in the exam?
No. The exam is multiple-choice, so you choose between expressions or results rather than typing them. The options are often very close, which is why writing and running queries yourself before the exam helps so much.
Which Prometheus version does PCA cover?
The curriculum does not name a Prometheus version. This guide cites the current Prometheus documentation; where newer features such as native histograms differ from classic histograms, learn the classic behaviour first, because the curriculum topics describe the core model.
How long should I study for PCA?
The Linux Foundation does not publish a recommended preparation time. The four-week plan here assumes a few hours a week and some exposure to metrics; if you already write alerting rules at work, two weeks of focused PromQL and concepts practice may be enough.
Does PCA count toward Golden Kubestronaut?
Yes. PCA is one of the exams on the Golden Kubestronaut list, alongside the Kubestronaut five and the other CNCF associate and professional exams. It has no prerequisite, so it can be taken at any point in the path.
What is the difference between PCA and OTCA?
PCA covers Prometheus: metrics, PromQL and alerting. OTCA covers OpenTelemetry: the API and SDK, the Collector and telemetry pipelines across metrics, traces and logs. The comparison page sets the two side by side.
Can I use the Prometheus documentation during the exam?
No. The multiple-choice FAQ says no resources are allowed, so PromQL functions, operators and naming rules must come from memory. That is why the plan has you predict query results before running them.
Sources
Every exam fact on this page comes from these pages, read on the date shown.
- Linux Foundation: Prometheus Certified Associate (PCA) certification page, checked
- CNCF curriculum: PCA Curriculum (PDF), checked
- Multiple-choice exam instructions, Linux Foundation certification docs, checked
- Multiple-choice exam FAQ, Linux Foundation certification docs, checked
- Prometheus docs: Operators, checked
- Prometheus docs: Query functions, checked
- Prometheus docs: Recording rules, checked
- Prometheus docs: Alerting rules, checked
- Prometheus docs: Histograms and summaries, checked
- Prometheus docs: Metric and label naming, checked
- Prometheus docs: Alerting overview, checked