A grant-funded pilot must avoid owning leftover hardware after the grant ends. Why does a consumption-based public cloud fit that goal?
Select an answer to reveal the explanation.
Short Explanation
Think of renting festival tents instead of buying them. When the festival ends, you return the tents and the rental bill stops. Consumption-based cloud works the same way for a short pilot—you are not stuck storing hardware in a basement after the grant money is gone.
Full Explanation
A grant-funded pilot that must not leave behind owned hardware is a natural fit for consumption-based public cloud. The city provisions what the pilot needs, pays while those resources run, and when the grant ends it can stop using (and typically stop paying for) those services without a warehouse of servers to refresh, power, or dispose of. That eliminates leftover CapEx assets that outlive the funding window—the core goal stated for the pilot.
Saying public cloud always requires purchasing servers the city keeps after the grant closes contradicts the rental-like nature of metered cloud. Claiming consumption billing forces a five-year CapEx purchase of the same hardware the grant would have bought reverses CapEx and OpEx. Barring grant projects from cloud because consumption supposedly requires permanent ownership invents a restriction that is not part of the consumption model.
Exam caveat: deleting or deallocating resources stops ongoing compute charges, but retained disks, snapshots, or static public IPs can still cost money—shutdown of spend is not automatic if artifacts are left behind after the grant closes.
Operational check: before the grant end date, inventory the pilot resource group, delete or archive what is no longer needed, confirm no orphaned disks or unused IPs remain, and capture a final Cost Management snapshot so auditors see spend ended with the project rather than lingering as zombie resources.