5 exercises — choose the best-structured answer covering cloud cost attribution, showback/chargeback, Reserved Instances, Savings Plans, and optimisation strategies.
Structure for FinOps Analyst answers
Tip 1: Know the FinOps lifecycle phases: Inform (visibility) → Optimise (right-sizing, commitments) → Operate (governance, culture)
Tip 2: Distinguish showback (informational cost reports to teams) vs chargeback (actual cost allocation to business units)
Tip 3: Name commitment discount types: AWS Reserved Instances (1/3yr, Standard/Convertible), Savings Plans (Compute/EC2/SageMaker), GCP CUDs
Tip 4: Know unit economics metrics: cost per customer, cost per API call, cost per GB processed — connect cloud spend to business value
0 / 5 completed
1 / 5
The interviewer asks: "What is the FinOps lifecycle and what does each phase involve?" Which answer best demonstrates FinOps framework knowledge?
Option B correctly names all three FinOps Foundation phases with concrete activities in each. Key structure: Inform (tagging + visibility + unit economics) → Optimise (right-sizing + commitments + auto-scaling) → Operate (culture + alerting + budgets + champions) → iterative cycle. Option A describes only ad-hoc cost management. Option C reduces FinOps to three tactical actions. Option D describes a generic budget cycle, not the FinOps framework.
2 / 5
The interviewer asks: "What is the difference between showback and chargeback, and when would you implement each?" Which answer best demonstrates FinOps cost allocation maturity?
Option B precisely distinguishes the financial mechanism difference, gives the sequencing recommendation, and addresses shared cost allocation. Key structure: showback = informational (no P&L transfer) → build culture + tagging quality → chargeback = P&L transfer → requires tagging completeness + finance integration → shared cost proportional allocation. Option A is vague. Option C presents a false size-based rule. Option D incorrectly equates chargeback with customer billing.
3 / 5
The interviewer asks: "Explain the difference between AWS Reserved Instances and Savings Plans. When would you recommend each?" Which answer best demonstrates commitment discount expertise?
Option B explains the commitment dimensions, compares Standard vs Convertible RIs, explains Compute vs EC2 Savings Plans flexibility, and gives a recommendation framework. Key structure: RIs: family/size/OS/region lock → Standard (no exchange) vs Convertible → best for stable workloads; Compute SP: any EC2/Fargate/Lambda → maximum flexibility → baseline; Standard RI → databases; 70% baseline rule; coverage rate + effective savings rate metrics. Option A is partially correct but incomplete. Option C is an oversimplification. Option D focuses only on payment model, missing the flexibility dimension.
4 / 5
The interviewer asks: "How do you handle cloud cost anomaly detection and alerting?" Which answer best demonstrates FinOps operational maturity?
Option B is strongest — it implements anomaly detection at the service level (ML-based), budget level (multi-threshold), operational level (daily digest), governance level (tag coverage), and commitment level (utilisation). Key structure: AWS Cost Anomaly Detection (ML) → budget alerts (50/80/100/120%) → daily Slack digest → tag coverage alerts → RI/SP utilisation alerts → weekly engineering review + Jira tickets. Option A is a single-layer, reactive alert. Option C conflates infrastructure monitoring with cost monitoring. Option D is fully manual and does not scale.
5 / 5
The interviewer asks: "What is unit economics in the context of FinOps and how do you calculate cost per customer?" Which answer best demonstrates business-value-driven cloud finance?
Option B defines unit economics correctly (business output, not infrastructure units), gives a calculation methodology, names data sources (CUR, BigQuery billing), and connects to CFO-level metrics. Key structure: cloud spend / business output metric → tag by product → shared cost allocation → CUR/BigQuery → cost per customer/API call/GB → % of revenue trend → cloud efficiency as competitive moat. Option A defines per-server cost (infrastructure unit, not business unit). Option C is the same infrastructure-unit error. Option D is a per-headcount metric (useful but not unit economics).