Examkin

Question

Difficulty: HardMonitoring, Logging, and Observability Integration

A financial services organization hosts a hybrid banking solution across Google Kubernetes Engine (GKE) and Cloud Run. During operational incidents, engineering teams struggle to correlate distributed trace contexts with application logs and performance metrics across service boundaries. The team needs to establish a unified observability architecture that propagates trace identifiers into Cloud Logging, aggregates metrics into Cloud Monitoring, and prevents high-cardinality metric labels from causing unexpected telemetry costs. Which architecture should the Cloud Architect recommend?

  1. Deploy the OpenTelemetry Collector to collect spans, metrics, and structured logs, configure W3C Trace Context propagation to embed trace IDs into log payloads, and aggregate high-cardinality attributes using OpenTelemetry processors before emitting data to Google Cloud Observability.Answer
  2. B
    Apply a broad log exclusion filter in Cloud Logging that drops all application telemetry and INFO logs across all projects, relying exclusively on basic GCP load balancer metrics to track operational health.
  3. C
    Grant the Project Owner primitive IAM role to the OpenTelemetry Collector service account across all GCP projects to grant unrestricted privileges for metric descriptor creation and trace span ingestion.
  4. D
    Configure the OpenTelemetry Collector to push raw trace spans and metrics directly to an external public IP endpoint, relying exclusively on IAM policies to prevent cross-project data exfiltration.

Answer

Deploy the OpenTelemetry Collector to collect spans, metrics, and structured logs, configure W3C Trace Context propagation to embed trace IDs into log payloads, and aggregate high-cardinality attributes using OpenTelemetry processors before emitting data to Google Cloud Observability.
Deploying the OpenTelemetry Collector with W3C Trace Context propagation enables automatic correlation of trace IDs with Cloud Logging entries across microservices. Utilizing OpenTelemetry batch and filter processors controls metric label cardinality before sending telemetry to Google Cloud Observability, balancing observability depth with cost control.

Step-by-Step Solution

1
Analyze trace and log correlation requirements across distributed microservices.
Identified that W3C Trace Context propagation embeds Trace IDs into structured application log payloads for seamless correlation in Cloud Logging.
Log-trace correlation requires consistent trace context injection across GKE and Cloud Run services.
2
Evaluate metric cardinality management at the telemetry collector layer.
Configured OpenTelemetry Collector processors to aggregate or strip high-cardinality labels prior to pushing metrics into Cloud Monitoring.
Uncontrolled metric cardinality generates excessive custom metric series in Cloud Monitoring, escalating operational costs.
3
Assess security and operational best practices.
Ensured minimal IAM role assignment (Monitoring Metric Writer, Logs Writer) and protected data egress paths.
Avoids primitive role vulnerabilities and ensures secure operational logging integration.

Key Concept

Unified Observability and Telemetry Integration via OpenTelemetry and Cloud Observability
Rate this question

Topics

Monitoring, Logging, and Observability Integration

More questions from this topic