Courseiva
Cloud Native ObservabilityhardMultiple ChoiceObjective-mapped

KCNA Cloud Native Observability Practice Question

A company runs a Kubernetes cluster with 50 worker nodes, each hosting multiple microservices. They use Prometheus for metrics collection and Grafana for dashboards. Recently, the Prometheus server has been experiencing out-of-memory (OOM) kills during peak hours, causing gaps in metric collection. The cluster has a dedicated monitoring namespace. The team has already increased the Prometheus pod's memory limits to 8GB, but OOMs still occur. The metrics retention is set to 15 days. The cardinality of certain metrics (e.g., HTTP request labels with user IDs) is very high. The team needs to resolve the OOM issue without losing critical alerting capability for at least the last 7 days of data. Which action should they take first?

⚠ Common exam trap

Test-takers frequently confuse memory pressure (caused by cardinality) with storage pressure (caused by retention), leading candidates to incorrectly choose reducing retention (Option C) instead of addressing the root cause of high cardinality via recording rules.

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

Implement recording rules to pre-aggregate high-cardinality metrics at a lower granularity

Recording rules allow Prometheus to pre-aggregate high-cardinality metrics (e.g., HTTP request labels with user IDs) at a lower granularity, reducing the number of unique time series stored in memory. This directly addresses the OOM issue caused by cardinality explosion without discarding raw data entirely, preserving the ability to query aggregated metrics for alerting over the required 7-day window.

Answer analysis

Option-by-option breakdown

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

  • Implement recording rules to pre-aggregate high-cardinality metrics at a lower granularity

    Why this is correct

    Recording rules reduce cardinality by aggregating metrics, lowering memory usage while preserving aggregated data for alerting.

  • Drop high-cardinality metrics like HTTP request labels using relabel_configs

    Why it's wrong here

    This may remove useful metrics; better to aggregate them.

  • Reduce metrics retention to 7 days to free memory

    Why it's wrong here

    Reduces memory but also loses older data; less targeted than recording rules.

  • Enable vertical pod autoscaler for the Prometheus pod

    Why it's wrong here

    VPA adjusts resources but does not reduce cardinality; OOM may still occur if node is saturated.

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

About these practice questions

One of 833 original KCNA 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 KCNA 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 KCNA exam.