Prometheus Certified Associate (PCA) Practice Exam

What the Prometheus Certified Associate (PCA) exam covers

• Observability Concepts103 questions
• Prometheus Fundamentals162 questions
• PromQL172 questions
• Instrumentation and Exporters136 questions
• Alerting and Dashboards125 questions

Free PCA practice test questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 693.

1. Question 1Observability Concepts

   What type of monitoring system is Prometheus?

   • AA metrics-based, time-series monitoring and alerting system that pulls (scrapes) metricsCorrect
   • BA log aggregation and full-text search platform that indexes application log lines
   • CA distributed tracing backend that stores request spans across microservices
   • DAn event-streaming message broker that buffers telemetry between producers and consumers
   ✓ Correct answer: A

   Prometheus is a metrics system: it stores numeric time series and evaluates alerting rules over them, and it collects by pulling from HTTP endpoints on a schedule it controls rather than waiting to be pushed to. Both halves matter for the exam. It is not a log or trace store, and the pull model is what gives it a per-target health signal for free on every scrape.

   Why the other options are wrong

   • BThat describes log-search systems like Loki or Elasticsearch, not Prometheus, which stores numeric time series.
   • CStoring request spans describes a tracing backend such as Jaeger or Tempo, not Prometheus.
   • DBuffering telemetry as a message broker describes Kafka-style systems, not a metrics monitoring server.
2. Question 2Prometheus Fundamentals

   To automate scrape-target generation for hosts that change frequently but are not in any supported service discovery, you want Prometheus to read a JSON/YAML file that an external script rewrites. Which discovery mechanism fits?

   • Afile_sd_config pointing at files that your script regenerates; Prometheus watches and reloads them automaticallyCorrect
   • Bremote_write carrying the current list of scrape targets to Prometheus so it discovers them from the incoming stream
   • Cstatic_configs listing every host inline, which you must edit and reload by hand each time the target set changes
   • DA recording rule that continuously emits the current set of targets as a metric that Prometheus then scrapes back
   ✓ Correct answer: A

   file_sd_config is the escape hatch for anything with no native discovery: point it at JSON or YAML files, have whatever owns the truth regenerate them, and Prometheus picks up the change automatically - it watches the files and also re-reads them periodically, so no reload is needed. Write the file atomically (write, then rename) or a half-written file can be read mid-update. The alternatives break in the usual ways: remote_write carries samples rather than targets, static_configs is the hand-editing this replaces, and a recording rule produces a series, which is not something Prometheus can scrape.

   Why the other options are wrong

   • Bremote_write ships sample data, not a file-based list of scrape targets.
   • Cstatic_configs requires manual edits and reloads, defeating the file-watching automation.
   • DRecording rules produce metric series and cannot generate discovery targets.
3. Question 3Prometheus Fundamentals

   In a Kubernetes cluster you want Prometheus to automatically discover and scrape new pods as they are created, applying per-pod scrape settings from annotations. Which design is correct?

   • AHave each pod push to the Pushgateway on a schedule and never scrape at all
   • BMaintain a static_configs list and redeploy Prometheus whenever any pod changes
   • CUse kubernetes_sd_config for the pod role and relabel_configs to act on pod annotations/labelsCorrect
   • DPoint node_exporter at the Kubernetes API so that it enumerates the pods
   ✓ Correct answer: C

   kubernetes_sd_config with role: pod watches the API server and produces a target per pod container port, each carrying __meta_kubernetes_pod_annotation_* and _label_* meta labels. relabel_configs then reads those: keep only pods annotated for scraping, take the path and port from their annotations, and map namespace and pod name into labels. New pods are picked up as they appear, with no reload. The alternatives all give up the automation: a static_configs list needs a redeploy per pod change, pushing to a Pushgateway loses the per-pod up signal and leaves dead pods reporting forever, and node_exporter reports host metrics rather than enumerating the API.

   Why the other options are wrong

   • APushing from every pod abandons the up metric and target health that scraping provides, and the Pushgateway keeps stale values after a pod goes away.
   • BA hand-maintained static_configs list plus a redeploy on every pod change is precisely the manual work Kubernetes service discovery exists to remove.
   • Dnode_exporter reports on the host it runs on and cannot be aimed at the Kubernetes API to enumerate pods.
