Exercise 1: Control Plane Unavailable, Worker Nodes Healthy — What Happens — Possible Solution
====================================================================

(a) Already-running application pods: THEY KEEP RUNNING.

Per the chapter, "already-running workloads on worker nodes keep
running even if the control plane is briefly unavailable." Once a pod
has been scheduled onto a node and the kubelet has instructed the
container runtime to start it, that container simply continues
executing as a normal running process on that machine -- it does not
depend on continuous, live contact with the control plane just to keep
existing and serving traffic. The kubelet also continues managing
already-assigned pods locally (restarting a crashed container per its
restart policy, for example) largely independent of the control plane
being reachable.

(b) The ability to schedule new pods: THIS STOPS WORKING.

Per the chapter's own kubectl-to-pod flow, creating a NEW pod requires
the API server to accept the request and write it to etcd, and the
scheduler to notice it and assign it to a node -- both of which are
control-plane functions. If the control plane is unavailable, none of
this can happen: no new pods can be created, no scheduling decisions
can be made, and (relatedly) no status updates or configuration
changes can be applied to the cluster at all, since kubectl itself
talks to the API server for everything.

Why these two outcomes differ:

The key distinction is between DECISIONS ALREADY MADE (and already
acted upon by the kubelet/runtime on a healthy node) versus NEW
DECISIONS that haven't been made yet. Existing pods represent a
decision the scheduler and kubelet already executed in the past,
which doesn't need to be re-confirmed continuously to keep running.
Creating something NEW, or changing existing state, requires going
through the API server and (for scheduling) the scheduler -- both
control-plane components that are, by definition, unavailable in this
scenario.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly applies the chapter's own explicit statement about
already-running workloads surviving a control-plane outage, and
derives the "new pods can't be scheduled" consequence from the
chapter's own architecture walkthrough (API server -> etcd ->
scheduler being required steps for anything NEW to happen) -- the
distinguishing principle being "already decided and running" vs.
"requires a new decision."