CNPEObservability and OperationsSingle nodeMedium

Tracing: add an OTLP traces pipeline to the OpenTelemetry Collector

Scenario cnpe-obs-002 · about 18 minutes · 9 points · 7 grader checks

The platform OpenTelemetry Collector only handles metrics. Give it an OTLP traces pipeline with the right processors, expose it, and prove it with generated spans.

opentelemetry
otel-collector
tracing
otlp
telemetrygen
observability

What you will practise

Configure receivers, processors, exporters and a traces pipeline in the Collector
Expose OTLP gRPC through a Service
Measure the pipeline through the Collector's own metrics

Start this lab

With the CLI installed and signed in, this command provisions a single node cluster on your Mac, applies the scenario setup and prints the task below.

goldenkube start cnpe-obs-002

Task

The task text exactly as the CLI shows it. Solve it on the cluster, then run goldenkube submit.

In namespace "observability" the Deployment "otel-collector" (image docker.io/otel/opentelemetry-collector-k8s:0.164.0) reads its configuration from the key "config.yaml" of the ConfigMap "otel-collector". It currently receives OTLP over HTTP only and runs only a metrics pipeline. Its own metrics are served on port 8888, exposed as port "metrics" of the Service "otel-collector". 1. Change the configuration so the Collector also receives OTLP traces over gRPC on port 4317 and runs a "traces" pipeline: otlp receiver, processors memory_limiter then batch, exporter debug. Keep the metrics pipeline and the internal metrics on port 8888 working. 2. Expose port 4317 as port "otlp-grpc" of the Service "otel-collector". 3. Run a Job "trace-gen" in "observability" with the image ghcr.io/open-telemetry/opentelemetry-collector-contrib/telemetrygen:v0.164.0 that sends 25 traces to the Collector over insecure OTLP gRPC. The Job must complete and the Collector must have accepted and exported the spans.

Requirements and details

Certification: CNPE · Certified Cloud Native Platform Engineer
Domain: Observability and Operations
Difficulty: Medium
Cluster topology: Single node
Cluster features: None beyond the base cluster
Recommended time: 18 minutes
Points: 9
Grader checks: 7
Kubernetes version: 1.35
Minimum CLI version: 0.1.0
Scenario version: 1
Published: 30 Oct 2026

Grading runs locally: 7 state checks read your cluster when you submit; the scenario passes when every check passes. Hints, the reference solution and the check definitions are available only inside the CLI, not on this page.

Install the CLI Create a free account

CNPEObservability and OperationsMedium

Monitoring and alerting: ServiceMonitor, alert and recording rule

Get the shop API into the platform Prometheus: scrape it with a ServiceMonitor, alert on its 5xx ratio and precompute its request rate with a recording rule.

Single node · ~18 min · 10 points

prometheus
servicemonitor
prometheusrule
alerting
recording-rules
observability

goldenkube start cnpe-obs-001

CNPEObservability and OperationsHard

Logging: collect one namespace's pod logs with an OpenTelemetry DaemonSet

Ship only the shop namespace's container logs: run the OpenTelemetry Collector as a DaemonSet with the filelog receiver on the node's pod log files and print the records with the debug exporter.

Single node · ~18 min · 9 points

opentelemetry
logging
filelog
daemonset
hostpath
observability

goldenkube start cnpe-obs-003

CNPEObservability and OperationsMedium

Incident response: roll back a bad release and fix an OOM-killed workload

Two workloads in namespace checkout are degraded: diagnose a failed rollout and an OOM-killed container from events and status, remediate both in place and record the findings in an incident ConfigMap.

Single node · ~14 min · 10 points

incident-response
rollout
rollback
oomkilled
troubleshooting
observability

goldenkube start cnpe-obs-004

Independent community project, not affiliated with or endorsed by CNCF or The Linux Foundation. Lab results are practice feedback, not an exam score.