Troubleshooting practice questions

You are troubleshooting a slow Pub/Sub subscription. Which three steps should you take to diagnose the issue? (Choose three.)

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

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.

Trap 2: Use Cloud Debugger to inspect the subscriber code

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.

A
Check the subscription's backlog in the Pub/Sub console or via gcloud pubsub subscriptions describe
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.
B
Use Cloud Monitoring Metrics Explorer to view the subscription's backlog and ack messages count
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.
C
Use Cloud Trace to analyze the latency of each Pub/Sub message
Why it fails: 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.
D
Use Cloud Debugger to inspect the subscriber code
Why it fails: 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.
E
Use Cloud Logging to check for subscriber errors or delivery failures
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.

Question 2hardmulti select

Your application running on Compute Engine is experiencing intermittent high latency. You need to diagnose the root cause. Which THREE tools or services should you use to gather data? (Choose 3)

Trap 1: Cloud Profiler

Cloud Profiler is not suitable because it performs continuous, low-overhead sampling of CPU and heap usage, producing aggregated profiles that show where functions consume resources over the long term. It lacks the temporal granularity needed to catch short-lived, intermittent latency spikes, as it does not tie samples to individual request latency or specific time windows. Profiler is better for optimizing sustained performance rather than troubleshooting transient slowdowns.

Trap 2: Cloud Debugger

Cloud Debugger is not suitable because it captures code snapshots and log points in production, allowing you to inspect variable values and program state at a specific source line without stopping the VM. It does not measure request latency, trace execution paths, or analyze network or I/O bottlenecks, so it cannot reveal why a particular request is slow. Debugger is meant for diagnosing code bugs and logical errors, not performance or latency issues.

A
Cloud Monitoring
Cloud Monitoring is the correct starting point because it provides time-series metrics for Compute Engine, such as CPU utilization, memory usage, disk I/O, and network throughput. You can build custom dashboards and alerts to correlate intermittent latency spikes with resource saturation, helping you determine whether the cause is a bottleneck in the VM, disk, or network. This metric-centric view is essential for seeing the pattern of when slowdowns occur.
B
Cloud Logging
Cloud Logging is correct because it aggregates application stdout/stderr, system logs, and access logs, allowing you to search for error messages, stack traces, or slow-query entries that align with the latency events. Using Logs Explorer with timestamp filters and log-based metrics, you can correlate specific exceptions or warnings with the intermittent behavior. This helps uncover application-level faults, such as database connection pool exhaustion or failed dependencies.
C
Cloud Profiler
Why it fails: Cloud Profiler is not suitable because it performs continuous, low-overhead sampling of CPU and heap usage, producing aggregated profiles that show where functions consume resources over the long term. It lacks the temporal granularity needed to catch short-lived, intermittent latency spikes, as it does not tie samples to individual request latency or specific time windows. Profiler is better for optimizing sustained performance rather than troubleshooting transient slowdowns.
D
Cloud Debugger
Why it fails: Cloud Debugger is not suitable because it captures code snapshots and log points in production, allowing you to inspect variable values and program state at a specific source line without stopping the VM. It does not measure request latency, trace execution paths, or analyze network or I/O bottlenecks, so it cannot reveal why a particular request is slow. Debugger is meant for diagnosing code bugs and logical errors, not performance or latency issues.
E
Cloud Trace
Cloud Trace is correct because it provides distributed tracing that captures latency for individual requests, breaking down the time spent in each service, library, and remote call. By analyzing trace spans and latency distributions, you can pinpoint the exact component—such as a Compute Engine instance, Cloud SQL query, or external API—that contributes the most delay. Trace's ability to sample and compare traces across requests makes it ideal for isolating intermittent bottlenecks.

Question 3hardmulti select

You are troubleshooting a slow application that uses multiple microservices. You suspect a particular service is causing high latency. Which TWO Google Cloud tools should you use to identify the root cause? (Select 2)

Trap 1: Cloud Profiler

Cloud Profiler uses statistical CPU and heap sampling to build flame graphs that reveal functions consuming the most CPU time or memory. In a multi-service application, the bottleneck is often a downstream call waiting on I/O, queues, or a slow peer — not a hotspot in your own code. Profiler does not capture request-level start/end timestamps or per-hop latency, so it cannot show which service is the slow link.

Trap 2: Cloud Logging

