Finance wants you to buy a three-year Savings Plan to cut the cloud bill. Walk me through how you'd reason about committing versus the risk of locking in spend.
technical-conceptual · Senior level · cloud-devops-security
What the interviewer is really asking
Probes whether the candidate understands the FinOps order of operations — eliminate waste and right-size before committing — the coverage/utilization trade-off, the term-length risk against an evolving workload, and where spot fits, rather than treating a commitment as a free discount.
What to say
- Insist on order of operations: right-size and eliminate idle resources first, because a commitment locks in your current footprint, and committing on top of waste just buys the waste at a discount.
- Reason about the coverage/utilization trade-off: cover only the stable baseline you're confident you'll run, since an under-utilized commitment can cost more than on-demand — so I'd commit conservatively to the floor and leave the variable top layer on-demand or spot.
- Match the instrument to the workload risk: shorter terms or flexible Compute Savings Plans for an evolving stack, longer/standard for a genuinely stable baseline, and spot for interruption-tolerant batch — and revisit coverage as usage shifts.
What to avoid
- Treating the commitment as a no-downside discount and committing to peak or total spend, which leaves you paying for capacity you don't use if the workload shrinks or migrates.
- Committing before right-sizing, so you lock in the over-provisioned footprint you should have shrunk first.
- Ignoring term-length risk — a three-year lock-in against a platform that may re-architect or move off those instance families is a real liability, not just savings.
Example answers
Strong: I'd push back on committing first. The order that works is right-size and kill idle resources, then commit, because a Savings Plan freezes your current footprint and committing on top of waste just discounts the waste. Then I'd cover only the baseline I'm confident we'll keep running — under-utilized commitments can cost more than on-demand — and leave the variable layer on-demand or spot. For a stack that might re-architect in three years I'd lean to a one-year or flexible Compute plan over a three-year lock, and I'd treat coverage as something we revisit, not set once.
Weak: Three years gives the biggest discount, so I'd commit to cover most of our current spend and lock in the savings up front. It's a guaranteed reduction on the bill, so the longer and bigger the commitment the better the deal for us.