Exercise 3: Four Instances of the Reconciliation Loop Across the Full Course — Possible Solution
====================================================================

The reconciliation loop, per Chapter 2 (Course 1): observe current
state, compare against desired state, act to reconcile any difference,
repeat forever. Four genuinely different instances of this exact
pattern, spanning both courses:

1. REPLICASETS MAINTAINING POD COUNT (Course 1, Chapter 5). Desired
   state = a specific NUMBER of pods matching a template; the
   controller continuously creates or deletes pods to reconcile the
   actual count against that number.

2. SERVICES MAINTAINING THEIR ENDPOINTS LIST (Course 1, Chapter 6).
   Desired state = "route to whichever pods currently match this
   label selector and are healthy"; the Service continuously updates
   its Endpoints list to reconcile against which pods actually
   currently match.

3. LIVENESS PROBES DECIDING WHETHER TO RESTART A CONTAINER (Course 1,
   Chapter 11). Desired state = "this container is functioning
   correctly"; the kubelet continuously observes actual container
   health via the probe and restarts it to reconcile a detected
   failure.

4. HPA ADJUSTING REPLICA COUNT BASED ON METRICS (Course 2,
   `k8s2-6`). Desired state = a target utilization percentage;
   HPA continuously observes actual CPU/memory usage and adjusts
   replica count to reconcile actual utilization toward that target.

(A fifth valid example: DaemonSets, Course 2 `k8s2-2`, reconciling
"one pod per matching node" as nodes are added or removed from the
cluster.)

This chapter's own GitOps controller example, as the closing instance:

THE GITOPS CONTROLLER RECONCILING THE ENTIRE CLUSTER AGAINST A GIT
REPOSITORY (Course 2, this chapter). Desired state = whatever the git
repository's YAML/Helm charts currently describe; the controller
continuously observes the cluster's actual deployed state and applies
changes (or reverts drift) to reconcile it against what git says
should exist -- operating at the largest possible scale of any example
in this list, an entire cluster's full configuration, rather than a
single pod, Service, container, or metric.

What ties all of these together: despite operating on completely
different kinds of resources at wildly different SCALES -- from a
single container's health (liveness probes) all the way up to an
entire cluster's complete configuration (GitOps) -- every one of these
is built from the exact same underlying structure: continuously watch
reality, compare it against a stated intention, and correct any gap
automatically, without a human needing to notice and intervene
manually each time.

WHY THIS WORKS AS AN ANSWER
------------------------------
This names four genuinely distinct examples spanning both courses
(rather than four variations on the same one), explicitly includes the
chapter's own GitOps example as requested, and states clearly what
makes GitOps's instance of the pattern notable -- it's the SAME
mechanism operating at the largest scale of any instance named across
the entire course, which is exactly why this chapter frames it as a
fitting closing thread.