Technical explanation

C is not a valid description. A service-mesh sidecar externalizes networking functions into a proxy container running beside the application; it does not force the instrumentation logic into the application’s source code. In fact, a core service-mesh objective is to provide connectivity, security, traffic management, and observability transparently without requiring application-code changes.

The operational concerns in the other choices are characteristic of sidecar implementations. A proxy must be injected into each workload pod, increasing container count and potentially affecting pod initialization, resource consumption, ordering, and readiness. Adding a sidecar to an existing pod template normally requires the pods to be recreated because Kubernetes cannot dynamically add a new container to an already-running pod.

Traffic interception also directs application traffic through the sidecar proxy and its network namespace paths, adding network-stack traversal and proxy-processing overhead. Cilium’s service-mesh design can instead use node-level Envoy proxies together with eBPF traffic redirection, avoiding one proxy container in every application pod. This preserves transparent application behavior while reducing the per-workload operational burden.

Official references

Cilium Service Mesh , Cilium Ingress and Network Policy Example

Study Guide topic: Sidecar-based and sidecar-free service-mesh architectures.