KCNA Cloud Native Observability — 10 Questions

Question 1

Which TWO are components of a distributed trace? (Select two.)

Accepted Answer

Spans. A distributed trace is composed of spans, which represent individual units of work within the trace. The trace itself is the overarching collection of spans, not a component. Metrics, logs, and alerts are separate observability signals and not components of a trace.

Answer

Metrics

Answer

Traces

Answer

Logs

Answer

Alerts

Question 2

Which TWO of the following are valid Prometheus metric types? (Select two.)

Accepted Answer

Counter. Counter and Histogram are two of the four valid Prometheus metric types. Counter is a cumulative metric that only increases, while Histogram samples observations and counts them in configurable buckets. The other options are not valid Prometheus metric types: Log, Event, and Trace are not metric types in Prometheus (they relate to logging, events, and tracing). Gauge and Summary are also valid metric types, but they are not listed as correct options here because only Counter and Histogram are marked correct in this question.

Answer

Log

Answer

Event

Answer

Trace

Question 3

A DevOps team notices that a microservice is returning 503 errors intermittently. The service runs in Kubernetes and uses a liveness probe. The team wants to understand the root cause without restarting the pod. Which observability approach should they use first?

Accepted Answer

Query Prometheus for kubelet metrics on probe successes and failures. Prometheus can scrape kubelet metrics that expose liveness probe success and failure counts directly, allowing the team to see if the probe is failing without restarting the pod. This approach provides historical data on probe behavior, which is essential for diagnosing intermittent 503 errors that stem from the kubelet restarting the container when the liveness probe fails. Unlike other options, it does not require modifying the application or restarting the pod, and it directly surfaces the root cause if the probe is the issue.

Answer

Use kubectl describe pod to check recent events

Answer

Increase log verbosity in the application to capture all requests

Answer

Enable distributed tracing across the service mesh

Question 4

A platform team is designing a monitoring strategy for a multi-tenant Kubernetes cluster. Each tenant runs workloads in separate namespaces. The team needs to ensure tenant isolation while providing aggregated cluster-wide dashboards. Which approach best meets these requirements?

Accepted Answer

Deploy a Prometheus instance per tenant and use Thanos to aggregate metrics globally. Deploying a Prometheus instance per tenant enforces strong tenant isolation by preventing cross-tenant metric access or resource contention, while Thanos provides a global view by aggregating metrics from all tenants via sidecar-based or query-frontend federation. This approach satisfies both isolation and aggregated dashboards without compromising security or scalability.

Answer

Deploy a single Prometheus instance with namespace labels on all metrics

Answer

Use a global Prometheus with recording rules to aggregate per-namespace metrics

Answer

Have each tenant deploy their own monitoring stack and view separately

Question 5

A Kubernetes administrator is troubleshooting a pod that is stuck in CrashLoopBackOff. The pod's restart count is increasing. Which initial step should the administrator take to diagnose the issue?

Accepted Answer

Run 'kubectl logs ' to view the application logs. When a pod is in CrashLoopBackOff, the immediate priority is to inspect the application logs to understand why the container is failing. `kubectl logs ` retrieves the stdout/stderr output from the container, which typically contains error messages, stack traces, or configuration issues that caused the crash. This is the most direct and efficient first step before deeper investigation.

Answer

Run 'kubectl describe pod <pod-name>' to check events

Answer

Check the Prometheus metrics for the pod's CPU usage

Answer

Run 'kubectl exec -it <pod-name> -- /bin/sh' to inspect the container

Question 6

An organization uses Prometheus and Grafana for monitoring. They want to alert when the 99th percentile of request latency exceeds 500ms for more than 5 minutes. Which PromQL query should they use in the alert rule?

Accepted Answer

histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.5. It uses `histogram_quantile(0.99, rate(...[5m]))` to calculate the 99th percentile request latency over a 5-minute window, matching the requirement to alert when this value exceeds 500ms (0.5 seconds) for more than 5 minutes. The `rate()` function with a 5m range computes the per-second increase of bucket counters over that duration, which is necessary for accurate quantile estimation in Prometheus.

Answer

histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[1m])) > 0.5

Answer

avg(rate(http_request_duration_seconds_bucket[5m])) > 0.5

Answer

max(rate(http_request_duration_seconds_bucket[5m])) > 0.5

Question 7

Which TWO of the following are best practices for structuring log output in cloud-native applications to maximize observability?

Accepted Answer

Output logs in structured format such as JSON. Structured logging (e.g., JSON) enables automated parsing, filtering, and querying by log aggregation tools like Fluentd, Logstash, or cloud-native observability backends (e.g., Elasticsearch, Loki). This format ensures each log entry has consistent key-value pairs, making it machine-readable and facilitating correlation across distributed services without manual text parsing.

Answer

Include verbose debug-level information in every log line

Answer

Use multi-line log entries for detailed error information

Answer

Avoid timestamps to reduce log size

Question 8

Which THREE of the following are valid use cases for distributed tracing in a microservices architecture?

Accepted Answer

Understanding the dependency graph between microservices. Distributed tracing is designed to track the flow of a single request across multiple microservices, recording timing and causality. Option B is correct because tracing systems like Jaeger or Zipkin automatically build a dependency graph by analyzing the parent-child relationships between spans, which reveals how services interact. This is a core use case for understanding service topology and identifying bottlenecks in a distributed system.

Answer

Monitoring CPU and memory usage of each service instance

Answer

Capturing detailed error messages and stack traces

Question 9

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?

Accepted Answer

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

Drop high-cardinality metrics like HTTP request labels using relabel_configs

Answer

Reduce metrics retention to 7 days to free memory

Answer

Enable vertical pod autoscaler for the Prometheus pod

Question 10

A company deploys a microservice application on Kubernetes. They notice that one of the services is returning 5xx errors intermittently. Which observability tool should they use to correlate the errors with resource usage across all pods of that service?

Accepted Answer

Prometheus. Prometheus is the correct choice because it is a monitoring and alerting toolkit designed to collect and store time-series metrics, such as CPU, memory, and request error rates. By querying Prometheus with PromQL, you can correlate 5xx error spikes with resource usage across all pods of a service, as it scrapes metrics from each pod's /metrics endpoint. This direct correlation of application-level errors with infrastructure metrics is not natively provided by the other tools listed.

Answer

Grafana

Answer

Fluentd

Answer

Jaeger