Cloud Logging collects and stores log entries with timestamps, but it has no built-in trace propagation or span model unless you integrate Cloud Trace and add structured trace fields. You could correlate entries manually across services; however, that is brittle and lacks the precomputed latency percentiles and aggregated metrics needed to quickly isolate a slow component. For latency troubleshooting, logs are a complementary debugging aid, not the primary signal.

Trap 3: Cloud Debugger

Cloud Debugger attaches to a running application and lets you set snapshot or logpoint breakpoints that capture local variables, call stack, and execution state at a specific line, without restarting or stopping the service. It is designed for inspecting behavior and state at a moment in time, not for measuring latency distributions or aggregating timing across requests. Debugger tells you what the code is doing, not how long it takes.

A
Cloud Profiler
Why it fails: Cloud Profiler uses statistical CPU and heap sampling to build flame graphs that reveal functions consuming the most CPU time or memory. In a multi-service application, the bottleneck is often a downstream call waiting on I/O, queues, or a slow peer — not a hotspot in your own code. Profiler does not capture request-level start/end timestamps or per-hop latency, so it cannot show which service is the slow link.
B
Cloud Logging
Why it fails: Cloud Logging collects and stores log entries with timestamps, but it has no built-in trace propagation or span model unless you integrate Cloud Trace and add structured trace fields. You could correlate entries manually across services; however, that is brittle and lacks the precomputed latency percentiles and aggregated metrics needed to quickly isolate a slow component. For latency troubleshooting, logs are a complementary debugging aid, not the primary signal.
C
Cloud Monitoring
Cloud Monitoring ingests service-level metrics such as request count, latency, and error rate from GKE, Compute Engine, and App Engine, and can display them in dashboards with percentile aggregations. You can create alerting policies and SLOs to detect when one service's latency breaches a threshold. This metric-centric view identifies which service is slow and when, but does not give the end-to-end span journey through each internal call — that is Cloud Trace's role.
D
Cloud Trace
Cloud Trace captures latency data for requests as they traverse services by using trace IDs and spans, and it visualizes a waterfall timeline that shows the critical path. Each span records the time spent in a service or an internal operation (for example, a database query or HTTP call), letting you pinpoint exactly which component adds the most delay. This makes it the most direct tool for diagnosing which part of a multi-service application is slow.
E
Cloud Debugger
Why it fails: Cloud Debugger attaches to a running application and lets you set snapshot or logpoint breakpoints that capture local variables, call stack, and execution state at a specific line, without restarting or stopping the service. It is designed for inspecting behavior and state at a moment in time, not for measuring latency distributions or aggregating timing across requests. Debugger tells you what the code is doing, not how long it takes.

Question 4hardmulti select

An engineer is troubleshooting a Compute Engine instance that is unreachable via SSH. They suspect a firewall rule is blocking traffic. Which TWO actions should they take to diagnose the issue? (Choose 2)

Trap 1: Create a Cloud Monitoring alert for packet loss

Creating a Cloud Monitoring alert for packet loss is reactive and does not identify the root cause. Packet loss metrics may not be visible if the network path is silently dropping traffic due to VPC firewall rules, and an alert only notifies you after the fact. The correct diagnostic step is to inspect firewall rule logs or the rules themselves to see whether traffic is being denied.

Trap 2: Run gcloud compute ssh --dry-run

Running `gcloud compute ssh --dry-run` only prints the SSH command and its arguments without actually attempting a connection. It does not test network connectivity, firewall rules, or IAM permissions, so it cannot reveal why the instance is unreachable. While it can help verify local SSH configuration, it is useless for diagnosing VPC firewall issues.

Trap 3: Use Cloud Trace to analyze network latency

Cloud Trace is designed for analyzing application-level request latency in distributed systems, not for diagnosing network connectivity or firewall rule problems. It requires instrumentation in the application and does not capture packet-level events or VPC firewall decisions. Therefore, using Cloud Trace to analyze network latency would not show whether a firewall rule is blocking traffic to the Compute Engine instance.

