Exercise 1: Investigating a Failure With No Cross-Boundary Correlation ID — Possible Solution
====================================================================

The practical fallback approach, per this chapter's own material:
narrow by TIME WINDOW plus a likely RESOURCE IDENTIFIER, independently
on EACH side of the boundary -- on the on-prem system's own logs, and
separately on the AWS-hosted service's own logs -- then manually
attempt to line up entries from both sources that fall within the same
approximate time window and appear to relate to the same request or
resource.

The limitation compared to Chapter 4's single-provider version:

Chapter 4's correlation-ID technique, within a single provider, lets
an investigator search MULTIPLE services' logs for one exact,
unambiguous identifier value, precisely isolating only the log entries
that genuinely belong to one specific failing request -- a precise,
targeted lookup.

The cross-boundary fallback described in THIS chapter has no such
precise identifier to search for at all. It relies on TIME PROXIMITY
and RESOURCE IDENTIFIERS as an approximation of "these entries
probably relate to the same request" -- which is inherently less
certain. Per this chapter's own explicit statement, this fallback is
"genuinely more manual and error-prone than Chapter 4's single-
provider version" -- specifically because:

1. Two SEPARATE, unrelated requests occurring close together in time
   on both systems could be mistakenly correlated as if they were the
   same request, when they weren't.

2. Clock synchronization between two completely independent systems
   (on-prem and a cloud provider) may not be perfectly aligned, adding
   further uncertainty to what "the same time window" even means
   precisely across the two sources.

3. It requires manually cross-referencing two ENTIRELY SEPARATE
   logging/monitoring systems by hand (per this chapter's own point
   that each side "almost certainly has completely separate logging
   and monitoring systems"), rather than a single unified search the
   way a shared correlation ID would allow.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly names the chapter's own stated fallback technique and
then explains, mechanism by mechanism, why it's a strictly weaker
substitute for a true correlation ID -- rather than simply asserting
it's "less good," it identifies the SPECIFIC sources of imprecision
(coincidental timing overlap, clock skew, manual cross-referencing)
that the chapter's own single-provider version doesn't suffer from.