Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
A DevOps engineer is troubleshooting missing telemetry and latency metrics in the Cloud Service Mesh dashboard for a microservice deployed on Google Kubernetes Engine (GKE). The mesh uses a managed control plane with distroless Envoy sidecar proxy containers.
The engineer suspects that the Envoy sidecar failed to receive its telemetry filter configuration from the control plane. However, executing kubectl exec directly into the istio-proxy container to run diagnostic commands fails because the distroless proxy image lacks utilities like curl and bash.
What should the engineer do to inspect the Envoy proxy configuration dump and verify that the telemetry filter is active?
Attach an ephemeral debug container using the istio/base image targeting the istio-proxy container with kubectl debug, and query localhost:15000/config_dump.
Query Cloud Logging for trafficdirector.googleapis.com/events to retrieve the serialized Envoy filter state directly from control plane event logs.
Create additional Istio Telemetry custom resources in the microservice's local namespace to force Envoy to output metric logs to stdout.
Change the Kubernetes Service definition from an HTTP/gRPC protocol port to a generic TCP port to bypass L7 filter evaluation.
Attach an ephemeral debug container using the istio/base image targeting the istio-proxy container with kubectl debug, and query localhost:15000/config_dump.
Cloud Service Mesh sidecars frequently run on distroless container images to reduce attack surfaces and optimize container startup times. Because distroless images omit system utilities such as curl, sh, and bash, operators cannot execute interactive commands directly inside the container using standard kubectl exec workflows. Instead, Kubernetes provides ephemeral debug containers via kubectl debug, which attach a temporary container sharing the target container's process and network namespace.
By executing kubectl debug --image istio/base --target istio-proxy -it -n curl localhost:15000/config_dump, the engineer attaches a container containing essential networking tools (istio/base) directly to the istio-proxy container. This enables querying Envoy's local administration interface on port 15000 to extract the full active configuration dump. The engineer can then inspect the output specifically for the presence and configuration of the Google Cloud Observability filter (stackdriver or Google Cloud metrics filter).
StudyCerts
StudyCertslocalhost:15000.This approach directly solves the diagnostic limitation imposed by distroless containers while providing real-time visibility into Envoy's active filters without modifying deployment manifests or breaking security baselines.
Query Cloud Logging for trafficdirector.googleapis.com/events to retrieve the serialized Envoy filter state directly from control plane event logs.
Create additional Istio Telemetry custom resources in the microservice's local namespace to force Envoy to output metric logs to stdout.
Change the Kubernetes Service definition from an HTTP/gRPC protocol port to a generic TCP port to bypass L7 filter evaluation.