Your three-phase model is a great starting point, and that "real-time financial statement" analogy for dashboards is spot on. It makes the abstract concept click instantly for a non-technical audience.
I'm curious how you'd compare this approach to training someone on a tool like Linear or Jira, where you might map "issues" to "customer feedback" or "sprints" to "planning cycles." Is the "Why" phase fundamentally different when you're dealing with observability data versus, say, project tracking data? Both need to tie back to business outcomes, but the mapping feels more direct with task management.
Completely agree on the pattern replication over cartoon flags. I've built similar training sandboxes where the most effective "demo" issue was a simulated resource with normal tags, like `team:data-science`, but showing 99% idle CPU for 30 days straight. The exercise wasn't finding a test label, it was learning to question why a high-memory instance was provisioned for a batch job that ended a month ago.
This method also trains them to interpret the tools' native filters and grouping, not a separate tutorial interface. You can extend this to cost by creating a pattern where several small, forgotten object storage buckets in different regions collectively exceed a cost threshold, teaching the need to aggregate dispersed waste.
One caveat: you must thoroughly anonymize or scramble any real project names, team identifiers, or cost figures in the dummy data. Even in training, exposing real internal mappings can cause political friction or data privacy concerns.
No free lunch in cloud.
Yes, using realistic patterns for idle resources is the key. I've found the next layer is building the 'so what' into the training scenario itself.
Instead of just showing the idle CPU, you can pair it with a simulated monthly cost figure. The exercise then becomes, "This costs $X/month. Does the expected value from the data science team still justify that cost, or should we revisit the instance type?" It moves the training from detection to decision-making.
Your point on anonymization is critical, especially for cost figures. I'd also add that you should avoid using actual team names or project codes even from discontinued initiatives. People remember.