Which pattern is used to intercept traffic in the data plane of a Service Mesh?

Which pattern is used to intercept traffic in the data plane of a Service Mesh?

• A. Init Container pattern
• B. DaemonSet pattern
• C. Gateway pattern
• D. Sidecar pattern

Answer: (D)

Intercepting traffic in the data plane of a Service Mesh is accomplished with the sidecar pattern. A lightweight proxy runs alongside each service container in the same pod and sits in the path of all inbound and outbound traffic for that service. This proxy is responsible for routing, observing, and enforcing policies (such as mTLS, retries, timeouts, and circuit breaking) as dictated by the mesh’s control plane. The other patterns don’t fit this purpose: an Init Container runs a one-time setup before the main app starts, not ongoing traffic interception; a DaemonSet places a daemon on each node but isn’t the per-service data-plane proxy; and a Gateway handles edge ingress/egress rather than the inter-service traffic inside the mesh.

Intercepting traffic in the data plane of a Service Mesh is accomplished with the sidecar pattern. A lightweight proxy runs alongside each service container in the same pod and sits in the path of all inbound and outbound traffic for that service. This proxy is responsible for routing, observing, and enforcing policies (such as mTLS, retries, timeouts, and circuit breaking) as dictated by the mesh’s control plane. The other patterns don’t fit this purpose: an Init Container runs a one-time setup before the main app starts, not ongoing traffic interception; a DaemonSet places a daemon on each node but isn’t the per-service data-plane proxy; and a Gateway handles edge ingress/egress rather than the inter-service traffic inside the mesh.