Troubleshooting practice questions

A DevOps team is troubleshooting high latency in a Cloud Bigtable instance. They notice that the row keys are lexicographically sorted timestamps. Which TWO actions will MOST improve performance? (Select 2 answers)

Trap 1: Add more Bigtable nodes

Helps throughput but does not fix hotspotting from row key design.

Trap 2: Increase the number of column families

Does not address row key hotspotting.

Trap 3: Enable compression on column families

Reduces storage, not latency from hotspotting.

A
Add more Bigtable nodes
Why wrong: Helps throughput but does not fix hotspotting from row key design.
B
Increase the number of column families
Why wrong: Does not address row key hotspotting.
C
Enable compression on column families
Why wrong: Reduces storage, not latency from hotspotting.
D
Use salt (hash prefix) in the row key
Randomizes row key distribution, reducing hotspots.
E
Redesign the row key to include a field promotion (e.g., user ID) before the timestamp
Distributes writes across tablets.

Read the full network assurance explanation →

Question 2mediummultiple choice

A company has a legacy monolithic application running on Compute Engine that is being migrated to microservices on GKE. During the migration, they need to maintain performance monitoring across both environments. The legacy application uses Stackdriver Logging and Monitoring agents (now Ops Agent) and exports logs to Cloud Logging. The new microservices are instrumented with OpenTelemetry for traces and metrics. The team wants a unified view of performance across both environments, including distributed traces from the new services and log-based metrics from the legacy app. They also want to correlate logs and traces for troubleshooting. Which solution should they implement?

Trap 1: Keep monitoring separate and use separate dashboards for legacy and…

Separate dashboards do not provide a unified view and hinder correlation.

Trap 2: Use a third-party APM tool that supports both environments.

While possible, it's not leveraging native Google Cloud tools and may add complexity.

Trap 3: Rewrite the legacy app to use OpenTelemetry.

Rewriting is costly and time-consuming, not necessary.

A
Keep monitoring separate and use separate dashboards for legacy and new.
Why wrong: Separate dashboards do not provide a unified view and hinder correlation.
B
Use a third-party APM tool that supports both environments.
Why wrong: While possible, it's not leveraging native Google Cloud tools and may add complexity.
C
Use Cloud Monitoring dashboards and ingest OpenTelemetry metrics into Cloud Monitoring, while using Cloud Logging log-based metrics from legacy app.
This approach unifies metrics and logs from both environments, enabling correlation.
D
Rewrite the legacy app to use OpenTelemetry.
Why wrong: Rewriting is costly and time-consuming, not necessary.

Question 3mediumdrag order

Drag and drop the steps to troubleshoot a failed Cloud Build in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Re-run the build first, then check logs, then examine…

This is incorrect because re-running without investigation is unlikely to resolve the issue and wastes time; logs should be checked first to understand the failure.

Trap 2: Examine build configuration first, then re-run the build, then…

This is incorrect because examining configuration without logs may miss runtime errors; logs provide the specific error pointing to what went wrong.

Trap 3: Fix issues first, then check logs, then examine configuration, then…

This is incorrect because fixing issues without understanding the failure (logs/configuration) is guesswork; you must diagnose before attempting a fix.

A
Check Cloud Build logs first, then examine build configuration, then fix identified issues, then re-run the build.
This is the correct order because logs provide the immediate error details, then configuration review helps identify misconfigurations, fixing addresses the root cause, and re-running validates the solution.
B
Re-run the build first, then check logs, then examine configuration, then fix issues.
Why wrong: This is incorrect because re-running without investigation is unlikely to resolve the issue and wastes time; logs should be checked first to understand the failure.
C
Examine build configuration first, then re-run the build, then check logs, then fix issues.
Why wrong: This is incorrect because examining configuration without logs may miss runtime errors; logs provide the specific error pointing to what went wrong.
D
Fix issues first, then check logs, then examine configuration, then re-run.
Why wrong: This is incorrect because fixing issues without understanding the failure (logs/configuration) is guesswork; you must diagnose before attempting a fix.

Question 4mediummulti select

You are troubleshooting a performance issue in a microservices application. Which TWO tools from Google Cloud's operations suite would you use to trace a request across services and identify the slowest component?

Trap 1: Error Reporting

Error Reporting aggregates errors but does not trace performance latency across services.

Trap 2: Cloud Profiler

Cloud Profiler profiles code-level CPU and memory usage, not request traces across services.

Trap 3: Cloud Logging

Cloud Logging provides individual log entries but does not directly trace a request's full path across services.

A
Cloud Monitoring
Cloud Monitoring can display latency heatmaps and service graphs that help visualize the slowest component in a distributed trace.
B
Error Reporting
Why wrong: Error Reporting aggregates errors but does not trace performance latency across services.
C
Cloud Profiler
Why wrong: Cloud Profiler profiles code-level CPU and memory usage, not request traces across services.
D
Cloud Logging
Why wrong: Cloud Logging provides individual log entries but does not directly trace a request's full path across services.
E
Cloud Trace
Cloud Trace is the primary tool for distributed tracing, capturing end-to-end latency for each request and showing spans for each service call.

Question 5hardmulti select

Which THREE of the following are valid reasons to use Cloud Deploy instead of manually applying kubectl commands in a CI/CD pipeline?

Trap 1: Cloud Deploy automatically containerizes applications.

Cloud Deploy expects already containerized apps.

Trap 2: Cloud Deploy enforces IAM roles on Kubernetes clusters.

IAM can be used with kubectl as well.

A
Cloud Deploy automatically containerizes applications.
Why wrong: Cloud Deploy expects already containerized apps.
B
Cloud Deploy maintains a deployment history for auditing.
Audit trail is built-in.
C
Cloud Deploy enforces IAM roles on Kubernetes clusters.
Why wrong: IAM can be used with kubectl as well.
D
Cloud Deploy provides automatic rollbacks on deployment failure.
Automated rollback is a key feature.
E
Cloud Deploy supports canary and blue-green deployments out of the box.
Advanced deployment strategies are supported.