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.

• ✗

  Use 'kubectl logs' command immediately after the crash

  Why it's wrong here

  The `kubectl logs` command only retrieves the current container's buffered stdout/stderr from the kubelet's local log files. In a CrashLoopBackOff scenario, the container restarts rapidly and previous container instances are pruned, so the very logs that contain the root cause are often already gone before you can fetch them. It also depends on manual timing and does not persist or aggregate logs across pod restarts, making it unreliable for post-incident analysis.

• ✓

  Configure a sidecar container to stream logs to Amazon CloudWatch Logs

  Why this is correct

  A sidecar container, such as aws-for-fluent-bit, runs alongside the application in the same pod and streams log events to Amazon CloudWatch Logs in near real time. Even if the main application container crashes and immediately restarts, the sidecar remains operational, and the log events already shipped are safely retained in CloudWatch, enabling immediate debugging and automated alarms. This decouples log shipping from the application's lifetime and provides durable, searchable history that survives pod restarts and rescheduling.

• ✗

  Store logs in a ConfigMap

  Why it's wrong here

  A ConfigMap is an API resource intended to store non-confidential configuration as key/value pairs or small files, not as an appendable log store. Log data is dynamic, high-volume, and unbounded, whereas ConfigMaps have strict size limits (1 MiB) and cannot be updated by a container at runtime; they are also not designed to stream or rotate data. Attempting to write logs to a ConfigMap would hit size limits, require API calls or a controller to update, and still not help when the pod crashes.

• ✗

  Use 'kubectl exec' to access the container and check logs

  Why it's wrong here

  `kubectl exec` requires an actively running container to establish an interactive session, so in a crash loop the container may be in a Waiting or Terminated state and the command will fail with a ‘container not found’ error. Even if you manage to attach during a brief running window, you are only inspecting the current process state, not capturing the historical log stream, and any evidence from previous crashes is already lost. Exec is also a manual, one-off operation that cannot provide the continuous, centralized logging needed to debug a restarting pod.

Go deeper

Related to this question