A civic permitting service should keep calling localhost while a helper container translates those calls to a legacy mainframe adapter. Which pattern is this?
Select an answer to reveal the explanation.
Short Explanation
An ambassador is like a bilingual concierge in the same suite: your app speaks simple localhost, and the concierge translates to the cranky legacy system next door.
Full Explanation
A civic permitting service that keeps calling localhost while a helper container translates those calls to a legacy mainframe adapter is using an ambassador (proxy) sidecar. The application retains a simple localhost client; the ambassador adapts protocol, authentication, or routing toward the external mainframe. Because containers in a Pod share one network namespace, localhost reaches the sidecar without Service DNS or kube-proxy hairpinning.
An init container that must exit before any outbound call is allowed cannot remain running to proxy live traffic after startup. A DaemonSet on every node that replaces Service discovery is a cluster-wide agent pattern, not an in-Pod ambassador dedicated to one permitting app. A PersistentVolumeClaim that stores mainframe responses as the primary API confuses durable storage with synchronous network adaptation.
Exam caveat: Ambassador versus adapter versus logging sidecars are core CKAD vocabulary. Ambassadors focus on proxying; adapters transform output formats; logging sidecars ship files. All rely on shared Pod networking and, when needed, shared volumes.
Operational check: kubectl exec -c app -- curl -sS 127.0.0.1:<ambassador-port>/healthz; confirm a permit submission appears in kubectl logs -c ambassador; scale the Deployment and ensure each Pod gets its own ambassador pair.