FinOps Engineer interview questions

I would match each discount instrument to the stability and flexibility of the eligible hourly spend.

• Compute Savings Plans cover EC2 across families and Regions plus eligible Fargate and Lambda usage, so I would use them for the portable baseline.
• EC2 Instance Savings Plans offer a deeper discount but bind the commitment to an instance family in one Region, so they fit a stable regional fleet.
• Reserved Instances fit specific EC2 requirements, especially when a zonal RI's capacity reservation or Standard RI economics matter, but they do not cover Fargate or Lambda.

I would place the portable baseline at the payer level with a Compute Savings Plan and avoid binding the migrating product to one Region.

• I would estimate the organization's lowest recurring eligible spend, then commit only the portion that remains above $40 per hour in downside scenarios.
• Savings Plan benefits can apply across linked accounts when discount sharing is enabled, so account-level attribution must not be confused with benefit application.
• I would keep the migration-sensitive tail on demand until the destination and steady-state hourly rate are proven for several billing cycles.

I would reserve the stable VM shapes and use a savings plan for the compute baseline that changes series or Region.

• One-year or three-year Reservations fit predictable resource families and can use shared, subscription, resource-group, or management-group scope according to ownership.
• Azure Savings Plan for Compute commits an hourly amount and applies to eligible compute across supported services and Regions, which protects flexibility for the changing fleet.
• I would model utilization after existing discounts and leave burst spend uncovered, because overlapping commitments do not create double discounts.

I would evaluate resource-based CUDs for the stable Compute Engine shape and spend-based CUDs for eligible variable services.

• Resource-based CUDs commit to specified resources such as vCPU and memory in a Region, so the $55 baseline must be translated into a durable machine profile.
• Spend-based CUDs commit to an hourly spend for eligible services and can better fit Cloud Run or a changing compute mix.
• I would compare one-year and three-year terms against a downside forecast and verify eligibility, because on-demand dollars and committed dollars are not interchangeable across every SKU.

I would add effective savings rate because coverage and utilization alone do not show the net discount on total eligible cost.

• Coverage is discounted eligible usage divided by total eligible usage, while utilization is used commitment divided by purchased commitment.
• Effective savings rate is on-demand-equivalent cost minus net amortized cost, divided by on-demand-equivalent cost for the same usage.
• I would reconcile fees, unused commitment, credits, and shared benefits; 96 percent utilization can still produce weak savings if the committed rate barely beats alternatives.

I would buy the proven floor in staggered tranches and revisit the uncovered growth as evidence arrives.

• I might commit $70 per hour now, $25 after three months, and the final $25 after six months if utilization stays above 95 percent.
• Staggered start and expiry dates prevent the full $120 per hour from renewing on one forecast and create regular repricing decisions.
• Forecast growth would remain on demand until observed, because pre-buying the expected 25 percent turns an upside assumption into fixed downside risk.

I would buy the $100 per hour commitment under the stated scenario assumptions because even the downside remains profitable, subject to validating hourly usage shape and discount eligibility.

• A 28 percent discount sets the committed rate at $72 per hour, so break-even utilization is 72 percent of the $100 per hour baseline.
• If half the workload disappears after six months, annual use is 75 percent: $657,000 of on-demand-equivalent use minus $630,720 of commitment cost leaves $26,280 in savings.
• Probability-weighted savings are 80 percent of $245,280 plus 20 percent of $26,280, or $201,480; I would still verify eligible usage exists in each hour because an annual average can hide uncovered or unused hours.

I would first identify whether each RI is Standard or Convertible because the exit paths differ materially.

• Convertible RIs can be exchanged for other Convertible RIs under AWS value and term rules, but they cannot be sold on the RI Marketplace.
• Eligible Standard RIs can be listed on the Marketplace, subject to account, payment, remaining-term, and offering restrictions, and a buyer is not guaranteed.
• Savings Plans cannot be exchanged or resold, so I would not present the RI options as a general escape hatch for all commitments.

I would allow bounded automation only with purchase guardrails, an immediate kill switch, and a recovery path that reflects actual Savings Plans rules.

• Policy would cap net new commitment per week, exclude migration or shutdown scopes, require separate purchase authorization, and alert on each material portfolio change.
• For a $75-per-hour plan, automation must immediately check the limited return path: purchase within 7 days, in the same calendar month, hourly commitment no more than $100, and the account's return eligibility.
• Outside that window the plan cannot be exchanged or resold, so I would stop new buys and recover by applying remaining eligible demand where sharing and architecture permit.

I would rank workloads by interruption tolerance and start with stateless, retryable capacity rather than target 50 percent uniformly.

