Google ACE Practice Question: Your application is deployed on GKE and…

Your application is deployed on GKE and experiencing increased latency. You suspect a memory leak causing the JVM to run frequent garbage collection cycles. Cloud Monitoring shows high memory usage but you need to understand the garbage collection behavior over time. Which GCP tool provides JVM-level profiling including memory allocation data?

⚠ Common exam trap

Google Cloud often tests the distinction between metric-based monitoring (Cloud Monitoring with MBeans) and profiling (Cloud Profiler), where candidates mistakenly choose Cloud Monitoring because it shows memory usage, but it lacks the allocation-level detail needed to diagnose garbage collection behavior.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Cloud Profiler with heap profiling enabled for the JVM application.

Cloud Profiler with heap profiling enabled captures JVM-level memory allocation data and garbage collection behavior over time, allowing you to identify memory leaks and GC frequency. Unlike generic memory monitoring, it provides per-method allocation snapshots and GC pause analysis specific to the JVM.

Answer analysis

Option-by-option breakdown

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

✗
Cloud Trace
Why it's wrong here
Cloud Trace is a distributed tracing system that measures request latency spans across services and doesn't expose any JVM internals like heap utilization, GC behavior, or object allocations. It samples HTTP requests and microservice calls, so it might show endpoints that are slow, but memory leaks can occur in background threads or async paths that aren't tied to a request. It has no visibility into the JVM's heap, making it irrelevant for leak diagnosis.
✓
Cloud Profiler with heap profiling enabled for the JVM application.
Why this is correct
Cloud Profiler with heap profiling samples every JVM object allocation and attributes each one to the exact call stack at the allocation site, turning 'memory is growing' into 'this method allocates this type.' The profiler's overhead is minimal — around 1% CPU — so it can be left on in production until the leak manifests. Comparing two profile snapshots shows which allocation site is still increasing, pinpointing the leak's source directly.
✗
Cloud Monitoring with JVM MBeans metrics exported via the Ops Agent.
Why it's wrong here
The Ops Agent can export JVM MBeans so Cloud Monitoring shows aggregate heap usage, committed memory, and garbage-collection counts and durations. Those high-level metrics reveal that the heap is filling up and how often GC runs, but they don't reveal which classes or methods are responsible for the allocations. A rising heap trend only confirms the symptom; Cloud Profiler's call-stack-level allocation profiles provide the evidence needed to locate the leaking code.
✗
Error Reporting filtered for OutOfMemoryError exceptions.
Why it's wrong here
Error Reporting filters and aggregates exception events, but an OutOfMemoryError often kills the JVM before the error can be reported, or the error is only where the JVM ran out — not why. Catching it in code gives no pre-crash allocation context, so you can't see which call stacks allocated the objects that filled the heap. It tells you the crash happened, not where the memory went.

Go deeper

Google ACE Practice Question: Your application is deployed on GKE and…

Why each option matters

Option-by-option breakdown

Related to this question