KCNA - Cloud Native Architecture (12% of the exam) - Section 4.4
Explain what a service mesh provides and when it is warranted.
The sidecar and ambient data-plane models, mutual TLS between services, traffic splitting and retries, and the operational cost a mesh adds relative to the problems it solves.
service meshIstioLinkerdsidecar proxymutual TLSEnvoy
Practice question for this objective
lock_openFree sampleCloud Native Architecturehard
A platform team adds a service mesh to a cluster and observes that a lightweight proxy container is now injected alongside every application container in each Pod, intercepting all inbound and outbound traffic for that Pod. What is this per-Pod proxy pattern called, and what does it fundamentally allow the mesh to do?
AIt is the DaemonSet pattern, which runs one shared proxy per node so that all Pods on that node route through a single node-level agent.
BIt is the sidecar proxy pattern, which lets the mesh handle traffic concerns such as encryption, retries and telemetry without changing application code.check_circle Correct
CIt is the init-container pattern, which runs once before the application starts to configure networking and then exits before traffic flows.
DIt is the ambassador pattern, which exposes the application to external clients by proxying only inbound requests from outside the cluster.
Recognise that a service mesh works by injecting a sidecar proxy into each Pod to handle traffic concerns transparently to the application. A service mesh places a data-plane proxy as a sidecar container in every Pod. Because the proxy intercepts all of the Pod's traffic, the mesh can enforce encryption, retries, timeouts and telemetry uniformly without any change to application code.
Why A is wrong: Tempting because a node-level proxy does exist in some designs and DaemonSets run one Pod per node, but the described per-Pod injected proxy is a sidecar, not a single shared node agent.
Why B is correct: Correct: a service mesh injects a sidecar proxy into each Pod so the proxy transparently intercepts traffic and applies policy, meaning features like mTLS, retries and metrics are added without modifying the app.
Why C is wrong: Tempting because meshes do use an init container to set up iptables rules, but that container exits at startup and cannot intercept live traffic, so it is not the proxy that carries ongoing requests.
Why D is wrong: Tempting because an ambassador proxy is a real sidecar variant, but it handles a narrow outbound-representation or edge role and does not describe the mesh proxy intercepting all inbound and outbound Pod traffic.
Answers that look right on this material and are not. Each one is a distractor from a different question in the KCNA bank for this domain.
It is the mesh control plane, which each Pod runs locally to store configuration and issue certificates
errorWhy it is wrong: Tempting because the control plane does distribute configuration and certificates, but it runs as its own separate workload, not as a container inside every application Pod.
A HorizontalPodAutoscaler that scales the new version's replicas up as traffic increases
errorWhy it is wrong: Tempting because autoscaling reacts to load, but it changes replica counts based on metrics and does nothing to control what fraction of requests reaches each version.
A service mesh removes the need for Kubernetes Services, so adopting it would force them to rewrite their existing service discovery.
errorWhy it is wrong: Tempting because a mesh does add its own traffic layer, but it runs on top of Kubernetes Services rather than replacing them, so this is not a real cost of adoption.