Your enterprise runs a distributed microservices platform on Google Kubernetes Engine (GKE) configured with Cloud Service Mesh using a managed control plane. You are tasked with instrumenting telemetry to capture distributed traces and proxy access logs across all communicating services, exporting them directly to Google Cloud Observability. During implementation, your team needs to ensure all mesh workloads send telemetry without conflicting configurations across application namespaces. What should you do?

Deploy a single `Telemetry` custom resource referencing the `stackdriver` provider in the root `istio-system` namespace.: ### What Cloud Service Mesh Telemetry configuration is The **Istio Telemetry API** (`telemetry.istio.io/v1alpha1`) allows administrators to configure distributed tracing, access logging, and metrics collection for Envoy proxies across the service mesh. ### How it meets the requirements - **Managed Control Plane Compliance**: Cloud Service Mesh with a managed control plane enforces a single, cluster-wide telemetry configuration located strictly in the root namespace (`istio-system`). - **Unified Observability Export**: Configuring the `stackdriver` provider within the root `Telemetry` custom resource instructs all Envoy sidecar proxies to export distributed tracing and access telemetry directly to Google Cloud Observability (Cloud Trace and Cloud Logging). - **Prevents Configuration Conflicts**: Using a centralized resource in `istio-system` prevents conflicts caused by multiple custom resources, ensuring consistent telemetry behavior across all workloads. ### Key advantages and capabilities - **Cluster-wide Consistency**: Automatically applies uniform distributed tracing context propagation and proxy logging across all current and future workloads. - **Google Cloud Native Integration**: Direct integration with Google Cloud Observability APIs without requiring third-party telemetry collection daemons. - **Minimal Operational Overhead**: Centralizes telemetry maintenance into a single declarative manifest. ### Why this is optimal Deploying a single `Telemetry` resource in `istio-system` aligns with Google Cloud architecture best practices for managed control planes, avoiding ignored configurations while ensuring seamless distributed trace collection across microservices.