Exercise 2: Why Spend Exceeded an Alerts-Only Budget — Possible Solution
====================================================================

A standard Cloud Billing budget is alerts-only by real, explicit
design - Google's own documentation states plainly that it "doesn't
automatically cap" usage or spending. Setting a $1,000/month budget
only configures notification thresholds (by default at 50%, 90%, and
100% of that amount); it never places any actual ceiling on what the
project is allowed to spend. Once real usage keeps climbing past
100%, the team keeps receiving alert emails, but nothing in the
standard budget mechanism itself ever stops the underlying services
from continuing to run and accrue cost - which is exactly how spend
reached $1,500 with no interruption.

The real alternative that would have actually stopped spending is
GCP's separate spend cap budget type (currently in preview, and only
available for supported services) - unlike a standard alerts-only
budget, a spend cap budget can actually pause a service once its
threshold is reached, rather than only sending a notification.

ANSWER: This happened because a standard budget only sends alerts and
never caps spending, by real, stated design - the team received
notifications at 50%, 90%, and 100%, but nothing automatically stopped
usage from continuing past that. The alternative that would have
actually stopped spending is GCP's separate spend cap budget type,
which can pause a supported service once its threshold is reached.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly explains the real alerts-only default behavior
(matching the same confirmed pattern across AWS and Azure) and
correctly names the one real GCP-specific feature - spend cap
budgets - that genuinely differs from that default.