What PCA is designed to validate
The Prometheus Certified Associate is a foundational credential for engineers and application developers interested in observability and cloud-native monitoring. The public program description emphasizes monitoring concepts, Prometheus architecture and data flow, metric collection, querying with PromQL, instrumentation and exporters, alert rules, Alertmanager, dashboards, and environments such as Kubernetes. It is a beginner exam, but “beginner” does not mean memorizing a glossary. A good candidate can explain why a metric type fits a behavior, predict what a query returns, and distinguish an alert-expression problem from a notification-routing problem.
PCA preparation becomes easier when every topic is connected to one lifecycle. An application or exporter exposes a metric family. Prometheus discovers the target, applies target relabeling, scrapes the endpoint, validates the exposition, applies metric relabeling, and writes samples into its time-series database. PromQL selects and combines those series. Recording rules save useful derived series. Alerting rules turn expression results into inactive, pending, or firing alert instances. Prometheus sends alert states to Alertmanager, which deduplicates, groups, routes, inhibits, silences, and notifies. A dashboard queries Prometheus and presents a decision-oriented view.
Study that lifecycle repeatedly. It prevents category errors. Alertmanager does not evaluate PromQL or store application metrics. Grafana does not make an invalid error ratio correct. A client library does not discover targets. Service discovery does not prove target health. A scrape limit does not reduce series already stored from a different job. Knowing the ownership and position of each operation is more durable than memorizing configuration fragments.
Use public objectives, not recalled questions
The CNCF publishes the curriculum around which PCA is created, and the Linux Foundation publishes exam and candidate resources. Those are the appropriate scope sources. Official Prometheus documentation is the authority for architecture, configuration, data model, PromQL, instrumentation, exporters, exposition, rules, and Alertmanager behavior. Kubernetes documentation is appropriate for Services, labels, and service discovery. Grafana documentation is relevant only when implementing Grafana dashboards.
Do not collect or share live, leaked, reconstructed, or recalled exam questions. Such material can violate confidentiality obligations, can be wrong after an update, and trains recognition rather than transferable skill. Marketplace practice content is not a technical authority. This guide, its 50 knowledge checks, its 40 flashcards, and its three projects are independently authored from public sources.
Turn official weights into a study allocation
The weights justify giving PromQL the largest focused block, but the domains are coupled. A query cannot be correct if the candidate misidentifies a gauge as a counter. A histogram percentile cannot be correct if the candidate does not understand cumulative buckets. An Alertmanager route cannot work as intended if alert labels are unstable. Use weights to allocate practice, not to create isolated silos.
Domain 1: observability concepts
Metrics are numerical measurements over time. They excel at continuous aggregate questions: request rate, error ratio, latency distribution, queue depth, saturation, and SLO compliance. Their power comes from compact repeated samples and bounded dimensions. Their limitation is detail. A metric showing an error-rate increase does not contain the complete exception, payload, or request path.
Logs record discrete events. A structured log can carry severity, event type, operation, and diagnostic context. Logs help explain what happened near a metric anomaly, but log volume is not automatically a meaningful service metric. Official Prometheus instrumentation guidance suggests that interesting log events often deserve counters so operators can see how frequently they occur and how that frequency changes. The counter and log serve different purposes.
Distributed traces follow work across service boundaries. A trace contains spans; each span represents a timed operation with relationships and contextual attributes. Traces are valuable when a request traverses several services and aggregate latency alone cannot identify the slow segment. Correlation must be designed safely. Putting every trace ID or request ID into a Prometheus label creates an unbounded series dimension. Use exemplars or links where supported, and retain request-level identifiers in an appropriate trace or log system.
An SLI is a measured indicator of a service behavior. An SLO is a target for that indicator over a window. An SLA is an agreement that may include commitments and consequences. “The ratio of eligible successful requests served within 300 milliseconds” is an SLI. “At least 99% over 28 days” is an SLO. A contract may use related commitments in an SLA. Be precise about the eligible population, error definition, time window, exclusions, and owner.
Prometheus normally uses a pull model: the server initiates HTTP scrapes. Pull centralizes collection timing and creates the automatic up metric for each target. Push has a limited role. The official Pushgateway guidance recommends it primarily for service-level batch jobs that end before reliable scraping. A Pushgateway can become a bottleneck, obscures direct instance health, and retains pushed series until they are deleted. Do not use it as a universal solution for firewall or architecture problems.
Service discovery addresses changing target identity. In a static lab, a target list may contain host and port strings. In Kubernetes, Pods come and go as Deployments scale and roll. Prometheus can watch the Kubernetes API and create targets from Pods, Services, nodes, ingresses, or EndpointSlices. Discovery supplies metadata and candidate targets; relabeling selects, drops, and normalizes them. The target must still expose a valid endpoint and be reachable and authorized.
Domain 2: Prometheus fundamentals
The Prometheus server is the center of the basic architecture. It scrapes targets, stores time-series samples locally, serves PromQL, and evaluates recording and alerting rules. Client libraries instrument application code. Exporters translate metrics from systems that cannot be directly instrumented. The Pushgateway supports the narrow short-lived batch case. Alertmanager handles alert notifications. Grafana or other API clients visualize query results.
Prometheus deliberately favors operational reliability. A server is autonomous and does not require distributed storage for its local core operation. That independence makes Prometheus useful during an outage, but it also sets expectations. It is not a complete event ledger and is not appropriate as the authoritative record for exact per-request billing. Scrapes observe current metric state at intervals and can miss events if instrumentation is wrong or the endpoint is unavailable.
The data model is dimensional. A metric name plus the complete label set identifies a series. Each label-set change creates a new series. A sample then contains a float64 or native-histogram value and a timestamp. Labels make one metric reusable across bounded dimensions such as method, normalized route, status class, service, or region. The same property makes labels dangerous when values are unbounded. One metric across 20 routes, 5 methods, 6 statuses, 10 regions, and 100 targets can already produce up to 600,000 series before other dimensions.
A scrape configuration describes a job and its targets. Important controls include scrape interval, scrape timeout, metrics path, scheme, authentication, TLS, static or dynamic discovery, target relabeling, metric relabeling, and limits. The timeout cannot exceed the interval. A target label conflict normally causes the scraped value to be renamed with an exported_ prefix while the server-side target label wins, unless honor_labels changes the behavior. Understand this rather than toggling the setting blindly.
Target relabeling occurs before scraping. It can change __address__, scheme, path, and labels, or keep and drop discovered targets. Internal labels beginning with double underscores are removed after target relabeling. Metric relabeling occurs after the scrape and before ingestion. It can drop expensive series but does not avoid the HTTP request or exporter work. Alert relabeling is a separate stage before sending alerts to Alertmanager.
Prometheus text exposition is line-oriented. HELP and TYPE metadata precede samples for a metric family. Each sample line includes a metric name or quoted metric syntax, optional labels, a value, and an optional timestamp. A unique metric-name and label combination must not be repeated in one exposition. Classic histograms expose cumulative _bucket series with le, plus _sum and _count; the positive-infinity bucket equals the count. OpenMetrics and protobuf support additional capabilities, and current Prometheus versions use content negotiation. Use client libraries where possible instead of hand-assembling output.
Configuration can be reloaded at runtime. If new configuration is malformed, it is not applied. That safety does not replace pre-deployment checks. Validate configuration and rules with promtool, review diffs, retain a known-good version, monitor reload status, and test targets after reload. Treat lifecycle endpoints and administrative APIs as privileged surfaces.
In Kubernetes, understand role selection. The service role creates a target for each Service port and is useful for black-box monitoring of a service address. The pod role exposes pod containers and ports as candidates. The node role discovers cluster nodes. The EndpointSlice role creates targets from the current backend addresses and carries Service and, when available, Pod metadata. Kubernetes deprecated the older Endpoints API in favor of EndpointSlices; use current official documentation and validate the role against the intended question.
Security is part of correctness. Keep Prometheus, Alertmanager, exporters, and dashboards private unless there is a justified protected access path. Use TLS and supported authentication, least-privilege Kubernetes list/watch permissions, read-only source access for exporters, separate identities, file-based or managed secrets, network policies, bounded payloads, and retention. Metrics can reveal topology, versions, tenant names, paths, and business activity even when they do not contain raw records.
Domain 3: PromQL
PromQL expressions evaluate to instant vectors, range vectors, scalars, or strings. An instant vector contains one sample per selected series at an evaluation timestamp. A range vector contains a time window of samples per series. A scalar is one floating-point value. Strings exist as a type but are not a normal operational result. Know the input and output type of every function you use.
An instant selector can name a metric and include label matchers. Equality uses =, inequality !=, regex match =~, and negative regex match !~. Prometheus regex matches are fully anchored. Matchers that also match an empty value can include series where the label is absent. A selector must name a metric or include at least one matcher that cannot match the empty string; an unconstrained expression such as {job=~".*"} is invalid.
A range selector appends a duration such as [5m] and returns samples in a left-open, right-closed interval. The offset modifier shifts a selector relative to evaluation time, enabling comparisons such as the current rate versus the rate one week ago. The @ modifier pins selection to a timestamp or to start() or end(). Both attach directly to the selector they modify.
rate() calculates the per-second average increase of a counter over a range, adjusts for resets, and extrapolates to the range boundaries. increase() estimates total growth over the range and is effectively rate multiplied by range seconds. irate() uses the last two samples and is most suitable for graphing volatile fast counters, not for stable alerts. The essential rule is “rate first, then aggregate.” If counters from different processes are summed before rate, one process restart can be hidden inside another process's increase and reset detection becomes unreliable.
Gauges require different reasoning. delta() estimates change between the first and last value over a range. deriv() uses linear regression to estimate per-second slope. Functions such as avg_over_time(), min_over_time(), and max_over_time() aggregate each series through time. Applying rate to queue depth or temperature can produce a number but not the intended counter meaning. PromQL often cannot prevent misuse of float metric semantics; the operator must know the type.
Aggregation operators combine dimensions at one evaluation time. sum by (service) retains only the service grouping label. sum without (instance) drops instance and preserves other labels. Choose grouping based on the output contract. Keeping route when an alert should be service-wide may create one alert per route. Removing region when failures have regional ownership may hide impact.
Binary vector operations require matching. By default, two series match when their labels match exactly. on(...) restricts the match key to listed labels; ignoring(...) removes listed labels from matching. group_left and group_right permit many-to-one or one-to-many matching. They do not permit ambiguous many-to-many arithmetic. For an error numerator grouped by method and code divided by a request denominator grouped only by method, ignoring code plus group_left can express the intended relationship.
Comparison operators filter by default. For a vector expression such as queue_depth > 100, false samples disappear and true samples retain their original value. Adding bool changes matched values to zero or one. Missing vector matches still do not materialize automatically. Logical set operators and, or, and unless combine series presence rather than arithmetic values.
A subquery evaluates an instant expression over a range and optional resolution, returning a range vector. For example, a five-minute rate evaluated across 30 minutes at one-minute resolution can feed an over-time function. Subqueries are useful for exploration and composition, but repeated wide subqueries can be expensive. Measure them. If a verified expression is used constantly by dashboards and alerts, a recording rule can provide a stable precomputed series.
Timestamps are practical metrics. Instead of exporting “seconds since last success” and updating it continuously, export the Unix timestamp of the last success. The query time() - last_success_timestamp_seconds calculates age at evaluation time and exposes a stuck updater naturally. timestamp(v) returns each selected sample's timestamp; time() returns the evaluation timestamp, not necessarily wall-clock “now” for a historical query.
Histograms, summaries, percentiles, and SLO math
Histograms and summaries both observe distributions such as latency or response size and both provide count and sum. A summary calculates configured quantiles in the instrumented client over a configured window. Those quantiles are convenient but cannot be meaningfully aggregated across instances, and different quantiles or windows cannot be reconstructed later. Averaging replica p95 values is not the p95 of all requests.
A classic histogram counts observations in configured cumulative buckets. More buckets provide resolution but create more series. Bucket boundaries should reflect expected values and important thresholds such as an SLO. A native histogram stores a dynamic bucket structure in a composite sample, supports aggregation across compatible layouts, and can provide greater resolution more efficiently. Library and ingestion support must be checked for the deployed versions rather than assumed.
For a classic histogram named http_request_duration_seconds, request rate can come from rate(http_request_duration_seconds_count[5m]). Average duration is the rate of _sum divided by the rate of _count, with each side aggregated in the same way. The fraction within an exact 300-millisecond bucket is the rate of the le="0.3" bucket divided by count rate. Because classic buckets are cumulative, that numerator includes every observation less than or equal to the boundary.
For a classic service-wide p95 by job, use histogram_quantile(0.95, sum by (job, le) (rate(http_request_duration_seconds_bucket[5m]))). The le label must remain in the aggregation because it identifies bucket boundaries. The function interpolates within the bucket containing the quantile, so accuracy depends on the bucket layout. Percentiles are estimates; display the window and avoid presenting excessive precision.
| Question | Preferred expression pattern | Common failure |
|---|---|---|
| Requests per second | sum by (service) (rate(requests_total[5m])) | Summing counters before rate and hiding resets |
| Error ratio | Error rate divided by total rate with explicit matching | Labels do not match, so expected services disappear |
| Queue maximum in an hour | max_over_time(queue_depth[1h]) | Using rate on a gauge |
| Age since success | time() - last_success_timestamp_seconds | Maintaining an age gauge that stops updating silently |
| Classic histogram p95 | histogram_quantile over sum by (..., le) of bucket rates | Dropping le or averaging summary quantiles |
| Repeated expensive indicator | Verified recording rule with bounded output labels | Copying a wide subquery into every dashboard panel |
Domain 4: instrumentation and exporters
A counter represents a cumulative quantity that rises and can reset on restart. Completed requests, failures, and bytes processed are examples. A gauge represents current state that can rise and fall, such as concurrency, memory, temperature, or queue depth. A histogram or summary observes many values, usually durations or sizes. The choice determines valid query operations.
Use a maintained Prometheus client library when application source is available. The library implements metric types, thread-safe updates, collection, and supported exposition. Place instrumentation near the code it describes. For an online-serving system, start with request count, error count, latency, and often in-progress requests. Count attempts as well as failures so a failure ratio is possible. For offline pipelines, track input, in-progress work, output, and last progress. For batch jobs, track last success and durations; use Pushgateway only for the justified service-level short-lived case.
An exporter is an adapter for a system that cannot expose useful Prometheus metrics directly. It reads an existing API, status page, protocol, or operating-system interface and translates values into stable metric families. A good exporter is not only a parser. It has timeouts, bounded collection, read-only access, collection duration, collection errors, last success, predictable behavior during partial failure, and secure handling of credentials.
Metric names should include a domain prefix, one quantity, and base-unit suffix when applicable. Durations use seconds, data sizes use bytes, ratios usually use values from zero to one, and cumulative counters end in _total. Colons are reserved for user-defined recording rules. A metric should represent the same logical thing across every label dimension; if summing or averaging all dimensions has no conceptual meaning, the family may be mixing quantities.
Use labels rather than generating names such as http_responses_500_total and http_responses_404_total; a bounded code label on one response counter is more composable. Do not overuse labels. User IDs, emails, complete URLs, request IDs, timestamps, random values, SQL text, and stack traces are poor labels. Cardinality is not merely disk cost: it affects memory, CPU, index size, query work, network transfer, dashboard rendering, and alert-instance count.
A robust lab predicts series count before deployment and measures it afterward. For a classic histogram, include one series per bucket plus sum and count for every label combination and target. Multiply deliberately. If 12 buckets are attached to five routes, four methods, five status classes, three regions, and 20 instances, the potential footprint is substantial. Remove labels that do not drive a decision, choose bucket boundaries from required accuracy, and avoid collecting unused exporter metrics.
Validate the endpoint as a protocol and as a behavioral contract. Check content type, HELP and TYPE, unique label sets, escaping, values, final line ending, histogram monotonicity, and concurrent updates. Restart the process and verify counter-aware queries. Break the source API and verify the exporter reports collection failure rather than silently exposing stale values as fresh truth. Measure endpoint size and scrape duration under worst-case fixtures.
Domain 5: alerting and dashboarding
Recording rules periodically evaluate PromQL and write new series. Use them for expressions repeatedly needed by dashboards and alerts, especially wide aggregation and histogram calculations. Rule groups evaluate at regular intervals; rules in a group run sequentially with the same evaluation time. A slow group can miss later evaluations. Monitor rule duration, errors, missed iterations, and output series count. Use per-group limits where appropriate, but understand that exceeding a limit discards the rule output for that evaluation.
Alerting rules turn expression output into alert instances. If an expression returns a vector element, the corresponding alert is active. With no for, it can become firing on the first evaluation. With for: 10m, it remains pending while the condition continues and becomes firing only after the duration. If it clears first, it becomes inactive. keep_firing_for can preserve firing state briefly after the condition clears, which may reduce flapping or transient data-loss resolutions, but it must not hide a poorly designed missing-data condition.
Labels identify alert instances and control routing, grouping, inhibition, and silences. Keep them stable and bounded: service, team, environment, severity, region, or cluster where operationally required. Annotations hold human-readable summary, description, current value, dashboard, and runbook. Putting a timestamp or complete error message in an alert label creates a new alert identity on every change and defeats deduplication.
Prometheus determines alert truth; Alertmanager manages notification behavior. Alertmanager deduplicates repeated states, groups related alerts, sends them through a routing tree, suppresses dependent alerts through inhibition, mutes matched alerts through silences, and delivers to receivers. It does not repair a bad PromQL expression. If an expected alert is absent in Prometheus, debug the rule. If it is firing in Prometheus but reaches the wrong destination, debug Alertmanager labels and routes.
Grouping reduces storms. During a cluster failure, hundreds of instance alerts may be batched by cluster and alert name into one notification containing affected instances. Notification timing matters. group_wait delays the first notification for a new group, allowing related or inhibiting alerts to arrive. group_interval governs updates for an existing group. repeat_interval controls reminders when nothing in the group changed.
Routing starts at a catch-all root. Child routes match label sets and inherit settings unless overridden. By default, matching stops after the first matching child; continue: true allows later sibling routes to match. Route order is therefore behavior, not style. Test a matrix of representative alerts, including defaults and alerts with missing labels, before sending to real responders.
Inhibition represents dependencies. A firing ClusterDown source alert can suppress InstanceDown target notifications when cluster labels are equal. The alerts still exist; only notifications are inhibited. A silence is different: it is an operator-created, time-bounded set of matchers that mutes notifications, commonly during maintenance. Every silence should be narrow, owned, explained, and expiring. A permanent broad silence is an untracked rule change.
Dashboards should answer questions. Start with service outcomes: traffic, errors, latency, saturation, availability, and SLO compliance. Add drill-down by bounded service, region, route, or status where it changes action. Show units, time windows, thresholds, and no-data states. Link to alerts, runbooks, target status, logs, and traces. Add platform health: target count, scrape duration, samples, TSDB active series, rule duration, rule failures, missed evaluations, Alertmanager delivery failures, and notification volume.
Grafana is one dashboard implementation. A Grafana dashboard contains panels that query data sources and visualize or transform results. Provision Prometheus as a restricted data source, keep variables bounded, version dashboard JSON, and review exports for embedded secrets. Use recording rules when a panel repeatedly executes expensive validated expressions. Test mobile layout, time-zone assumptions, missing series, partial outages, and high-cardinality legends.
Three projects that convert study into evidence
Each project includes at least nine implementation steps and explicitly covers architecture, security, functional and operational validation, failure injection, cardinality, cost, evidence, and cleanup. Use synthetic data and disposable environments only. The goal is not to create a permanent public monitoring endpoint; it is to prove that you can predict and validate behavior.
An eight-week PCA study plan
Week 1: observability and objectives
Read the public PCA domains, Prometheus overview, and an authoritative SLO introduction. Build a one-page comparison of metrics, logs, traces, and events. Define an SLI and SLO for a synthetic API. Explain pull versus push, the meaning of up, and why discovery does not equal health. Complete the nine Observability Concepts checks and explain every distractor.
Week 2: architecture and data model
Run Prometheus locally in a disposable environment. Scrape its own metrics and one static target. Draw the data flow. Inspect jobs, instances, labels, samples, target state, and TSDB series. Change one label and observe the new series identity. Read configuration, data-model, and metric-type documentation. Complete half of the Fundamentals checks.
Week 3: configuration, exposition, limitations, and Kubernetes discovery
Create static, file, and Kubernetes-style discovery examples. Practice target relabel keep, drop, replace, and label mapping on synthetic metadata. Compare target and metric relabeling. Inspect text exposition and a classic histogram. Validate configuration, trigger a safe reload, and test malformed YAML rejection. Explain the exact-billing limitation. Finish the Fundamentals checks.
Week 4: selectors, rates, gauges, and aggregation
Build a deterministic dataset. Practice instant and range selectors, matchers, staleness, absence, offset, and @. Compare rate, increase, irate, resets, delta, deriv, and over-time functions. Apply rate before sum across a restarted target. Practice by and without. Do not move on until you can state the unit and output labels of each result.
Week 5: vector matching, subqueries, timestamps, histograms, and cost
Construct one-to-one and many-to-one arithmetic. Predict matches before running the query. Practice comparison filters and bool. Use subqueries with explicit resolution and measure latency. Calculate ages from event timestamps. Compute histogram request rate, average, SLO-bucket ratio, and p95. Explain why summary quantiles cannot be aggregated. Complete all 14 PromQL checks twice.
Week 6: instrumentation and exporters
Complete the first project. Use a client library, design bounded labels, create counters, gauges, histograms, and timestamp metrics, and implement an exporter with collection self-metrics. Parse the exposition, restart the application, break the exporter source, and calculate expected cardinality. Complete the eight Instrumentation and Exporters checks.
Week 7: rules, Alertmanager, and dashboards
Create recording rules for verified rates, error ratios, and latency expressions. Create alert rules with labels, annotations, for, and one justified keep_firing_for. Test them with promtool. Configure Alertmanager grouping, child routes, continue behavior, inhibition, an expiring silence, and a local receiver. Build a concise Grafana dashboard. Complete the nine Alerting and Dashboarding checks.
Week 8: failure injection and timed review
Inject errors, latency, counter resets, missing series, target failure, cardinality growth, slow queries, missed rule iterations, broad silence attempts, and receiver failure. Record what the metric, query, alert, route, and dashboard show. Complete all 50 original checks under a 90-minute limit, review mistakes by domain, revisit official docs, and repeat after remediation. Then verify official exam-day instructions.
A practical readiness standard
Readiness is not a practice-score percentage alone. For Observability Concepts, explain which signal answers which question and create a valid SLI. For Fundamentals, draw the architecture, trace data flow, explain series identity, distinguish relabel stages, validate exposition, and identify a Prometheus limitation. For PromQL, predict types, units, label sets, resets, missing matches, histogram requirements, and query cost. For Instrumentation, justify each metric type and label and calculate cardinality. For Alerting, predict pending and firing states and distinguish grouping, inhibition, silences, and routes.
Use error classification. A factual error means the concept was unknown. A semantic error means a counter, gauge, histogram, or label was misunderstood. A query-shape error means types or vector matching were wrong. A scope error means the candidate confused Prometheus, Alertmanager, Grafana, exporter, or Kubernetes responsibilities. A reading error means a qualifier such as “per second,” “per job,” “sustained,” or “before ingestion” was missed. Fix the category, not just the question.
When reviewing a multiple-choice scenario, first identify the required outcome and component. Then identify data type and time window. Predict labels and cardinality. Eliminate options that violate metric semantics, move work into the wrong component, create unbounded labels, suppress rather than solve the condition, or claim guarantees Prometheus does not provide. Finally verify with official documentation or a minimal lab.
Common PCA preparation mistakes
- Memorizing syntax without units. A query may parse while answering the wrong question.
- Using rate on gauges. Know the metric's behavior before choosing a function.
- Aggregating counters before rate. Reset detection must see each source series.
- Dropping le from classic-histogram aggregation. The quantile function needs bucket boundaries.
- Averaging summary quantiles. It does not create a global percentile.
- Assuming no data means zero. Missing series, stale series, failed scrapes, and true zero are different states.
- Using unbounded labels. User, request, URL, timestamp, and error-message values explode series and may leak data.
- Confusing target and metric relabeling. One acts before scrape; the other acts before ingestion.
- Confusing alert truth and notification policy. Prometheus evaluates rules; Alertmanager routes notifications.
- Using a silence as a fix. Silences mute notifications but do not repair the rule or service.
- Copying every Kubernetes label. Discovery metadata should be whitelisted based on operational use.
- Building dashboards with raw series. Reduce and aggregate before graphing; use recording rules for repeated expensive work.
- Skipping self-monitoring. Scrapes, TSDB, rules, Alertmanager, exporters, and dashboards can fail independently.
- Relying on recalled questions. Confidential material is unethical, unstable, and less useful than durable understanding.
Exam-day preparation
The exam is listed as online, proctored, multiple choice, and 90 minutes. That description is not a substitute for current candidate instructions. Before scheduling, verify exam eligibility, validity, retake, identification, name matching, supported operating system and browser, room and camera requirements, scheduling rules, rescheduling policy, allowed items, language, and support process from the official Linux Foundation resources.
Run the required system check early enough to fix issues. Use a stable network and power source. Close prohibited applications and remove extra materials according to the current instructions. Do not assume that rules from another Linux Foundation exam apply. During the exam, read qualifiers carefully, choose the component responsible for the behavior, and reason from metric semantics and data flow. Do not attempt to record, copy, or reconstruct questions.
Connect certification study to career evidence
A certification can show validated foundational knowledge, but a portfolio demonstrates method. Publish sanitized architecture diagrams, a metrics contract, bounded label rationale, expected-series calculation, sample exposition, PromQL workbook, rule tests, Alertmanager routing matrix, dashboard JSON, failure-injection timeline, access tests, query and storage measurements, cleanup proof, and explicit limitations.
State claims precisely. “Built a disposable Kubernetes lab that discovered EndpointSlice-backed targets and tested Prometheus rules” is stronger than “expert in production observability.” Synthetic success does not prove enterprise scale, every failure mode, or regulatory compliance. Use the jobs surface to research local role language and the career surface to convert evidence into accurate capability statements. Common adjacent roles include site reliability, platform, DevOps, cloud, observability, monitoring, and application engineering, but titles and requirements vary.
Continue across PrepKloud
Official and authoritative references
- CNCF — Prometheus Certified Associate: public purpose, domains, weights, delivery, and curriculum link.
- Linux Foundation — Prometheus Certified Associate: current duration, level, validity, registration, and candidate resources.
- CNCF curriculum repository: latest open certification curricula.
- Linux Foundation Candidate Handbook: current candidate policies and delivery guidance.
- Prometheus overview: features, components, architecture, fit, and limitations.
- Prometheus data model: time series, metric names, labels, samples, and timestamps.
- Prometheus metric types: counters, gauges, histograms, summaries, and native-histogram behavior.
- Prometheus configuration: scraping, service discovery, relabeling, security options, limits, Alertmanager targets, and storage.
- PromQL basics: types, selectors, time modifiers, subqueries, staleness, and query safety.
- PromQL operators: arithmetic, comparison, set operations, aggregation, and vector matching.
- PromQL functions: rate, increase, gauge functions, histogram functions, timestamps, and over-time aggregation.
- Histograms and summaries: buckets, averages, quantiles, aggregation, errors, and visualization.
- Prometheus client libraries: supported instrumentation approach and language libraries.
- Exporters and integrations: official and community adapters for systems that cannot be instrumented directly.
- Exposition formats: text, OpenMetrics, protobuf, content types, and sample syntax.
- Instrumentation practices: service patterns, labels, metric types, timestamps, missing metrics, and performance.
- Metric and label naming: prefixes, base units, suffixes, labels, and cardinality.
- Recording rules: rule groups, stored results, syntax checks, limits, and missed evaluations.
- Alerting rules: expressions, for, keep_firing_for, labels, annotations, and states.
- Alertmanager concepts: grouping, inhibition, silences, deduplication, routing, and high availability.
- Alertmanager configuration: routing tree, timing, inhibition rules, receivers, matchers, and validation.
- Rule unit testing: promtool test fixtures and expected rule behavior.
- Pushgateway guidance: recommended use case, pitfalls, and alternatives.
- Kubernetes Services: Pods, Services, EndpointSlices, selectors, ports, and discovery.
- Kubernetes labels and selectors: metadata, selection, and grouping semantics.
- Grafana dashboards: dashboard, panel, data-source, variable, and management concepts used in the optional implementation labs.
Frequently asked questions
Is PCA an active certification in 2026?
Yes. As verified on August 20, 2026, CNCF and the Linux Foundation list Prometheus Certified Associate as an active beginner certification. The official description states that it is an online, proctored, multiple-choice exam. Recheck the official pages before registration because programs and policies can change.
What are the PCA duration and credential validity?
The official Linux Foundation page currently lists 90 minutes for the exam and two years for certification validity. It also provides current registration and candidate resources. Verify scheduling, eligibility, retake, identification, system, and environment rules directly before the appointment.
Which domain deserves the most study time?
PromQL has the largest public weight at 28%. Prometheus Fundamentals is 20%; Observability Concepts and Alerting and Dashboarding are each 18%; Instrumentation and Exporters is 16%. Spend the largest focused practice block on PromQL while continually connecting queries to metric semantics and architecture.
How much hands-on practice is useful?
At minimum, instrument one synthetic service, expose and scrape metrics, write selectors and reset-safe rates, calculate a histogram SLO, create and test recording and alerting rules, route alerts through Alertmanager, and build a small dashboard. Add Kubernetes EndpointSlice discovery if possible.
Are PrepKloud PCA checks copied from the exam?
No. All checks, cards, projects, roadmap material, and this guide are independently authored from the public PCA curriculum and official documentation. No live, recalled, leaked, confidential, or marketplace exam content is reproduced, and no particular exam form is predicted.
What should I verify before taking PCA?
Read the current official exam page, candidate handbook, confidentiality agreement, and multiple-choice exam instructions. Verify your account name and ID, eligibility period, scheduling and rescheduling rules, system check, supported environment, room requirements, allowed items, time, validity, retake, and support channel.