• CI workers, queue consumers, and checkpointed batch jobs can enter first because interruption loses minutes of work rather than customer sessions.
• Stateful databases, singleton controllers, and workloads with a 30-minute startup stay on demand unless their architecture changes.
• I would track Spot share, interruption rate, completion time, and net savings after retries so a nominal 50 percent target does not hide reliability cost.

I would diversify capacity and make jobs resumable so no single Spot pool controls completion.

• Karpenter would receive broad instance-family, size, and Availability Zone requirements instead of one preferred type with shallow capacity.
• Jobs would checkpoint every five minutes, honor interruption notices, and retry through the queue with idempotent output writes.
• I would keep a 20 percent on-demand floor or fallback NodePool and compare deadline misses against savings before increasing Spot share.

I would size from sustained high percentiles and required headroom, not from the 20 percent average.

• At p99 the service uses about 5.9 vCPU, so a 6-vCPU target has no operating margin and a 4-vCPU target is unsafe.
• I would test a 8-vCPU cheaper generation or scale-out shape first, then target roughly 20 percent headroom above p99 after load testing.
• Memory p99, throttling, latency, autoscaling delay, and seasonality must pass the same review before any instance reduction.

I would compare the all-in burstable cost with fixed-performance families and remove sustained workloads from unlimited bursting.

• CPU credit charges show that the fleet's baseline entitlement is below its sustained demand, even though the monthly average looks low.
• I would segment truly spiky services from steady workers, then benchmark M or C families for the steady segment.
• For retained T instances, I would alert on credit balance and surplus charges and verify that Standard mode would not throttle a latency-sensitive service.

I would optimize by access pattern and total lifecycle cost, then validate recovery requirements before moving data.

• Object lifecycle rules can transition the 180-day cohort to a colder tier, but retrieval fees, minimum duration, and restore delay belong in the model.
• For block storage, I would remove unattached volumes and stale snapshots, then right-size provisioned IOPS and throughput separately from capacity.
• I would pilot on one data class and measure storage, request, retrieval, and operational costs for 60 days before broad rollout.

I would decompose transfer by source, destination, path, and price class before changing architecture.

• Billing and flow data should separate cross-AZ, cross-Region, internet egress, NAT processing, CDN origin, and managed-service transfer.
• If chatty services now cross Availability Zones, request coalescing or topology-aware placement may save money without removing required redundancy.
• I would quantify bytes avoided and latency or resilience impact; moving everything into one zone can reduce cost while creating a larger failure risk.

I would separate database infrastructure, edition, and license rights because compute rightsizing alone addresses less than half the bill.

• I would verify core counts, edition features, passive failover rights, and whether existing licenses can use Azure Hybrid Benefit or AWS License Mobility where eligible.
• Query and memory profiling may allow fewer licensed cores, while moving from Enterprise to Standard requires proving that no required feature is lost.
• A managed open-source migration could reduce licenses, but I would include engineering effort, downtime risk, and dual-run cost in the business case.

I would rank recommendations by realizable net value, confidence, effort, and service risk rather than raw annualized savings.

• A practical score can multiply verified monthly savings by confidence and expected persistence, then subtract implementation and transition cost.
• I would raise priority for idle resources with an owner and rollback path, and lower it for production rightsizing based on seven days of data.
• The queue would show owner, dependency, due date, accepted risk, and realized savings so recommendations become accountable work rather than dashboard inventory.

I would define one stable hierarchy from legal payer to business unit, product, team, environment, and resource.

• Account, subscription, or project ownership provides the first deterministic boundary before tags and Kubernetes metadata fill lower levels.
• Each product and team needs a versioned identifier rather than a display name so reorganizations do not rewrite historical cost.
• Unallocated cost remains visible in a dedicated bucket with an owner and target, rather than being silently spread across products.

I would split the platform into cost pools and assign each pool the driver that best represents consumption.

• Build workers could use runner minutes, observability could use ingested GB, and an API gateway could use request count or processed bytes.
• A fixed platform baseline can follow agreed capacity or product revenue only if the report labels it as a policy allocation rather than measured use.
• For each pool, allocated cost dollars plus an explicit unallocated residual must equal that source pool; all pools together must equal $420,000, while driver units reconcile separately to their metering source, not to bill dollars.

I would allocate variable network cost from metered bytes and keep fixed attachment charges in a separate shared pool.

• NAT processing maps to source account or workload bytes, transit processing maps to attachment and direction, and inter-Region transfer maps to both endpoints.
• Fixed gateway hourly charges can follow connected accounts or reserved capacity, because byte-only allocation would leave idle attachments free.
• Flow logs must be sampled and reconciled to billed GB, with unknown traffic retained as an explicit network-unallocated line.