A
Create a Cloud Monitoring alert for packet loss
Why it fails: Creating a Cloud Monitoring alert for packet loss is reactive and does not identify the root cause. Packet loss metrics may not be visible if the network path is silently dropping traffic due to VPC firewall rules, and an alert only notifies you after the fact. The correct diagnostic step is to inspect firewall rule logs or the rules themselves to see whether traffic is being denied.
B
View Cloud Logging for firewall rule logs
Viewing Cloud Logging for firewall rule logs is the direct way to see whether VPC firewall rules are dropping or allowing traffic. Firewall rule logging records each connection attempt with details like source IP, destination IP, port, protocol, and the action (allow or deny). If the Compute Engine instance is unreachable due to a firewall rule, these logs will show the denied packets, making this a reliable troubleshooting step.
C
Run gcloud compute ssh --dry-run
Why it fails: Running `gcloud compute ssh --dry-run` only prints the SSH command and its arguments without actually attempting a connection. It does not test network connectivity, firewall rules, or IAM permissions, so it cannot reveal why the instance is unreachable. While it can help verify local SSH configuration, it is useless for diagnosing VPC firewall issues.
D
Use Cloud Trace to analyze network latency
Why it fails: Cloud Trace is designed for analyzing application-level request latency in distributed systems, not for diagnosing network connectivity or firewall rule problems. It requires instrumentation in the application and does not capture packet-level events or VPC firewall decisions. Therefore, using Cloud Trace to analyze network latency would not show whether a firewall rule is blocking traffic to the Compute Engine instance.
E
Check VPC firewall rules in Cloud Console
Checking VPC firewall rules in Cloud Console lets you review ingress and egress rules, their priorities, targets, and allowed/denied protocols. This is essential because firewall rules are evaluated in priority order, with an implied deny rule at the lowest priority, so a misconfigured rule could block SSH or other traffic. By inspecting these rules, you can quickly spot missing or overly restrictive rules that would prevent connectivity to the instance.

Question 5mediummulti select

You are troubleshooting a Pub/Sub subscription that is not delivering messages promptly. Which THREE factors should you investigate? (Choose THREE.)

Trap 1: The topic's retention duration

The topic's retention duration controls how long Pub/Sub retains messages on the topic itself, independent of subscription delivery. Even if the retention window is very short, messages that exist when a subscriber pulls are still delivered at the same rate; retention only affects message durability after the window expires. Thus, changing topic retention cannot speed up or slow down message delivery, and it is not a valid cause when a subscription is stuck.

Trap 2: The message ordering key

The message ordering key ensures that messages sharing the same key are delivered to subscribers in the order they were published, but it does not govern delivery speed. Ordering requires the Pub/Sub service to maintain per-key sequencing, which can reduce parallelism, but an ordering key alone will not prevent a subscription from delivering messages. If delivery is slow, the cause is elsewhere, such as processing time or ack deadlines.

A
The subscription's backlog size
The subscription's backlog size is the primary indicator of delivery problems: it counts messages that have been published but not yet acknowledged. When troubleshooting a subscription that is not delivering, an ever-growing backlog means messages are arriving faster than the subscriber can process them, or the subscriber has stopped pulling entirely. Large backlog also correlates with slow processing and can help you decide whether to scale out subscribers or inspect subscriber logs.
B
The topic's retention duration
Why it fails: The topic's retention duration controls how long Pub/Sub retains messages on the topic itself, independent of subscription delivery. Even if the retention window is very short, messages that exist when a subscriber pulls are still delivered at the same rate; retention only affects message durability after the window expires. Thus, changing topic retention cannot speed up or slow down message delivery, and it is not a valid cause when a subscription is stuck.
C
The subscriber's processing latency
The subscriber's processing latency directly impacts how fast messages are drained from the subscription. If each message takes a long time to handle—due to heavy computation, external API calls, or slow I/O—the effective throughput drops, and the backlog grows even if the subscriber is healthy. High processing latency also increases the chance that the acknowledgment deadline expires, leading to redeliveries that further compound the slowdown.
D
The message ordering key
Why it fails: The message ordering key ensures that messages sharing the same key are delivered to subscribers in the order they were published, but it does not govern delivery speed. Ordering requires the Pub/Sub service to maintain per-key sequencing, which can reduce parallelism, but an ordering key alone will not prevent a subscription from delivering messages. If delivery is slow, the cause is elsewhere, such as processing time or ack deadlines.
E
The acknowledgment deadline
The acknowledgment deadline is the maximum time a subscriber has to ack a message before Pub/Sub redelivers it. A deadline that is too short for the subscriber's actual processing time causes premature redelivery, duplicate processing, and wasted effort, which can stall the subscription and inflate the backlog. Diagnosing this requires comparing the deadline to the observed subscriber latency; if redelivery counts are high, the deadline should be increased or processing time reduced.