Google ACE Practice Question: A GKE application Pod needs a sidecar container…

A GKE application Pod needs a sidecar container that proxies all outbound network requests through an audit logger before they reach the internet. Both containers share the same network namespace. Which Kubernetes pattern implements this?

⚠ Common exam trap

Google Cloud often tests the distinction between initContainers and sidecars, where candidates mistakenly choose initContainers because they think 'start before the main app' implies ongoing traffic interception, but initContainers exit after completion and cannot proxy runtime traffic.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Add the audit logger as a second container in the same Pod spec (sidecar pattern)

The sidecar pattern allows two containers to share the same network namespace within a single Pod, enabling the audit logger to intercept all outbound traffic from the application container before it reaches the internet. This is achieved by configuring the application container to route its outbound requests through the sidecar (e.g., via a localhost proxy or iptables rules), ensuring all traffic is logged without external network hops.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Run the audit logger as a separate Deployment and route traffic via a Service
Why it's wrong here
Running the audit logger in a separate Deployment creates a separate Pod with its own network namespace, so to route traffic through it you would need to explicitly configure the application or a Service to forward traffic, which adds latency and requires modifying the application's endpoint configuration. It cannot intercept traffic that the application sends directly because the application's outbound connections do not naturally pass through that Service; only traffic explicitly destined to the Service would be seen, missing most application traffic.
✓
Add the audit logger as a second container in the same Pod spec (sidecar pattern)
Why this is correct
A sidecar container in the same Pod shares the network namespace with the main application container, meaning both can bind to the same localhost interface and the sidecar can transparently proxy or audit all traffic entering or leaving the Pod. This pattern is ideal for audit logging because it requires no code changes to the application and provides a complete view of the Pod's network activity, including both inbound and outbound connections, at the Pod boundary.
✗
Use a DaemonSet for the audit logger on each node to intercept node-level traffic
Why it's wrong here
A DaemonSet places one pod on every node, so an audit logger in a DaemonSet runs at the node level, not inside the application Pod. Intercepting traffic at the node level typically requires manipulating iptables or CNI rules to redirect flows, which is complex and affects all Pods on that node, not just the target application. This approach cannot selectively and transparently proxy per-Pod application traffic without significant risk of misrouting or performance overhead.
✗
Add an initContainer to start the audit logger before the main application
Why it's wrong here
InitContainers run to completion one by one before any regular containers start, so an audit logger added as an initContainer would start, perhaps capture some initial setup traffic, and then terminate before the main application even launches. They are designed for initialization tasks like waiting for services to be ready or preparing files, not for continuous background processes like logging agents that need to run alongside the application for the lifetime of the Pod.

Go deeper

Google ACE Practice Question: A GKE application Pod needs a sidecar container…

Why each option matters

Option-by-option breakdown

Related to this question