Each replica of a public-works work-order API writes its own dated log file under /var/log on the container filesystem. Operators cannot search one incident across replicas after a node is replaced. Which logging design matches cloud-native practice?
Select an answer to reveal the explanation.
Short Explanation
Logs should flow like a radio broadcast the station records—not like sticky notes taped inside each taxi that vanish when the car is retired. Stdout as a stream lets the platform capture and search across replicas. Private per-host files die with the host.
Full Explanation
Cloud-native logging for the public-works work-order API means writing a time-ordered event stream to standard output and letting the platform capture and aggregate it. Per-replica files under /var/log on the container filesystem vanish or become unreachable when a node is replaced, and operators cannot search one incident across replicas from a single place. Stdout/stderr plus platform aggregation keeps logs off ephemeral container disks and makes multi-replica incident search feasible.
Keeping unique per-host files and SCPing them to a shared drive only during audits delays visibility until after the emergency and still depends on hosts that may already be gone. Disabling logging in production to save disk on ephemeral containers removes the evidence operators need when work orders fail for citizens. Emailing each log line to the on-call engineer as it is written does not scale, creates noise, and is not an aggregation strategy.
Exam caveat: the practice is stream-to-stdout with centralized capture—not “never use disk,” and not a requirement to name a particular logging SaaS product on the exam.
Operational check: emit structured logs to stdout from two replicas, replace one node, and confirm you can still query both replicas’ events for a single work-order id in the aggregated log system.