All jobs / Solutions / cloud architect

Cloud Cost interview questions

Cloud Cost questions a Solutions / cloud architect can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. A developer wants to keep three full copies of production running for testing. What is the first thing you raise?

    The strongest answer: What each copy is for and whether a smaller or on-demand environment answers the same question — cost is a requirement like any other

    Why it works: Exactly. Purpose first, then size to purpose. Idle full-size copies are a bill with no user.

    • Ask what each environment is for.
    • Size and schedule to the purpose.
    • Cost is a requirement.
    • Idle copies are pure waste.
  2. Traffic is heavy from nine to six on weekdays and near zero at night. How does the architecture turn that into a smaller bill?

    The strongest answer: Make the services stateless and quick to start so they scale in on load with a small floor, switch non-production off outside working hours, and move batch work to the quiet hours

    Why it works: Exactly — a daily pattern is the easiest saving there is, if the services can scale and non-production can sleep.

    • Follow the daily curve.
    • Stateless, fast start, small floor.
    • Non-production sleeps at night.
    • Batch work in quiet hours.
  3. How do you right-size compute for a service that has been running for a month?

    The strongest answer: Look at actual utilisation at peak and average, keep headroom for growth and bursts, then step down in small increments while watching latency — and revisit on a schedule

    Why it works: Exactly. Data, headroom, small steps, watch the user-facing signal, repeat.

    • Measure peak and average.
    • Keep headroom for bursts.
    • Step down while watching latency.
    • Review on a schedule.
  4. When does committing to reserved or discounted capacity make sense versus paying on demand?

    The strongest answer: Commit for the steady baseline you are confident you will run for the term; stay on demand or spot for the variable part — and revisit the split as the workload changes

    Why it works: Exactly. Baseline committed, variable flexible, reviewed.

    • Commit to the confident baseline.
    • Flexible pricing for the variable part.
    • Match the term to your confidence.
    • Revisit as the workload moves.
  5. The finance team forwards a cloud invoice that is much higher than last month, with no new servers added.

    The cloud bill jumped after a new analytics integration. Where do you look first?

    The strongest answer: Data transfer — cross-region, cross-zone and out to the internet — because moving data is billed separately from storing it and integrations that copy data are the usual cause

    Why it works: Exactly. Egress and cross-boundary transfer are the line items people forget to model.

    • Look at data transfer first.
    • Cross-region and internet egress cost.
    • Copying data has a price.
    • Model transfer before you integrate.
  6. The RTO agreed with the business is four hours; the next test restore from the archive tier is scheduled for next week.

    Backups were moved to the cheapest archive storage tier and the bill fell. What did you just change about disaster recovery?

    The strongest answer: Archive tiers take hours to retrieve and charge for retrieval, so the recovery time objective may no longer be achievable — keep recent backups in a fast tier, archive only the older ones, and test a restore from the archive

    Why it works: Right — a storage tier trades retrieval time and cost against price; the RTO must still hold.

    • Tiers trade retrieval time for price.
    • Recent backups stay fast.
    • Archive the old ones.
    • Test a restore against the RTO.
  7. How do you estimate the running cost of a proposed design before it is built?

    The strongest answer: Model the main cost drivers — compute hours, storage, data transfer, managed-service units — from the capacity estimate, state the assumptions, compare two or three variants, and plan to check the model against the first real bill

    Why it works: Exactly. Drivers, assumptions, variants, and a check against reality.

    • Model the main drivers.
    • State the assumptions.
    • Compare variants.
    • Check against the first bill.
  8. Cloud spend is growing faster than revenue and nobody owns it. What do you set up?

    The strongest answer: Tagging and allocation so every cost has an owning team, budgets with alerts per team, a regular review of the biggest lines with the engineers who can change them, and architecture standards for the recurring wastes

    Why it works: Exactly. Ownership, budgets, regular engineering review, standards. A system, not an event.

    • Every cost has an owner.
    • Budgets and alerts per team.
    • Regular review with engineers.
    • Standards for recurring waste.
  9. How do you connect architecture decisions to the business’s unit economics?

    The strongest answer: Express infrastructure cost per unit the business sells — per order, per active user, per tenant — track it over time, and use it to judge designs: a change that lowers cost per unit at scale can justify complexity that a small system should not carry

    Why it works: Exactly. Cost per unit is the bridge between architecture and the business model.

    • Cost per business unit.
    • Track it over time.
    • Judge designs against it.
    • Complexity earns its place through the unit.