Courseiva
Application Observability and MaintenancemediumMultiple ChoiceObjective-mapped

CKAD Application Observability and Maintenance Practice Question

You need to collect metrics from an application running in a pod. The application exposes metrics on port 8080 at /metrics in Prometheus format. Which resource should you configure to allow Prometheus to scrape these metrics?

⚠ Common exam trap

A common mix-up: candidates confuse Prometheus's pull-based scraping with push-based or external access patterns, leading them to choose Ingress (external exposure) or PrometheusRule (alerting) instead of the service annotation that enables automatic internal discovery.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Create a Service with annotation 'prometheus.io/scrape: "true"' and 'prometheus.io/port: "8080"'.

Prometheus uses a pull-based model to scrape metrics from targets. By adding the `prometheus.io/scrape: "true"` and `prometheus.io/port: "8080"` annotations to a Service that selects the pod, you enable Prometheus's built-in service discovery to automatically detect and scrape the `/metrics` endpoint on port 8080 without manual configuration.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Create an Ingress resource that exposes the /metrics endpoint externally.

    Why it's wrong here

    Creating an Ingress resource would expose the /metrics endpoint to the outside world via HTTP routing rules, but Prometheus scrapes inside the cluster by reaching pod IPs directly through service discovery. Ingress is an API object for external L7 load balancing, not for registering internal scrape targets, and it doesn't contribute to Prometheus's dynamic service discovery, which uses Kubernetes Services or Pods as sources.

  • Create a ConfigMap with the Prometheus scrape configuration and mount it into the Prometheus pod.

    Why it's wrong here

    Mounting a ConfigMap into the Prometheus pod only provides static configuration files; it does not register the target pod’s /metrics endpoint for dynamic service discovery. This option is tempting because ConfigMaps are the standard way to supply Prometheus with its own configuration, such as scrape intervals or static targets. However, in this scenario, the application pod must be discovered and scraped automatically, which requires a ServiceMonitor or PodMonitor custom resource definition that Prometheus Operator uses to generate the actual scrape configuration.

  • Create a Service with annotation 'prometheus.io/scrape: "true"' and 'prometheus.io/port: "8080"'.

    Why this is correct

    This is the standard approach for Prometheus operator's annotation-based discovery: the service's annotations `prometheus.io/scrape: "true"` and `prometheus.io/port: "8080"` allow the auto-discovery component to generate a scrape_config targeting the service's endpoints on port 8080. The Service provides a stable DNS name and selects the pods, so even if pod IPs change, Prometheus can dynamically look up the current endpoints. This is distinct from the static ConfigMap method because it enables automatic, label-based target discovery across the cluster.

  • Add a PrometheusRule resource that defines the scrape target.

    Why it's wrong here

    A PrometheusRule custom resource defines alerting or recording rules that evaluate PromQL expressions on scraped metrics; it does not configure where to collect metrics from. Scrape targets are instead defined by ServiceMonitor or PodMonitor objects that specify selector labels, ports, and intervals, which the Prometheus Operator processes to build the actual scrape_config file. Thus, adding a PrometheusRule would only affect alerting behavior, not register the application's /metrics endpoint as a scrape target.

About these practice questions

One of 160 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This CKAD practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKAD exam.