Exercise 3: Nobody Owns the VPN Connection During an Incident — Possible Solution
====================================================================

Why this ambiguity happens:

Per this chapter, in a single-provider environment, Chapter 1's "of
the cloud" vs. "in the cloud" responsibility split is relatively clean
-- the provider owns one side of a clear line, the customer owns the
other. In a hybrid environment, a THIRD ZONE exists: the connectivity/
integration layer BETWEEN the on-prem environment and the cloud
environment -- in this case, the VPN connection itself. This zone
doesn't automatically fall under either the cloud provider's
responsibility model (they typically manage their own end of the VPN
endpoint, but not the on-prem side or the link's overall behavior) or
under the on-prem network team's traditional scope (which may not
have been explicitly extended to cover a hybrid link into a cloud
environment).

Because neither existing responsibility framework was ever explicitly
extended to clearly claim this specific in-between zone, BOTH teams
can reasonably (and sincerely) believe the OTHER team owns
investigating it -- not out of negligence, but because the ambiguity
is a genuine structural gap in how responsibility was originally
divided, not a case of either team being wrong about their own
existing scope.

What should be done about it:

Per this chapter's own practical approach: "be explicit about who owns
the connectivity/integration layer specifically, rather than assuming
it's automatically covered by an existing responsibility split." This
needs to be decided and documented BEFORE an incident, not resolved
for the first time DURING one -- during an active incident, the
priority should be assigning joint or explicitly-designated ownership
of investigating the connection itself immediately (even if that means
temporarily pulling in both teams together rather than waiting to
determine "whose job it really is"), so that troubleshooting can
actually begin rather than stalling on an unresolved ownership
question while the production impact continues.

Longer-term, per the chapter's warn-box, the real fix is closing this
specific ambiguity proactively -- explicitly documenting, ahead of the
next incident, which team (or a jointly-defined process) owns
investigating the connectivity layer specifically, so this exact
finger-pointing delay doesn't recur the next time a similar incident
happens.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the STRUCTURAL reason the ambiguity exists (a third
zone that neither existing responsibility framework was ever extended
to explicitly cover) rather than framing it as a simple communication
failure, and then applies the chapter's own stated fix -- explicit,
proactive ownership assignment -- both as an immediate incident-time
action and as a longer-term process fix, matching the chapter's own
warn-box directly.