5 exercises — practise answering Serverless Cost Engineer interview questions in professional technical English.
0 / 5 completed
1 / 5
The interviewer asks: "A serverless application's monthly cloud bill tripled after a traffic increase that only doubled request volume. How would you investigate this?" Which answer best demonstrates Serverless Cost Engineer expertise?
Option B is strongest because it decomposes the bill by function and resource dimension, checks specific known causes of cost-traffic mismatch, and correlates against deploy history to root-cause the actual driver. Option A assumes an external cause without first checking internal usage patterns, which is almost always where the answer lies. Option C risks under-provisioning functions that genuinely need the memory, causing timeouts or throttling. Option D is a drastic, costly migration attempted before diagnosing whether the actual issue is fixable within the serverless model.
2 / 5
The interviewer asks: "How do you decide the right memory allocation for a Lambda function, given that memory also affects CPU and therefore execution duration?" Which answer best demonstrates Serverless Cost Engineer expertise?
Option B is strongest because it uses empirical power-tuning to find the actual cost-minimising point on the memory-duration curve, correctly distinguishing CPU-bound from I/O-bound functions rather than applying a blanket rule. Option A ignores that maximum memory is rarely the cost optimum, especially for I/O-bound functions. Option C ignores that under-provisioning CPU-bound functions can increase duration enough to raise total cost despite lower per-millisecond rate. Option D never optimises at all and leaves cost to accident of initial configuration.
3 / 5
The interviewer asks: "Engineering leadership wants a real-time view of serverless spend attributed to individual teams and features, not just a monthly cloud bill total. How would you build this?" Which answer best demonstrates Serverless Cost Engineer expertise?
Option B is strongest because it enforces tagging at deploy time via IaC policy, builds a near-real-time attribution pipeline, and scopes anomaly alerts per team with CI-enforced tagging compliance. Option A produces an inaccurate approximation with no relationship to actual usage. Option C is an unreliable, unverifiable self-reported estimate. Option D provides far too infrequent visibility for the real-time need leadership described.
4 / 5
The interviewer asks: "A team wants to use provisioned concurrency to eliminate cold starts on a customer-facing function, but that adds a fixed cost even during idle periods. How do you help them decide if it's worth it?" Which answer best demonstrates Serverless Cost Engineer expertise?
Option B is strongest because it quantifies both the actual cold-start business impact and the real cost delta at the function's traffic pattern, and proposes scheduled scaling to capture the benefit at lower cost where traffic is predictable. Option A dismisses a legitimate use case without evaluating impact. Option C approves added fixed cost without verifying the problem is significant enough to justify it. Option D jumps to a much larger architectural change without first evaluating the simpler, purpose-built serverless feature.
5 / 5
The interviewer asks: "How would you prevent a runaway serverless cost incident, like an infinite retry loop or a misconfigured recursive trigger, from causing a massive unexpected bill before anyone notices?" Which answer best demonstrates Serverless Cost Engineer expertise?
Option B is strongest because it layers concurrency limits, bounded dead-letter retries, tight-window billing anomaly alerts tied to on-call, and explicit circuit breakers for high-risk recursive patterns — proactive controls, not reactive monitoring. Option A checks far too infrequently to prevent significant cost accrual within a runaway incident. Option C relies on passive human attention, which is exactly the gap that causes real cost incidents. Option D removes retries entirely, which harms legitimate transient-failure recovery instead of addressing the specific runaway-loop risk with a bounded limit.