Diagnosing and Preventing Idle or Underused VMs for a Google Cloud Customer Segment

You are a product manager on Google Cloud. You notice that one group of customers has virtual machines that run at very low utilization, and some of their VMs appear not to be used at all. Explain how you would find the root cause, how you would fix the problem, and how you would make sure it does not happen again. ### Clarifying Questions - How is low utilization measured today: low average CPU and memory on VMs that are running, VMs that run but serve no traffic, or capacity that was reserved or created and never used? - What do we already know about the affected group, such as account size, region, machine type, pricing model, or how the VMs were created? - Is this a recent change, or a long-standing pattern that someone has only now noticed? - Why does it worry us: customers paying for capacity they do not use, trial or credit-funded VMs taking capacity Google pays for, or both? ### Part 1 — Find the root cause Describe how you would go from the observation to a confirmed root cause: which data you would pull, how you would segment it, and how you would separate competing explanations. ```hint Trust the number first Before explaining why these customers behave this way, ask whether the utilization measurement itself could be misleading, then look for what the affected customers share that others do not. ``` #### What This Part Should Cover - Validating the signal, including how utilization is measured and which kinds of legitimate work look idle. - Sizing the problem and comparing affected customers with similar unaffected ones, by attribute and by time. - A structured set of hypotheses, each paired with the evidence that would confirm or rule it out. ### Part 2 — Solve the issue Once the cause is known, explain how you would fix it for the customers affected today, who you would involve, and how you would know the fix worked. ```hint Weigh who pays Idle VMs can cost the customer money while adding to Google's revenue. Think about trust as well as revenue before choosing between alerts, recommendations and automatic actions. ``` #### What This Part Should Cover - Fixes tied to the confirmed cause rather than a generic list. - How customers are told, and what control they keep over their own machines. - Success metrics and guardrails, including how the revenue impact is measured. ### Part 3 — Prevent it from happening again Explain what you would put in place so this does not recur, whether for this group or a new one. ```hint Catch it and stop it Consider both how you would spot the next case early and what you would change in the product so the waste is less likely to start. ``` #### What This Part Should Cover - An ongoing metric with thresholds, alerts and a named owner. - Product guardrails in defaults, provisioning flows or resource lifecycle. - A process that checks new templates or defaults after launch. ### What a Strong Answer Covers - A precise definition of underutilization that separates oversized running VMs from idle or never-used ones. - An evidence-driven root-cause process instead of a list of guesses. - Clear reasoning about why low utilization matters to the customer and to Google, and how that shapes the fix. - Fixes and prevention that follow from the cause, with metrics, guardrails and an owner. ### Follow-up Questions - You find that most idle VMs come from a getting-started flow that creates a large machine by default. Shrinking the default would lower revenue from new accounts. How do you decide? - A finance partner argues that idle VMs are profitable and should be left alone. How do you respond? - How would you tell a VM that is idle on purpose, such as a standby or disaster-recovery machine, from one that is wasted?