A parks-and-rec team wants one kubectl command that aggregates application logs from every Pod across the cluster like a production logging platform. What should you clarify?
Select an answer to reveal the explanation.
Short Explanation
kubectl logs is a flashlight for one Pod at a time—not the streetlight grid for the whole city. For durable, cluster-wide search you still want a real logging stack. Keep kubectl for triage, not as your SIEM.
Full Explanation
Parks-and-rec teams sometimes expect one kubectl invocation to behave like a production logging platform across every Pod. The clarification they need is that kubectl logs is a per-Pod (and per-container) stream against the kubelet’s local log files—it is not durable, indexed, multi-tenant aggregation. Cluster-wide, historical, searchable logging for municipal production requires a logging stack (agents such as Fluent Bit/Fluentd, plus a backend). That distinction keeps on-call expectations realistic: kubectl is excellent for live triage of one workload; it is not the citywide SIEM.
Suggesting kubectl logs -A --all-containers as a supported SIEM replacement fails because even broad kubectl log flags still pull ephemeral streams without retention, indexing, access controls for analysts, or reliable historical query—and flooding terminals is not an observability architecture. Installing Fluent Bit as a Deployment solely “so kubectl can query historical indexes” fails conceptually: agents ship logs to backends; kubectl does not become the query API for those indexes. Enabling API server audit logging fails because audit logs record API requests (who did what to which object), not application stdout lines from parks services.
Exam caveat: some managed platforms add vendor log UIs, but CKAD still expects you to know kubectl’s scope versus a real logging pipeline. Operational check: document that production municipal apps ship logs via DaemonSet/agent + backend; use kubectl logs only for targeted debugging, with -c, --tail, and --timestamps as needed, and never treat an empty kubectl session as proof that “logging is fine cluster-wide.”