PCA Study Plan

The PCA blueprint lays out what the exam covers; this page decides when you study each part, and for how long. Five domains, but they are not five equal boxes: PromQL alone is 28% of the paper — bigger than Alerting & Dashboarding and Instrumentation & Exporters combined — and it is the one domain candidates reliably under-practice, because it looks like a pile of query snippets to memorize rather than what it actually is: a small, precise language with its own grammar. This plan spends four weeks the way the weights say to, and it treats PromQL accordingly — a short daily rep from day two onward, the way you'd drill vocabulary, plus a dedicated consolidation block near the end, rather than one crammed week and hoping it sticks.

Spend the calendar where the marks are

☺ Like you're 10: Don't give every topic the same number of days. Give the biggest topic the most days — and give the language-shaped topic a little practice every single day instead of one big block.

The PCA curriculum publishes five weighted domains and 26 named competencies. Read the full domain table and every competency on the PCA blueprint first if you haven't already — this page assumes you know what each domain covers and focuses purely on pacing it.

Turned into a 28-day, 50-hour domain-study budget, split by weight, with PromQL's hours deliberately spread rather than block-scheduled:

A two-minute readiness check before day one

☺ Like you're 10: Four weeks is a guess that fits most people. If you've never actually run Prometheus, give yourself more runway first.

This plan assumes you have at least one live Prometheus target you can point queries at — your own laptop with node_exporter is enough. If you already write PromQL in production and know rate() from irate() without checking, compress this to two weeks: skip the Fundamentals week's first read and go straight to the daily reps and the harder PromQL competencies (histograms, binary-operator label matching, timestamp metrics), then keep weeks 3–4 as written since Alerting, Dashboarding and Instrumentation are where self-taught PromQL users usually have real gaps. If you're comfortable with observability generally — dashboards, alerts, on-call — but Prometheus and PromQL specifically are new, run the full 28 days as written; this is exactly the candidate the plan is built for. If you've never installed Prometheus at all, spend a weekend first getting a bare Prometheus plus node_exporter running locally before you start the clock — every day of this plan assumes you have a real target to query, not just a page to read.

The 28-day schedule

☺ Like you're 10: Here's the whole four weeks on one strip — and a thin gold line underneath showing where the daily language practice runs the whole time.

The bar below is the table beneath it, drawn to scale. Block width is day count. The thin gold strip underneath the main row is not a separate week — it's PromQL running quietly beneath three other domains, the whole time you're reading about them.

Week 1 close-up — Fundamentals, the model everything else stands on

☺ Like you're 10: Before you can ask a good question, you need to know what shape the answers come in. That's this week.

Read Prometheus for the architecture, then treat the data model as the one idea worth over-learning: a time series is a metric name plus a set of labels, and every unique combination of label values is a separate series. That sentence is also where cardinality explosions come from, and "Understanding Prometheus Limitations" is a named competency for a reason — know what Prometheus deliberately does not do (long-term storage, billing-grade accuracy, general event logging) as cold as you know what it does.

# the exposition format — a plain-text payload scraped on an interval
# HELP mission_requests_total Total requests handled by mission control.
# TYPE mission_requests_total counter
mission_requests_total{code="200",method="get"} 84210
mission_requests_total{code="500",method="get"} 12

# a gauge goes up AND down — never wrap it in rate()
# TYPE mission_probe_temperature_celsius gauge
mission_probe_temperature_celsius 21.4

# a histogram is really several series: cumulative _bucket, plus _sum and _count
# TYPE mission_latency_seconds histogram
mission_latency_seconds_bucket{le="0.1"}  9310
mission_latency_seconds_bucket{le="0.5"}  9870
mission_latency_seconds_bucket{le="+Inf"} 9901
mission_latency_seconds_sum   1442.7
mission_latency_seconds_count 9901

Then read configuration and scraping the same way: Prometheus pulls on an interval, using service discovery to find targets that never have a stable IP, and relabelling to decide — before the scrape — what actually gets kept.

scrape_configs:
  - job_name: mission-control-pods
    kubernetes_sd_configs: [{role: pod}]     # SERVICE DISCOVERY — targets aren't static
    relabel_configs:                          # runs BEFORE the scrape
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: "true"

The daily PromQL rep — a language, not a snippet library

☺ Like you're 10: Every day, write one query from memory, guess what it will say back, then check. That's the whole trick — the same way you'd learn any language.

Twenty to twenty-five minutes, every day, days 2 through 21. Pick one of the seven PromQL competencies — Selecting Data, Rates and Derivatives, Aggregating over Time, Aggregating over Dimensions, Binary Operators, Histograms, Timestamp Metrics — write one expression against it from memory, predict the shape of the answer before you run it, then run it against a real target and check. That predict-before-you-run step is what separates language practice from copy-pasting a working query and feeling like you understand it.

A full progression through all seven competencies, worth writing out once by hand before you start drilling them separately:

# SELECTING DATA — an instant vector, filtered by label matchers
mission_requests_total{job="mission-control", code=~"5.."}

# a RANGE VECTOR — every sample in the last 5 minutes, via a duration selector
mission_requests_total{job="mission-control"}[5m]

# RATES — rate() reads a COUNTER's range vector and handles resets for you.
# Always rate() first, sum() second:
sum by (code) (rate(mission_requests_total{job="mission-control"}[5m]))

# BINARY OPERATORS — two instant vectors, matched on IDENTICAL label sets
  sum(rate(mission_requests_total{job="mission-control", code=~"5.."}[5m]))
/ sum(rate(mission_requests_total{job="mission-control"}[5m]))

