CKAD Application Design and Build Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Sidecar containers are always started before the main container

  Why it's wrong here

  Kubernetes does not guarantee any startup order for containers inside a Pod; the kubelet starts them in parallel, so a sidecar may not be running before the main application begins. While the sidecar pattern often implies a functional dependency, such as a proxy needing to be up first, that ordering is not enforced by the runtime. If strict ordering is essential, operators use init containers or wait for readiness probes, not this statement.

• ✓

  Sidecar containers are used for tasks like log collection, service mesh proxies, or data synchronization

  Why this is correct

  A sidecar container is an auxiliary process that deploys alongside the main container to provide supporting functionality without being the primary workload. Common use cases include collecting and shipping logs (e.g., Fluentd), acting as a service mesh proxy (e.g., Envoy), or synchronizing data volumes between local and remote storage. This pattern encapsulates cross-cutting concerns into a separate, co-located process that shares the Pod's lifecycle.

• ✗

  Sidecar containers can be updated independently without restarting the main container

  Why it's wrong here

  Kubernetes treats a Pod as the smallest immutable scheduling unit, and all containers within it share the same lifecycle. Any modification to the Pod spec, including an image change for a single sidecar container, requires the entire Pod to be recreated — there is no in-place update mechanism for individual containers. Even the newer native sidecar support in Kubernetes 1.28+ does not change this: updating a sidecar still forces a full Pod restart because the Pod's status and resource allocation are tied to all its containers.

• ✓

  Sidecar containers run in the same Pod as the main container

  Why this is correct

  By definition, a sidecar is deployed in the same Pod as its main application container, sharing the Pod's lifecycle, storage volumes, and network. This co-location allows the sidecar to read and write the same shared volume (e.g., log files or cached data) and to communicate with the main app over the loopback interface. Because they belong to the same Pod, the sidecar is terminated, killed, or rescheduled whenever the main container's Pod is, making the sidecar an extension of the main workload.

• ✓

  Sidecar containers share the same network namespace as the main container

  Why this is correct

  All containers within a Kubernetes Pod share the same network namespace: they use the same loopback interface, IP address, hostname, and port space. This is what enables a sidecar proxy, like an Envoy or Linkerd mesh sidecar, to intercept all traffic intended for the main application by listening on a localhost port and forwarding it to the app's own port. It also means the sidecar and main container can communicate using 127.0.0.1 without any service discovery, simplifying configuration but also making the network namespace a shared failure domain.

Go deeper

Related to this question