Interview Kubernetes, Docker, Helm & Podman

What is the role of the ENTRYPOINT exec form versus shell form regarding signals?

Kubernetes, Docker, Helm & Podman · Advanced level

Answer

Exec form ENTRYPOINT runs the process directly, so it receives signals properly as PID 1. Shell form wraps the command in /bin/sh -c, which can swallow signals, complicate argument parsing, and break graceful shutdown.

Technical explanation

PID 1 has special signal and zombie-reaping behavior in Linux, so container entrypoint design affects graceful shutdown.

Use exec form and consider a minimal init such as tini only when the app does not reap child processes.

Container image quality affects supply chain, startup time, vulnerability surface, rollout reliability, and debugging workflows.

Prefer reproducible builds: pinned dependencies, small build context, deterministic Dockerfile order, non-root runtime, and immutable image references.

Understand the runtime boundary: an image is not a VM, and container isolation depends on kernel, namespaces, cgroups, capabilities, seccomp, and mounts.

Hands-on example

1. Create a tiny sample app and Dockerfile for this exercise: compare shell-form and exec-form ENTRYPOINT signal handling.

2. Build and inspect it with docker build or podman build, docker history, image inspect, and a vulnerability or size scan if available.

3. Run it locally with explicit env vars, ports, user, volumes, and signal tests depending on the question.

4. Convert the final runtime assumptions into Kubernetes fields such as image, command, args, ports, securityContext, probes, and volumeMounts.

Preparing for an interview?

Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.

More Kubernetes, Docker, Helm & Podman interview questions

← All Kubernetes, Docker, Helm & Podman questions