Exercise 2: Why One Workspace and Language Can't Cover Both Data Types — Possible Solution
====================================================================

Azure Monitor's own real data platform deliberately splits telemetry
across two genuinely separate workspace types, despite their similar
names. A Log Analytics workspace collects log and trace data, queried
using KQL (Kusto Query Language). An Azure Monitor workspace instead
collects Prometheus and OpenTelemetry metrics, queried using PromQL.

The team's own expectation -- querying both application log traces
AND Prometheus-based container metrics using the same query language
in the same workspace -- assumes these two real data types live in
one unified system. They don't: application log traces belong in a
Log Analytics workspace and are queried with KQL, while Prometheus
metrics belong in a separate Azure Monitor workspace and are queried
with PromQL. These are real, separate resource types with different
underlying data stores, not two names for the same underlying system.

ANSWER: This expectation is incorrect because Azure Monitor
deliberately uses two distinct real workspace types for these two
distinct data kinds -- logs/traces in a Log Analytics workspace
(KQL), and Prometheus/OpenTelemetry metrics in a separate Azure
Monitor workspace (PromQL). The team would need to query each data
type separately, in its own respective workspace and query language,
rather than expecting one unified query experience across both.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the specific real structural reason (two
separate resource types, not just two query languages layered on one
system) rather than only naming the two query languages, and directly
matches the chapter's own explicit warning that these are genuinely
separate systems despite their confusingly similar names.