Which of the following describes the governance of a service mesh?

Question

Options

• AAbstract service governance capabilities into a unified SDK implementation through SDK
• BUse the Sidecar pattern to deploy application components into separate processes or containers
• CService governance capabilities are directly embedded in the business code and implemented directly
• DService governance capabilities are unified by ESB-implemented

• A
  14% (4)
• B
  76% (22)
• C
  7% (2)
• D
  3% (1)

Explanation

A service mesh governs inter-service communication by deploying a sidecar proxy (e.g., Envoy) alongside each service instance in a separate container or process. This proxy intercepts all network traffic and enforces governance policies - load balancing, retries, circuit breaking, observability, mTLS - without touching business code, which is the defining architectural pattern of a service mesh.

Why the distractors are wrong:

• A (SDK): Embedding governance in a shared SDK couples it to application code and requires language-specific implementations per service. This is the pre-mesh approach that service meshes were designed to replace.
• C (embedded in business code): Directly coupling governance logic to business logic creates maintenance burdens and violates separation of concerns - exactly the problem a service mesh solves.
• D (ESB): An Enterprise Service Bus is a centralized message broker from the SOA era. It handles governance through a central hub, not through distributed sidecars, and introduces a single point of failure.

Memory tip: Think of the sidecar as a "bodyguard" riding alongside your service container - it handles all the traffic rules so your service can focus purely on business logic. If governance lives in the code or in a central bus, it's not a service mesh.

No community discussion yet for this question.