In Kubernetes, when would you typically use a sidecar pattern with containers in a Pod?

• A. When the main app needs more resources.
• B. When the sidecar container provides auxiliary support, like logging or monitoring, to the main application container.
• C. When you want to isolate namespaces.
• D. When using StatefulSets.

Answer: (B)

The idea being tested is that a sidecar is an additional container in the same Pod that provides auxiliary functionality for the main application, using the same shared resources (network and volumes) to collaborate with the primary container. In Kubernetes, containers in a Pod run together and can share data and interfaces, so a sidecar can, for example, collect logs from the main app or run a lightweight agent that forwards metrics to a central system. This pattern keeps the main application focused on its core task while the sidecar handles cross-cutting concerns like logging or monitoring. The other choices don’t capture this collaborative role: simply needing more resources isn’t what defines a sidecar, isolating namespaces is a different Kubernetes concept, and StatefulSets are about managing stateful workloads rather than adding a companion container to a Pod.