GKE Memory Leak: Three Actions to Investigate and Mitigate
An incident is declared for a production service running on GKE. The on-call engineer suspects a recent code change may have introduced a memory leak. Which THREE actions should the engineer take to investigate and mitigate?
Quick Answer
The answer is to compare memory usage metrics before and after the deployment using Cloud Monitoring, enable detailed memory profiling with tools like Cloud Profiler, and temporarily increase the container’s memory limit in the pod spec to prevent OOM kills. Comparing metrics before and after the deployment isolates the regression, while Cloud Profiler pinpoints the specific code path consuming excess memory. Raising `resources.limits.memory` provides immediate headroom, buying time for root-cause analysis without crashing the service. On the Google Professional Cloud DevOps Engineer exam, this scenario tests your ability to balance rapid mitigation with systematic investigation—a common trap is jumping to a permanent code fix before confirming the regression window. Remember the three-phase approach: **Compare, Profile, Raise**—first verify the change caused the leak, then profile the heap, then raise the limit as a temporary shield.
⚠ Common exam trap
Google Cloud often tests the misconception that scaling down replicas reduces memory pressure, when in fact it reduces total available memory and can worsen the impact of a memory leak.
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
✓
Increase the memory limit for the container as a temporary mitigation
Increasing the memory limit for the container provides a temporary mitigation to prevent the service from being killed by the Out of Memory (OOM) killer while the root cause is investigated. In GKE, the container's memory limit is defined in the pod spec under `resources.limits.memory`, and raising it gives the application more headroom to continue serving requests without immediate termination. This is a standard incident response practice to buy time for deeper analysis, such as reviewing logs and metrics, before applying a permanent fix.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Increase the memory limit for the container as a temporary mitigation
Why this is correct
Temporary increase buys time for a permanent fix.
- ✗
Scale down the number of replicas to reduce memory pressure
Why it's wrong here
Scaling down reduces total memory but each container still leaks, causing crashes.
- ✗
Roll back the deployment immediately without further investigation
Why it's wrong here
Rollback is mitigation, but the question asks for investigation and mitigation steps.
- ✓
Check container logs for Out of Memory (OOM) killed messages
Why this is correct
OOM messages confirm memory exhaustion.
- ✓
Compare memory usage metrics before and after the deployment using Cloud Monitoring
Why this is correct
Identifies if memory usage increased after the change.
Go deeper
Related to this question
About these practice questions
This PCDOE question is part of Courseiva's 486-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on PCDOE
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A team uses Google Kubernetes Engine (GKE) with cluster telemetry enabled. During an incident, they notice that a deployment's pods are repeatedly crashing with Exit Code 137. The team wants to investigate the root cause. Which two Google Cloud services should they use together to correlate resource usage and logs?
medium- ✓ A.Cloud Monitoring and Cloud Logging
- B.Security Command Center and Cloud Logging
- C.Cloud Trace and Cloud Monitoring
- D.Cloud Error Reporting and Cloud Logging
Why A: Exit Code 137 indicates a container was killed by SIGKILL, typically due to an out-of-memory (OOM) condition. To correlate resource usage and logs, Cloud Monitoring provides resource usage metrics (e.g., memory, CPU), while Cloud Logging captures container termination logs and system events. Together, they allow correlation of spikes in resource usage with log entries to identify OOM kills. Cloud Trace is not primarily a logging service; it provides distributed tracing for latency analysis, but does not directly correlate logs with resource usage. Therefore, only Cloud Monitoring and Cloud Logging together (option A) satisfy the requirement.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCDOE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCDOE exam.