A municipal SRE plans to delete a failing pod after collecting evidence. Why should logs be dumped before deletion when no centralized logging is in place?
Select an answer to reveal the explanation.
Short Explanation
No log shipper means the pod's diary burns when you delete it. Save the logs first, then tear down—postmortems hate empty folders.
Full Explanation
When no centralized logging is in place, container logs for a pod typically live on the node filesystem managed by the runtime. A municipal SRE who plans to delete a failing pod should dump logs first because those node-local logs are usually lost once the pod is removed unless they were gathered or shipped elsewhere. Postmortems hate empty folders. Deletion does not always archive logs into etcd for ninety days; etcd is not a log archive for container stdout. kubectl delete does not automatically email stdout to the cluster admin; that convenience does not exist. Pending pods do not retain logs forever after deletion; removal clears the local container log artifacts with the pod sandbox. Exam caveat: Even with a log shipper, verify ingestion lag before delete. On the exam, the durable lesson is: collect first when retention is node-local. Operational check: kubectl logs (and --previous if needed), save to the ticket or object storage, then delete or recreate the pod, and prioritize deploying cluster logging for civic workloads. In municipal production practice, record the finding in the incident ticket with command output snippets, confirm the fix under change control, and re-validate the user-facing civic service before closing the change window.