# HISTOGRAMS — keep `le` when you aggregate, or the quantile answers nothing
histogram_quantile(0.95,
  sum by (le) (rate(mission_latency_seconds_bucket{job="mission-control"}[5m])))

# AGGREGATING OVER TIME — a range vector collapses to one value per series
max_over_time(mission_probe_temperature_celsius[1h])

# AGGREGATING OVER DIMENSIONS — by() keeps the labels named, drops the rest
topk(3, sum by (pod) (rate(container_cpu_usage_seconds_total[5m])))

# TIMESTAMP METRICS — minutes since the last successful telemetry sync
(time() - mission_telemetry_last_success_timestamp_seconds) / 60

Four query patterns cause most of the wrong predictions — treat them as the phrasebook entries worth over-learning first:

Week 2 close-up — Observability Concepts, the part everyone assumes they already know

☺ Like you're 10: This week isn't about Prometheus at all — it's about knowing which tool to reach for: a number, a written record, or a map of one request's journey.

Metrics, logs, events and traces answer different questions, and the exam wants the distinctions stated precisely: a metric answers "how much / how many, over time," a log answers "what exactly happened, in this one place," an event is a discrete, timestamped occurrence rather than a continuous measurement, and a trace — built from spans — answers "where did one request's time actually go, across every service it touched." The OpenTelemetry Data Model covers traces and spans in more depth than PCA itself requires, which is useful background for the "when, what, why" alerting judgment calls in week 3.

Push vs. pull is a one-paragraph idea worth stating cold: Prometheus pulls, on its own schedule, from targets it discovered — the Pushgateway is a narrow exception for short-lived batch jobs that die before a scrape could ever reach them, not a general push channel. Close the week with the SLI/SLO/SLA vocabulary: an SLI is the measurement, an SLO is your internal target, an SLA is the contractual promise with consequences attached, and the error budget is the gap between your SLO and perfection.

Week 3 close-up — Alerting & Dashboarding, then Instrumentation & Exporters

☺ Like you're 10: First, how a number turns into a page that wakes someone up. Then, how a number gets into Prometheus in the first place.

Alerting & Dashboarding (days 15–18) is where the exam turns opinionated. A recording rule precomputes an expensive expression under a new name; an alerting rule fires when an expression keeps returning results for longer than for:, which exists specifically to survive a blip.

groups:
  - name: mission-control-slos
    rules:
      - record: job:mission_requests_errors:ratio_rate5m
        expr: |
          sum by (job) (rate(mission_requests_total{code=~"5.."}[5m]))
            / sum by (job) (rate(mission_requests_total[5m]))
      - alert: MissionControlHighErrorRate
        expr: job:mission_requests_errors:ratio_rate5m{job="mission-control"} > 0.05
        for: 10m
        labels: {severity: page}
        annotations:
          summary: "mission-control is serving {{ $value | humanizePercentage }} errors"
          runbook_url: https://runbooks.example.dev/mission-control-error-rate

The "when, what, why" competency is the philosophy underneath that YAML: alert on symptoms a user would feel — error ratio, latency, saturation — never on causes like "CPU is at 80%," which may be entirely fine. In Alertmanager, grouping collapses a storm into one notification, inhibition suppresses a downstream alert when its parent is already firing, and a silence mutes known work. On the dashboard side: a panel is a query plus a visualization, and template variables let one dashboard serve many services — read Grafana for the mechanics.

Instrumentation & Exporters (days 19–21) is how numbers get into Prometheus at all: client libraries instrument your own code directly, exporters translate something that doesn't natively speak Prometheus — node_exporter for machines, blackbox_exporter for probes — into the exposition format.

from prometheus_client import Counter, Histogram, start_http_server

# name in base units, counters end in _total, labels stay LOW cardinality
REQUESTS = Counter(
    "mission_requests_total", "Requests handled by mission control.",
    ["method", "code"],            # never a user_id, request_id, or raw path
)
LATENCY = Histogram(
    "mission_latency_seconds", "Request duration in seconds.",
    buckets=[0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5],   # chosen up front, on purpose
)

@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

Week 4 — the PromQL consolidation block, then revision and a timed mock

☺ Like you're 10: The last week isn't for learning anything new about the other four domains. It's for pulling PromQL together into one whole grammar, then finding out — honestly — whether the first three weeks worked.

Days 22–24 are a dedicated PromQL block: not new material, but the seven competencies drilled deliberately and in combination rather than one at a time. Spend extra time on the two that PCA candidates most often under-rate — Histograms (the le-survives-aggregation rule from week 1, now under time pressure) and Timestamp Metrics (the time() - x_timestamp_seconds pattern that answers "how long since this last succeeded," the backbone of freshness and batch-job alerting). By day 24 you should be able to write all seven shapes on a blank page, unprompted, with no options to recognize.

Clear day 27's mock comfortably above 75% and you can book the real exam. Land right on the line, and hold off one more evening: patch whichever domain the mock exposed, and sit Mock Exam · Set 2 before committing a date — one score near the line is noise, two consistent scores above it is signal. Widening beyond this specialist badge afterward, OTCA picks up the traces-and-spans half of observability that PCA only touches, and the sibling CNPE has its own performance-based Observability & Operations domain that assumes exactly the PromQL depth this plan just built.

Exam-day logistics — and what to verify before you book

☺ Like you're 10: Once your four weeks are done, here's what booking the real thing involves — and a reminder to double-check every number before you pay.

These figures come from the Linux Foundation's and CNCF's official PCA pages, read in 2026.

↗ Official PCA page — Linux Foundation ◆ Multiple Choice Exam FAQ (pass mark)