A library pod runs an app container and a logging sidecar. kubectl logs without a container name fails with an ambiguous-container error. What must the administrator do?

When a library pod runs an application container plus a logging sidecar, kubectl logs without a container name fails with an ambiguous-container error because the API cannot know which stream you requested. The administrator must specify the target container with -c or --container using the container’s name—each container keeps its own diary on stdout and stderr. Deleting the sidecar before any log collection is possible is unnecessary and destructive; selecting the container with -c is the supported and sufficient approach. Switching the pod to hostPID to merge log streams automatically is unrelated to kubectl’s container-selection requirement and weakens process isolation without solving the ambiguity error. Annotating the Service with a fictional logging.kubernetes.io/force-all annotation does not make kubectl choose among containers; Service annotations are not a substitute for the -c flag. Exam caveat: Init containers also require explicit selection when you need their logs. Under time pressure, read container names from the pod spec or wide describe output before issuing logs. Operational check: List container names from the pod, run kubectl logs <pod> -c <app|sidecar> as needed, and file both streams in the library outage notes when the review needs both voices.