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.

• ✗

  The network bandwidth is saturated, causing log delivery to fail. Increase instance network performance.

  Why it's wrong here

  Network saturation would typically manifest as CloudWatch Logs API call failures, connection timeouts, or a backlog of unsent log batches with corresponding `ClientError` or `Throttling` entries in the agent logs, not as clean, silently missing log periods. The provided evidence points to sustained high EC2 CPU utilization as the root cause, and upgrading network performance would not address CPU contention that prevents the agent from collecting and forwarding its buffers. A missing period in CloudWatch Logs alongside high CPU is far more consistent with the agent being unable to schedule its collection loop than with a network bottleneck.

• ✗

  The CloudWatch Logs retention policy is set to 1 day, so older logs are deleted. Increase retention.

  Why it's wrong here

  CloudWatch Logs retention policy controls how long ingested log events are retained before deletion; it has no effect on whether new log events are delivered or appear in near real-time. A 1-day retention would simply cause logs older than one day to be expunged, but you would still see a continuous stream of recent events unless delivery itself stopped. Since the problem is missing periods of logs while high CPU is observed, retention is a red herring — it does not cause gaps in the current data stream.

• ✓

  The CloudWatch agent is being starved of CPU resources, causing it to drop logs. Increase the CPU credits or instance size.

  Why this is correct

  The CloudWatch agent runs as a separate user-space daemon that periodically reads log files and sends them to the CloudWatch Logs API. When the host's CPU is saturated — especially on T-series instances with exhausted CPU credits — the agent's log collection and flush loop can be delayed or preempted for long enough that it begins dropping buffered events to avoid creating an ever-growing backlog. Increasing instance size or CPU credits gives the agent the scheduling time it needs to reliably process and upload log batches, directly resolving the observed missing periods.

• ✗

  The instances are running out of disk space, preventing log buffering. Add more EBS volume space.

  Why it's wrong here

  Disk exhaustion on the instance would typically produce `No space left on device` errors when the agent attempts to write its state file or when the application itself cannot append to the monitored log file, often accompanied by the log file size remaining static and a flooded agent log with I/O errors. The agent does not rely on free EBS space to buffer logs for delivery — it uses in-memory batching with an optional local queue that is much smaller and not the likely failure point here. Adding EBS volume space would address capacity concerns but would do nothing to fix the CPU starvation that prevents the agent from running its collection thread.

Go deeper

Related to this question