4. Question 4Instrumentation and Exporters

   You run blackbox_exporter to probe 5,000 endpoints, and the single exporter instance is CPU-bound during each scrape cycle. Which approach best optimizes performance and cost?

   • ARun multiple blackbox_exporter instances and distribute probe targets across them, staggering scrape schedulesCorrect
   • BIncrease the number of probe modules so that each target runs several more checks per scrape
   • CSwitch to node_exporter and have it perform all of the endpoint probes instead
   • DAdd all five thousand URLs to Alertmanager as receivers in order to offload the probing
   ✓ Correct answer: A

   blackbox_exporter performs each probe synchronously when Prometheus scrapes it, so 5,000 targets on one instance means 5,000 network requests concentrated into each scrape cycle. The fix is horizontal: run several exporter instances and shard the targets across them, so each handles a fraction of the work. Staggering the scrape schedules of those jobs spreads the load in time as well, avoiding a synchronised burst. Adding probe modules increases the work per target, node_exporter cannot probe remote endpoints at all, and Alertmanager receivers deliver notifications rather than performing checks.

   Why the other options are wrong

   • BMore modules per target increases work per scrape, worsening the CPU bottleneck.
   • Cnode_exporter reports host metrics and cannot probe external endpoints.
   • DAlertmanager receivers deliver notifications and cannot probe URLs.
5. Question 5Instrumentation and Exporters

   A compliance scan asks what stops an untrusted client from overwriting or deleting metric groups on your Pushgateway. Which statement correctly describes securing it?

   • AThe Pushgateway signs each pushed group with the client certificate, so any tampering is already prevented for you
   • BSet --web.enable-lifecycle on the Pushgateway so that it requires authenticated deletes from every client
   • CThe Pushgateway has no per-client authorization, so restrict it with network controls and front it with TLS/authCorrect
   • DAdd basic_auth to the Pushgateway scrape job in prometheus.yml in order to protect the push endpoint itself
   ✓ Correct answer: C

   The Pushgateway has no notion of who owns a grouping key, so any client allowed to reach the push API can overwrite or remove any group, whether or not a shared credential sits in front of it. That is a deliberate design decision rather than a defect, and the documented mitigation is external: restrict network reachability so only the hosts that run batch jobs can connect, and front it with a reverse proxy that terminates TLS and enforces authentication. It does accept a --web.config.file that turns on TLS and HTTP basic auth, but that authenticates the connection rather than the owner of a group, so the network boundary remains the primary control. It does not verify client certificates on pushed groups. The Pushgateway's --web.enable-lifecycle exposes a shutdown endpoint rather than adding auth, and basic_auth in the Prometheus scrape job authenticates Prometheus reading the Pushgateway, not clients pushing to it.

   Why the other options are wrong

   • AThe Pushgateway does not sign or verify pushes; anyone who can reach the push endpoint can overwrite or delete groups, so this claim is false.
   • BThe Pushgateway does have a --web.enable-lifecycle flag, but it only enables shutdown over HTTP - more attack surface, and not an authentication or authorization control.
   • Dbasic_auth in a prometheus.yml scrape job authenticates Prometheus to the target on scrape; it does not protect the inbound push/delete API of the Pushgateway.
6. Question 6PromQL

   Which PromQL subquery syntax evaluates 'rate(http_requests_total[5m])' at 1-minute resolution over the past 30 minutes?

   • Arate(http_requests_total[5m])[30m]
   • Brate(http_requests_total[5m])[30m:1m]Correct
   • Csubquery(rate(http_requests_total[5m]), 30m, 1m)
   • Drate(http_requests_total[5m] offset 30m)[1m]
   ✓ Correct answer: B

   PromQL subqueries use the syntax expr[range:resolution], where range is how far back to evaluate and resolution is the step between evaluations. rate(http_requests_total[5m])[30m:1m] evaluates the rate expression at every 1-minute mark going back 30 minutes, producing a range vector that functions like overtime aggregation functions such as max_over_time() or avg_over_time() can then operate on. If resolution is omitted, the global evaluation_interval is used.

   Why the other options are wrong

   • Arate(...)[30m] without a colon and resolution is not valid subquery syntax - the colon separating range from resolution is required to trigger subquery parsing.
   • Csubquery() is not a PromQL function - subqueries are expressed with bracket syntax on instant-vector expressions, not a dedicated function call.
   • Drate(metric[5m] offset 30m)[1m] applies an offset to the selector and then attempts an invalid range bracket on an instant vector - this is not correct subquery syntax.
7. Question 7Observability Concepts

   A monitoring lead wants to define an SLO and asks where the target threshold (e.g., '99.9% of requests under 200ms') belongs. In SLI/SLO terminology, what is this percentage target called?

   • AThe Service Level Indicator
   • BThe Service Level Agreement
   • CThe Service Level ObjectiveCorrect
   • DThe error budget burn rate
   ✓ Correct answer: C

   The threshold belongs to the objective. The indicator is the measured quantity, here the fraction of requests under 200ms, and the objective is the target set against it, here that the fraction should be at least 99.9%. Keeping them apart is what lets a team tighten or relax the target without changing what is being measured or how.

   Why the other options are wrong

   • AThe SLI is the underlying measurement, not the target threshold.
   • BAn SLA is a customer-facing contract, typically looser than the internal SLO.
   • DBurn rate measures how fast the error budget is consumed, not the target itself.
