Exercise 2: What Happens to the Display Manager on systemctl isolate multi-user.target — Possible Solution
====================================================================

Answer: the display manager stops.

Explanation:

Per the chapter's own description of systemctl isolate, running it
"stops everything NOT required by [the target being isolated to] --
the display manager included." The display manager is specifically
part of what graphical.target itself requires/wants (it's the
component that makes graphical.target a superset of multi-user.target
in the first place, per this chapter's own description of that
relationship), but it is NOT something multi-user.target itself
requires or wants -- multi-user.target's whole definition, per the
chapter's own compare-table, is "full multi-user, no GUI."

When systemctl isolate multi-user.target runs, systemd determines
what multi-user.target actually needs, and stops anything currently
running that ISN'T part of that set -- since the display manager falls
into exactly that category (needed by graphical.target, not needed by
multi-user.target), it gets stopped as part of this isolate operation.
This is precisely the mechanism the chapter names as making isolate a
genuine "live runlevel-style switch" -- comparable to what telinit 3
used to accomplish under System V init, but here driven by an actual
dependency-resolution operation (per this chapter's own comparison)
rather than a legacy numbered switch.

WHY THIS WORKS AS AN ANSWER
------------------------------
This states the direct answer (the display manager stops) and
explains the mechanism by connecting the display manager's own
membership in graphical.target's own dependency set (but not
multi-user.target's) to the chapter's own description of what
isolate actually does -- stopping anything not required by the target
being isolated to.