Prometheus Certified Associate (PCA) Roadmap

Learn why metrics, logs, traces, and events answer different questions. Tie telemetry to service outcomes before studying syntax.

• Describe metrics as numerical measurements recorded over time
• Use logs for discrete event context and traces for timed request flow
• Explain traces, spans, parent-child relationships, attributes, and correlation
• Distinguish telemetry collection from observability as investigation capability
• Define SLIs as measurements and SLOs as targets over windows
• Distinguish internal SLOs from broader SLAs and potential consequences
• Design availability, latency, error, freshness, and throughput indicators
• Explain the pull model and automatic target health through up
• Recognize the narrow service-level batch-job use case for Pushgateway
• Explain why service discovery fits ephemeral workloads
• Map symptom metrics to related logs, traces, deployments, and runbooks
• Avoid copying identities, URLs, log messages, or trace IDs into unbounded labels

Evidence outcome: an observability signal map, one SLI/SLO specification, a pull-versus-push decision note, and a short incident walkthrough that moves from metric symptom to trace and log evidence.

Follow a sample from instrumentation or exporter through discovery, scrape, relabeling, storage, rules, query, alert state, notification, and dashboard.

• Identify the Prometheus server, client libraries, exporters, Pushgateway, Alertmanager, and visualization clients
• Explain the standalone server design and local TSDB reliability goal
• Define series identity from metric name and the full label set
• Define samples as float or native-histogram values with timestamps
• Distinguish jobs, instances, scrape targets, target labels, and stored labels
• Configure scrape intervals, timeouts, paths, schemes, static targets, and discovery
• Use target relabeling before scrape and metric relabeling before ingestion
• Understand Kubernetes Pod, Service, node, ingress, and EndpointSlice discovery roles
• Prefer EndpointSlice over the deprecated Endpoints API for current Kubernetes designs
• Read HELP, TYPE, sample, label, value, timestamp, histogram, and line-ending exposition rules
• Validate and reload configuration without replacing a known-good config with malformed YAML
• Describe retention, scrape, body, sample, label, and target controls
• Recognize that Prometheus is not a perfect transactional ledger for exact billing
• Protect metrics endpoints, UIs, API credentials, receiver secrets, and configuration files

Evidence outcome: a local Prometheus architecture, valid scrape configuration, exposition inspection, Kubernetes discovery lab, relabeling examples, access tests, and a documented limitation analysis.

PromQL carries the largest official weight. Practice against deterministic data so every expression has a known result rather than merely producing a plausible graph.

• Distinguish instant vectors, range vectors, scalars, and strings
• Use equality, inequality, regex, and negative regex label matchers
• Understand missing labels, empty values, lookback, staleness, and absent series
• Use range selectors, offset, and @ with explicit time reasoning
• Apply rate before aggregation so counter resets remain detectable
• Use increase for window totals and irate only for appropriate volatile graphing
• Use delta, deriv, predict_linear, and over-time functions only with suitable gauge semantics
• Aggregate with sum, avg, min, max, count, topk, by, and without
• Control vector matching with on, ignoring, group_left, and group_right
• Use comparison filtering and understand the bool modifier
• Use logical set operators and distinguish them from arithmetic
• Build subqueries with explicit range and resolution and measure their cost
• Calculate ages with time and timestamp-valued metrics
• Calculate classic-histogram rates, averages, bucket ratios, and quantiles
• Retain le when aggregating classic buckets for histogram_quantile
• Explain why summary quantiles cannot be meaningfully averaged across replicas
• Start broad query exploration in table view and reduce output before graphing
• Create recording rules for verified, repeated, expensive expressions

Evidence outcome: a versioned PromQL workbook covering selectors, temporal modifiers, rates, gauges, aggregations, vector matching, subqueries, timestamps, histograms, missing data, counter resets, and query-cost measurements.

Correct PromQL begins with correct metric semantics. Instrument one service directly and translate one system through an exporter.

• Use counters for cumulative events that rise and reset
• Use gauges for current values that rise and fall
• Use histograms for aggregatable distributions and SLO bucket ratios
• Understand summaries, client-side quantiles, windows, and aggregation limits
• Choose native, classic, or summary behavior from current library support and requirements
• Name metrics with domain prefixes, one quantity, base units, and _total counters
• Reserve colons for user-defined recording rules
• Use labels for bounded dimensions rather than procedurally generated metric names
• Estimate cardinality as the product of label-value combinations across targets
• Instrument traffic, errors, latency, concurrency, saturation, and last-success timestamps
• Initialize expected zero series when missing metrics would be ambiguous
• Use maintained client libraries when source code is available
• Use exporters when existing systems cannot be instrumented directly
• Expose exporter collection duration, errors, and last success
• Validate content type, exposition, concurrency, failure behavior, and resource overhead

Evidence outcome: an instrumented synthetic API, a bounded custom exporter, a metrics contract, parser tests, reset tests, security checks, a cardinality budget, and a measured overhead report.

Complete the feedback loop: precompute stable indicators, detect sustained symptoms, route notifications, visualize outcomes, test failure, and review weak domains.

• Distinguish recording rules from alerting rules
• Understand inactive, pending, and firing alert states
• Use for for sustained conditions and keep_firing_for only with a reason
• Keep stable routing identity in labels and human context in annotations
• Validate rules with promtool syntax checks and unit-test fixtures
• Use Alertmanager for deduplication, grouping, routing, throttling, silencing, and inhibition
• Design a catch-all root route and ordered child routes
• Understand continue, inherited settings, group_wait, group_interval, and repeat_interval
• Use inhibition for dependent symptoms and silences for bounded maintenance
• Build dashboards around outcomes, units, windows, bounded variables, and action links
• Use Grafana only as the dashboard implementation layer; keep PromQL behavior grounded in Prometheus docs
• Monitor Prometheus, rule, Alertmanager, exporter, target, and dashboard health
• Inject latency, errors, missing series, counter resets, target loss, rule delay, and notification failure
• Measure active series, samples, query duration, rule duration, storage, and alert volume
• Complete two timed 50-check reviews and analyze errors by official domain
• Recheck official exam instructions and complete environment checks before exam day

Evidence outcome: tested recording and alerting rules, an Alertmanager routing matrix, responsive dashboards, a failure-injection incident report, cost and security findings, two timed practice reviews, and an exam-day checklist.