SAP Platform Engineering & FinOps interview questions

A platform question that is really a product question. The design is the easy half; the answer that scores explains how you would know developers chose it rather than were forced onto it.

A shared cluster produces one bill and no answer. Attribution is a measurement problem first and a cultural one second, and the number that changes behaviour is not the one finance asked for.

The tool emits recommendations; the programme is everything around it. Interviewers use this question to see whether you can turn a dashboard into landed changes without breaking production or trust.

Registration coverage tells you a script ran. It says nothing about whether an engineer has ever found the portal worth opening.

Forty minutes is a symptom with at least four different causes, and three of them are cheaper to fix than moving everyone's development to a remote machine.

Support demand grows with teams multiplied by surface area, and headcount does not. The only durable lever is removing the reason people ask.

Saying yes without a contribution contract produces features the platform team did not design and now supports forever, on call, at 3am.

Every capability a platform accepts is a permanent operational commitment. Teams that cannot say no end up operating six things badly instead of two things well.

The discount is real and so is the option you are selling. The question is what your usage looks like in year three, and the honest answer for most teams is that they do not know.

A question about method, not about tactics. Candidates who open with a list of levers lose to candidates who open with one question about the bill itself.

The difference between scaling node groups and provisioning nodes is the whole answer. One picks from shapes you defined in advance; the other reads the pending pods and buys what they need.

Four purchase instruments, one fleet, and a finance team asking why you did not commit to everything at maximum discount. The scoring rubric rewards the arithmetic of being wrong, not the discount table.

Everyone quotes the discount. Fewer candidates can describe what happens when a notice arrives late or a worker disappears without completing shutdown and why some workloads shrug it off while others lose hours of compute.

Percentage savings make every quarter look like a win and tell you almost nothing. A denominator tied to revenue is the one that survives scrutiny, because it is the only one a finance conversation can act on.

Most tagging initiatives are spring cleans that rot within two quarters. The durable answer treats the schema like an API contract enforced where resources are born, and knows which lever actually wins.

Data transfer appears on nobody's architecture diagram and reliably appears on the invoice. The strong answer enumerates the taxed flows, ranks the levers, and knows which tax is worth paying.

Over-requested CPU and memory can prevent efficient node packing. Cutting them safely is a measurement problem with a reliability trap sitting in the middle of it.

Pay-per-use sounds free until the invoice arrives. The useful method is to decompose the bill into invocations, gigabyte-seconds and the lines nobody models, then locate the honest crossover rather than arguing about it.

Most of your rows are read rarely and cost the same as the ones read constantly. Tiering pays for itself only when access patterns are honest, which is why the audit comes before the architecture.

The licence fee is visible and the engineering time is not, so omitting internal effort can make building look artificially cheap. The fix is pricing internal effort honestly, including its maintenance tail.

Central teams optimise well and get ignored; federated teams own outcomes and drown in tooling. The mature answer is a hub-and-spoke split by decision type, and the interview tests whether you can say exactly who decides what.

Token spend has no natural ceiling. Every retry, every retrieved document, every chain step multiplies, and nothing in the system tells anyone until the invoice arrives.

An upfront purchase, a refund and two currencies can produce several valid totals. Work out which total finance needs, then prove every adjustment from the source rows.