8. Question 8Prometheus Fundamentals

   Which Prometheus HTTP endpoint exposes the server's own internal telemetry for self-monitoring?

   • A/metricsCorrect
   • B/-/healthy
   • C/api/v1/query
   • D/-/reload
   ✓ Correct answer: A

   Prometheus exposes its own metrics at /metrics in the ordinary exposition format, which means it can be scraped like any other target - and it should be, by itself or by a peer. That self-scrape is where the operational signals live: prometheus_tsdb_head_series for cardinality, prometheus_rule_evaluation_duration_seconds for rules running late, prometheus_remote_storage_samples_pending for a remote_write queue falling behind. The rejected endpoints do other jobs: /-/healthy and /-/ready are liveness and readiness probes returning a status rather than metrics, /api/v1/query runs PromQL, and /-/reload re-reads the configuration.

   Why the other options are wrong

   • B/-/healthy returns a liveness status, not the metrics exposition.
   • C/api/v1/query executes PromQL queries; it does not expose the exposition format.
   • D/-/reload triggers a configuration reload and returns no metrics.
9. Question 9Instrumentation and Exporters

   You need to collect filesystem, CPU, and memory metrics from a Linux VM. Which exporter is the standard choice and on what default port does it listen?

   • Anode_exporter on port 9100Correct
   • BcAdvisor on port 8080
   • Cwindows_exporter on port 9182
   • Dblackbox_exporter on port 9115
   ✓ Correct answer: A

   node_exporter is the official exporter for Linux and other Unix-like hosts, and it listens on port 9100 by default. It exposes hardware and kernel metrics gathered from procfs and sysfs, including CPU time by mode, memory and swap usage, filesystem size and free space, disk I/O, network device counters and load average, under the node_ prefix. cAdvisor on port 8080 reports per-container resource usage rather than host-level metrics, so it answers a different question. windows_exporter on 9182 is the Windows equivalent and does not run on Linux. blackbox_exporter on 9115 probes endpoints over HTTP, TCP, DNS and ICMP from outside and reports nothing about the machine it runs on.

   Why the other options are wrong

   • BcAdvisor exposes per-container metrics on 8080, not general Linux host metrics.
   • Cwindows_exporter targets Windows servers on 9182, not Linux.
   • Dblackbox_exporter performs external endpoint probing on 9115, not host metrics.
10. Question 10Alerting and DashboardsSelect all that apply

    Which TWO statements correctly describe the difference between labels and annotations on a Prometheus alerting rule? (Choose TWO)

    • ALabels become part of the alert's identity and are used by Alertmanager for grouping, routing, and inhibitionCorrect
    • BAnnotations carry human-readable, descriptive information such as summaries and runbook links and do not affect routingCorrect
    • CAnnotations are what Alertmanager uses in order to deduplicate and then group all of the alerts
    • DLabels on an alerting rule can only come from the query result, so the rule itself cannot attach any additional ones
    ✓ Correct answer: A, B

    Alertmanager uses the alert's label set as its fingerprint for grouping, matching routes, silences, and inhibition. Annotations are templated, human-readable fields (summary, description, runbook_url) meant for notifications and have no effect on routing decisions.

    Why the other options are wrong

    • CDeduplication and grouping use labels, not annotations.
    • DThe `labels` clause on an alerting rule exists precisely to attach additional labels beyond those the query returns, and those added labels become part of the alert's identity for routing.

Who this Prometheus Certified Associate (PCA) practice exam is for

This practice set is for anyone preparing for the Prometheus Certified Associate (PCA) exam at the intermediate level - from first-time candidates building a foundation to experienced Cloud Native practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this Prometheus Certified Associate (PCA) practice exam

1. Start with the free sample questions above to gauge your current baseline.
2. Read the full explanation on every question, including why each wrong option is wrong.
3. Track your weak domains and focus your study where you are losing the most marks.
4. Once you are scoring consistently well, take a timed, full-length mock exam.
5. Use your readiness score to decide when you are ready to book the real Prometheus Certified Associate (PCA) exam.

Related Cloud Native resources

• Prometheus Certified Associate (PCA) study guideKey concepts
• Cloud Native practice examsAll Cloud Native
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• How these questions are written and reviewedMethodology
• Report a problem with a questionCorrections
• CBA practice examRelated
• Certified Argo Project Associate (CAPA) practice examRelated
• Certified GitOps Associate (CGOA) practice examRelated

Prometheus Certified Associate (PCA) practice exam FAQ