DOP-C02 Incident and Event Response Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  DiskReadOps

  Why it's wrong here

  DiskReadOps tracks the number of read operations completed by a disk volume. A memory leak consumes RAM and, later, possibly swap space, but it does not inherently cause disk reads; disk read activity typically stems from file I/O or application data access. While heavy paging can eventually lead to swap I/O, DiskReadOps specifically measures block device requests, not memory-consumption trends, making it insensitive to a leak.

• ✓

  MemoryUtilization (custom metric published via CloudWatch Agent).

  Why this is correct

  MemoryUtilization, published as a custom metric by the CloudWatch Agent, is calculated from /proc/meminfo or OS-level memory counters and represents the percentage of actual RAM in use. A memory leak causes this value to climb continuously over time as allocations are never freed, even when the workload is stable. Monitoring this metric reveals the leak as a monotonic upward trend, making it one of the most direct and essential signals for detection.

• ✗

  NetworkIn

  Why it's wrong here

  NetworkIn measures the number of bytes received on the instance's network interfaces. This metric is driven by incoming traffic, which has no direct relationship with memory allocation or deallocation. A process with a memory leak may continue to use the same network patterns, and the leak itself will not alter NetworkIn unless the leak is triggered by specific network requests—making it an unreliable and indirect indicator.

• ✓

  SwapUsage (custom metric published via CloudWatch Agent).

  Why this is correct

  SwapUsage, also published through the CloudWatch Agent, shows the amount of swap space currently used on the instance. As a memory leak progressively consumes RAM, the OS begins swapping idle or less-frequently accessed pages to disk, causing SwapUsage to rise. This metric is a strong, though lagging, indicator of memory pressure because it reflects the OS's response to dwindling free RAM, confirming that the leak is affecting the overall memory subsystem.

• ✗

  CPUUtilization

  Why it's wrong here

  CPUUtilization is a default CloudWatch metric that represents the percentage of allocated compute capacity being used. While a memory leak can cause the OS or garbage collector to compensate over time, the leak itself is a passive failure—the allocated memory simply remains unreferenced, and CPU usage is not necessarily affected until the system starts swapping or becomes OOM-bound. Many other factors, such as active load, thread contention, or inefficient code, can cause high CPU, so this metric lacks specificity for diagnosing a memory leak.

Go deeper

Related to this question