TL;DR: Start with the bill and identify the largest controllable costs. Verify ownership and retention before deleting idle resources, right-size from measured demand, then choose purchasing instruments for the remaining workload. Quantify risk and savings for each proposal.
How to approach it
Open by asking what the top line items are and whether cost is allocated to teams. Both answers change the whole plan. Then give an ordered method, not a menu, and estimate each stage from the actual bill and state the assumptions.
A strong answer
Group the bill by service, account and owner, then rank costs by potential savings and implementation risk. Measure concentration in this estate instead of assuming three items dominate. Use tags, account boundaries and usage records to attribute costs; keep an explicit unallocated category while repairing missing ownership.
Then four stages in order, cheapest first.
Waste review. Inventory unattached volumes, idle load balancers, old snapshots and temporary environments. An unattached volume may hold recovery data and a snapshot may satisfy retention requirements. Confirm ownership, dependencies and restore needs, obtain the required approval, and use a reversible quarantine where practical before deletion. Estimate savings from the reviewed inventory.
Right-sizing. Compare provisioned to actual utilisation. The characteristic finding is instances at 5 to 10 percent CPU because someone sized for a peak that never arrived, and Kubernetes requests set to a round number that nobody revisited. On Kubernetes the specific lever is requests, since requests drive scheduling and therefore node count, and inflated requests can prevent efficient scheduling. The achievable node reduction also depends on topology, failover headroom and disruption constraints. Karpenter or an equivalent consolidating provisioner turns right-sized requests into fewer, better-packed nodes automatically.
Purchase model. Only now, because committing to the wrong shape is expensive. Savings Plans or reserved instances against the stable baseline, spot for anything interruptible such as batch, CI runners and stateless workers. The discipline is to commit to the trough, never the peak, and to compare commitment scenarios against a downside forecast and retained flexibility.
Architecture. Storage lifecycle policies, cross-AZ traffic that could stay in-zone, an over-provisioned managed database, a data pipeline that reprocesses everything nightly when it could be incremental. This has the largest ceiling and the longest lead time, so it is a roadmap item rather than a quarter-end action.
Then the part most candidates omit: keep it from coming back. Cost anomaly alerts, a per-team showback that lands in a channel the team reads, and a budget check in the pull request for infrastructure changes. Without that, everything above is a one-off saving that can erode as resources and ownership change.
What interviewers probe next
"How do you decide between spot and committed capacity?" By interruption tolerance, not by price. Anything that can be drained and restarted goes to spot. Stateful workloads need a replication, quorum and recovery analysis; the presence of state alone does not rule out interruptible replicas.
"A team refuses to right-size because they are afraid of an incident." Give them the data and the safety net: show measured p99 utilisation over a full cycle, change one service, watch it, and let them keep a documented revert. Fear here is usually reasonable and is answered with evidence, not with mandate.
"What is the risk of over-committing?" You lock in a shape you outgrow or shrink out of, and the commitment then costs you the flexibility to migrate. Choose coverage from utilization and downside scenarios, not a universal percentage.
Common mistakes
Opening with a list of tactics. The first move is finding out where the money is, and an interviewer notices immediately if you skip it.
Starting with the purchase model because it is the biggest single percentage. Committing before right-sizing locks in your current waste.
Ignoring allocation. Untagged spend means no owner, and no owner means the savings do not stick.
Treating this as a technical problem only. The durable version of this work is a reporting loop and a habit, not a one-quarter cleanup.