A main civic container is hardened, but a logging sidecar requests CAP_SYS_ADMIN. What should the candidate conclude?
Select an answer to reveal the explanation.
Short Explanation
A side door with a master key still opens the whole building. Sidecars get the same securityContext scrutiny as the main app—drop wild capabilities like CAP_SYS_ADMIN unless truly justified. Logging does not need that hammer.
Full Explanation
Every container in a Pod—including logging sidecars—has its own securityContext and capability set. Hardening the main civic container while granting CAP_SYS_ADMIN to a sidecar undermines Pod isolation: the sidecar becomes a high-privilege foothold beside the app. Candidates should conclude that sidecars must meet the same SecurityContext standards as the main container and that unnecessary CAP_SYS_ADMIN must be rejected. Logging agents rarely need SYS_ADMIN; demand justification and prefer least-privilege alternatives.
Sidecars are not exempt from SecurityContext rules simply because they are not the primary container. CAP_SYS_ADMIN is not required for kubectl logs to work—log collection uses the kubelet/API mechanisms, not SYS_ADMIN inside the app Pod. It is also wrong to review only init containers: sidecars run for the Pod lifetime and inherit neither “Deployment ServiceAccount limits” as a substitute for capability policy nor a free pass from capability review.
Exam caveat: privilege is per-container; a hardened main container cannot redeem a privileged sibling. Operational check: list all containers in the Pod template, inspect each securityContext.capabilities, and remove CAP_SYS_ADMIN from the logging sidecar unless a documented, exceptional need exists. Confirm drop ALL (or equivalent) remains in force, and that city Pod Security policies would admit the Pod only after the sidecar is constrained like the main civic container.