TL;DR: The API server authenticates, admits and persists the object to etcd, and that is the whole of the write path. Everything after it is controllers watching for a difference and acting: the deployment and replicaset controllers create the pod, the scheduler binds it to a node, the kubelet pulls and starts it, and the CNI and kube-proxy make it reachable.
How to approach it
Name the stages in order and keep each to a sentence. The value of the answer is that it gives you a fault tree: for every stage you name, you know what "stuck here" looks like. Finish by mapping each stalled transition to the component you would inspect.
A strong answer
The request hits the API server, which authenticates you, authorises the verb against RBAC, then runs admission. Mutating admission webhooks and defaulting run first, so this is where a sidecar gets injected or a default resource limit gets stamped on. Validating admission and policy engines such as Kyverno or a Pod Security admission run next and can reject outright. If it survives, the object is persisted to etcd and the API server returns success. Your kubectl apply is now done, and nothing is running.
Everything after this is a control loop. The deployment controller sees a Deployment with no matching ReplicaSet and creates one. The replicaset controller sees a ReplicaSet whose desired replica count exceeds observed and creates Pod objects, which land in etcd with nodeName empty.
The scheduler watches for unbound pods. It filters nodes that cannot run the pod at all (insufficient allocatable resources, unsatisfied node selector or affinity, an untolerated taint, an unbindable volume) and then scores the survivors and writes a binding. If nothing survives filtering, the pod sits in Pending and the events explain which predicate failed.
The kubelet on the bound node takes over. Through CRI it asks the container runtime to create the pod sandbox; the runtime normally creates the network namespace and invokes CNI to configure networking and allocate an IP. Storage controllers and the kubelet coordinate CSI attachment and mounting. The runtime pulls images and starts containers. Ordinary init containers complete in sequence; restartable native sidecars can continue running after their startup condition allows the next container. EndpointSlices can contain an unready pod already: readiness updates endpoint conditions, which service proxies normally use to select traffic destinations. Pod lifecycle, EndpointSlice conditions.
The debugging payoff: Pending covers both unscheduled pods and scheduled pods whose containers are not yet set up. Inspect PodScheduled and events before blaming the scheduler. ContainerCreating means the kubelet is stuck on CNI, CSI or an image pull. CrashLoopBackOff means it started and died, so read the last terminated state. Running but not receiving traffic means readiness or the selector, not the pod.
What interviewers probe next
"Where is the pod's IP assigned?" By the CNI plugin, on the node, into the pod's network namespace. Not by the API server, and not by the scheduler.
"What if the scheduler is down?" Existing pods keep running because the kubelet does not need it. New pods stay Pending indefinitely. This is a good illustration of why the control plane is not on the data path.
"Where would an injected sidecar come from?" A mutating admission webhook, which is why it appears in the object even though nobody wrote it in the manifest.
Common mistakes
Describing it as a linear pipeline where each component calls the next. Controllers coordinate asynchronously through API state, while kubelet, runtimes and plugins also make direct API calls. Controllers watch the API server and reconcile, which is why the failure modes are "stuck" rather than "errored".
Skipping admission. It is where a surprising share of real production behaviour is introduced, and interviewers notice its absence.
Saying the scheduler "starts the pod". The scheduler only writes a node name. The kubelet starts things.