Google ACE Practice Question: Ensuring Successful Operation of a Cloud Solution

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Check the subscription's backlog in the Pub/Sub console or via gcloud pubsub subscriptions describe

  Why this is correct

  Checking the subscription's backlog, either in the Pub/Sub console or via the `gcloud pubsub subscriptions describe` command, gives a direct numeric measurement of how many messages are unacknowledged and waiting to be redelivered. A consistently growing backlog relative to the publish rate indicates the subscriber cannot keep up with the incoming flow. This is the first diagnostic step because it confirms whether the bottleneck is on the delivery side or the processing side without instrumenting any application code.

• ✓

  Use Cloud Monitoring Metrics Explorer to view the subscription's backlog and ack messages count

  Why this is correct

  Cloud Monitoring Metrics Explorer can visualize Pub/Sub subscription metrics such as `pubsub.googleapis.com/subscription/backlog` and `pubsub.googleapis.com/subscription/ack_message_count`. By comparing the ack_message_count with the published_message_count over time, you can determine if the subscriber is acknowledging messages at a lower rate than they are being published. This also reveals patterns such as spikes or stalls, helping you correlate the slowness with specific time windows or deployment changes.

• ✗

  Use Cloud Trace to analyze the latency of each Pub/Sub message

  Why it's wrong here

  Cloud Trace is designed for end-to-end distributed tracing of HTTP-based request latencies, not for Pub/Sub message flow. Pub/Sub does not automatically propagate trace contexts through its API, and Cloud Trace cannot capture the latency of an individual message from publish to acknowledgment unless your subscriber code explicitly wraps the processing with a custom trace span. Even then, it would only give per-request timing, not throughput or backlog health, so it is the wrong tool for this systemic slowness diagnosis.

• ✗

  Use Cloud Debugger to inspect the subscriber code

  Why it's wrong here

  Cloud Debugger lets you inspect live application state and set snapshots or logpoints without stopping the service, which is useful for debugging logic errors or variable values. However, it does not provide any metrics about Pub/Sub subscription throughput, backlog, or acknowledgement rates. The slowness you are investigating is unlikely to be caused by a single line of code; Debugger is not intended for performance analysis and cannot show queue depths or end-to-end message delivery latency.

• ✓

  Use Cloud Logging to check for subscriber errors or delivery failures

  Why this is correct

  Cloud Logging is useful here because a subscriber that is throwing exceptions, timing out, or hitting dead-letter conditions will often emit error logs that explain why messages are not being acknowledged. If you have structured logs from the subscriber, you can search for messages matching the subscription ID or processing failures to identify systematic issues such as an unavailable downstream dependency. This complements the numeric backlog and ack metrics by providing the actual error messages and stack traces from the consuming application.

Go deeper

Related to this question