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
Your organization runs a microservices architecture distributed across Cloud Run and Compute Engine instances. During incident investigations, engineers struggle to correlate application logs with distributed traces in Google Cloud Observability.
You need to implement end-to-end trace context propagation between services and ensure application log entries are automatically correlated with Cloud Trace in Cloud Logging.
Which configuration should you implement?
Propagate trace context across HTTP calls using standard trace context headers (such as W3C traceparent or X-Cloud-Trace-Context), and emit structured JSON logs containing the logging.googleapis.com/trace field formatted as projects/[PROJECT_ID]/traces/[TRACE_ID] and the logging.googleapis.com/spanId field.
Add an X-Goog-Request-Reason HTTP header containing the trace ID to all internal service requests, and format logs by writing the trace identifier exclusively inside jsonPayload.message.
Configure VPC Flow Logs on all subnets, route logs to Cloud Storage, and use Google Security Operations UDM mapping tables to join connection IP tuples with application execution logs.
Embed trace identifiers into the HTTP User-Agent string of internal requests and rely on unstructured plaintext logs ingested via the Cloud Logging agent without metadata enrichment.
Propagate trace context across HTTP calls using standard trace context headers (such as W3C traceparent or X-Cloud-Trace-Context), and emit structured JSON logs containing the logging.googleapis.com/trace field formatted as projects/[PROJECT_ID]/traces/[TRACE_ID] and the logging.googleapis.com/spanId field.
Trace context propagation passes unique identifiers (Trace ID, Span ID, and trace flags) across network and process boundaries in distributed systems. Google Cloud Observability automatically links structured application logs to trace spans when log entries include designated special JSON fields recognized by the Cloud Logging ingestion pipeline.
StudyCerts
StudyCertstraceparent or Google's X-Cloud-Trace-Context header) and injecting it into outgoing client requests ensures that downstream services running on Cloud Run or Compute Engine participate in the same global trace.stdout/stderr or via the logging agent with logging.googleapis.com/trace set to projects/[PROJECT_ID]/traces/[TRACE_ID] and logging.googleapis.com/spanId set to the hex span ID, Cloud Logging automatically associates each log entry directly with the corresponding Cloud Trace span.This approach directly aligns with Google Cloud Observability architecture by leveraging native trace field extraction and standard W3C/HTTP propagation mechanisms without introducing latency or infrastructure dependencies.
Add an X-Goog-Request-Reason HTTP header containing the trace ID to all internal service requests, and format logs by writing the trace identifier exclusively inside jsonPayload.message.
Configure VPC Flow Logs on all subnets, route logs to Cloud Storage, and use Google Security Operations UDM mapping tables to join connection IP tuples with application execution logs.
Embed trace identifiers into the HTTP User-Agent string of internal requests and rely on unstructured plaintext logs ingested via the Cloud Logging agent without metadata enrichment.