Courseiva
Troubleshooting →hardMultiple Choice

CV0-004 Troubleshooting Practice Question

A cloud engineer is troubleshooting a containerized application deployed on a managed Kubernetes cluster. The application pods are repeatedly restarting with 'OOMKilled' status. The engineer reviews the pod specification and sees that the memory request is 512Mi and the memory limit is 1Gi. The application is a Java-based service with a heap size set to 768Mi. Node metrics show that nodes have 8Gi of memory with 2Gi available. Which of the following is the MOST likely cause of the OOMKilled events?

⚠ Common exam trap

The trap here is focusing on node-level memory availability and overlooking the container's cgroup limit, which is the actual constraint triggering the OOM killer.

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

✓

The Java heap size exceeds the container memory limit when accounting for JVM overhead.

The container memory limit is 1Gi, but the Java heap is 768Mi. The JVM requires additional native memory for metaspace, thread stacks, and other structures. When the total memory usage exceeds the 1Gi limit, the kernel OOM killer terminates the container, resulting in 'OOMKilled'. Although the node has available memory, the container's cgroup limit is the constraint. Increasing the memory limit or reducing the heap size would resolve the issue.

Answer analysis

Option-by-option breakdown

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

  • ✓

    The Java heap size exceeds the container memory limit when accounting for JVM overhead.

    Why this is correct

    The container memory limit is 1Gi, but the Java heap is set to 768Mi. The JVM requires additional memory beyond the heap for metaspace, thread stacks, code cache, and native memory. This overhead can easily exceed 256Mi, pushing total memory usage above the 1Gi limit. When the container exceeds its limit, the kernel OOM killer terminates the process, resulting in 'OOMKilled' status. The node has available memory, so the issue is the container limit, not node pressure.

  • ✗

    The container is being killed by the Kubernetes liveness probe due to high memory usage.

    Why it's wrong here

    A liveness probe failure results in the container being restarted, but the status would show 'Error' or 'CrashLoopBackOff', not 'OOMKilled'. The 'OOMKilled' status is specifically set when the kernel OOM killer terminates the process because it exceeded the cgroup memory limit. Liveness probes do not trigger OOMKilled; they trigger restarts based on health checks. Thus, this is not the cause.

  • ✗

    The Java application has a memory leak that causes it to exceed the heap size.

    Why it's wrong here

    A memory leak would eventually cause the heap to grow, but the JVM heap is capped at 768Mi. If the heap is exhausted, the JVM would throw OutOfMemoryError and the application might crash, but the container would not necessarily be OOMKilled by the kernel unless total memory exceeds the cgroup limit. The 'OOMKilled' status specifically indicates the kernel killed the container due to exceeding the cgroup memory limit, which is more likely due to JVM overhead than a leak.

  • ✗

    The memory request is too low, causing the pod to be scheduled on a node with insufficient memory.

    Why it's wrong here

    The memory request (512Mi) is used by the scheduler to find a node with enough allocatable memory. The node has 2Gi available, which is more than the request, so scheduling is not the issue. Even if the request were too low, the pod would still be scheduled, but the OOMKilled would occur only if the container exceeds its limit. The node has sufficient memory, so the problem is the container's memory limit being exceeded.

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

About these practice questions

This CV0-004 question is part of Courseiva's 834-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 →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official CompTIA exam blueprint

This CV0-004 practice question is part of Courseiva's free CompTIA 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 CV0-004 exam.