A permitting service writes logs to files on disk. A second container in the same Pod must tail those files and ship them to a central system. Which pattern fits?
Select an answer to reveal the explanation.
Short Explanation
Sidecars are helpful roommates: same apartment (Pod), shared fridge (volume), each doing their chore. The logger tails files the app drops in the shared emptyDir and ships them out.
Full Explanation
A permitting service that writes logs to files on disk and needs a second container to tail and ship those files fits the logging sidecar pattern. Place both containers in the same Pod and mount a shared emptyDir at the log path so the app writes and the shipper reads the same files. Pod co-location and the shared volume give low-latency shipping without rewriting the app to log only to stdout—though stdout remains a best practice when feasible for municipal services.
A second Deployment whose Pods mount the first Pod’s filesystem over the network by default is not how Kubernetes works; Pod filesystems are not exported that way. Using only an init container fails because init must exit before the app starts and therefore cannot tail live logs. A CronJob outside the Pod that SSHs into the app container every minute is fragile, non-declarative, and not a CKAD multi-container pattern.
Exam caveat: Sidecars share fate/scheduling with the app Pod. Prefer stdout+node agents when possible, but file-tail sidecars with emptyDir remain a standard teaching pattern.
Operational check: kubectl exec into both containers (or use debug) to see the shared mount; kubectl logs -c shipper; delete the Pod and confirm emptyDir logs vanish while centralized shipped logs remain.