Free lesson · AWS for System Design Interviews

When cloud-specific answers are expected, and when they are penalised

Easy8 min readawssystem-designinterview-preparation

The Question Has A One-Sentence Answer

Ask.

"Should I assume a specific cloud provider, or design this in general terms?"

Fifteen words, asked in the first two minutes, and it resolves the entire question. It also signals that you know the two modes exist and that the answer differs - which is itself a small positive.

Most candidates never ask and guess for forty-five minutes.

Tip: The answer you get is usually more informative than the words alone.

"Assume AWS" - specificity is welcome, and the interviewer likely works in it daily.

"Design it generally" - primitives, and product names will be noise.

"Whatever you're comfortable with" - the most common answer, and it means the design is being assessed, not the vocabulary. Use primitives, mention services as asides, and let their reaction guide you.

"How would you do it on AWS?" - this is not the same question. They want the specific answer, and retreating into primitives now reads as evasion.

Ask once, early, and then stop thinking about it.

When Specificity Is Expected

Situation	Because
The interviewer asked directly	A direct question deserves a direct answer
The role is cloud-specific	The job description names it; the skill is being tested
The company is visibly AWS-native	Their engineering blog, their job posts, their conference talks
You are asked to optimise cost	Requires real pricing models
You are asked about operational burden	Requires real managed capabilities
The question is about a service's behaviour	The service is the subject
You raised a service and were probed	You opened it; answer it

Cost and operations are the two categories where neutrality actively fails. "It would be cheaper to cache" is not an answer; the cost of the cache versus the database reads it saves depends on actual pricing structures. Vagueness here reads as never having owned a bill.

When It Is Penalised

Situation	Because
The company runs its own infrastructure	Google, Meta, Netflix in large part, most large banks
The interviewer is testing fundamentals	The service name skips what is being assessed
It substitutes for reasoning	Module 01 Topic 1, in every context
You are wrong about the service	Worse than never naming it
You use it as a credential	"At my last company we used…" as an argument
A multi-cloud or on-prem constraint was stated	You were told and did not listen

Warning: The most damaging version is confident inaccuracy about a service you named, and it is entirely self-inflicted.

Stating that DynamoDB supports strong reads on a GSI, or that SNS retains messages, or that Aurora scales writes horizontally - each is a specific, checkable error, delivered with certainty, about something nobody made you say.

The inference an interviewer draws is not "they misremembered a detail." It is "they speak confidently about things they have not verified" - which is a much larger conclusion and it colours everything else in the interview.

The asymmetry is stark: naming a service correctly is a small positive; naming one incorrectly is a large negative. If you are unsure, describe the primitive and say you would verify the specifics. That is a stronger position than a confident guess, always.

Reading The Company

graph TD
    C{What does the<br/>company run?} --> A[**Cloud-native**<br/>startups, most SaaS,<br/>modern enterprise]
    C --> H[**Hybrid**<br/>large enterprise,<br/>finance, retail]
    C --> O[**Own infrastructure**<br/>Google, Meta,<br/>large parts of Netflix]
    A --> A1[Specifics welcome.<br/>**Still lead with<br/>the primitive.**]
    H --> H1[Primitives, with<br/>specifics offered.<br/>**Migration context<br/>often relevant.**]
    O --> O1[**Primitives only.**<br/>Service names are<br/>a foreign vocabulary.]

This diagram shows how to read a company's infrastructure position. Cloud-native companies - startups, most SaaS, modern enterprise - welcome specifics, though you should still lead with the primitive. Hybrid companies such as large enterprises, finance, and retail want primitives with specifics offered, and migration context is often relevant. Companies running their own infrastructure, such as Google, Meta, and large parts of Netflix, want primitives only, because service names are a foreign vocabulary there.

Research this before the interview. The engineering blog, the job description's stated stack, and public conference talks establish it in fifteen minutes.

And note the asymmetry: primitives are safe everywhere. At an AWS-native company, leading with the primitive costs you nothing and gains the depth signal. At an infrastructure company, leading with the service name costs you real ground. The expected value points one direction.

The Two-Layer Answer

The format that works regardless of which situation you are in.

Layer one: the primitive and its guarantees. "I need a durable queue between the API and the workers so bursts are absorbed and processing failures do not lose requests. At-least-once, so consumers must be idempotent."

Layer two, as an aside: "On AWS that's SQS, with a dead-letter queue for poison messages."

Important: The two-layer answer costs about five seconds and it is correct in every situation this topic describes.

At a general-vocabulary company, layer one is the answer and layer two is a harmless demonstration that you can implement it.

At an AWS-native company, layer one earns the depth signal and layer two confirms the practical knowledge.

If the interviewer wants more specificity, they will pull on layer two. If they want less, they will engage with layer one and ignore the rest. You have given them the choice rather than guessing at it, which is the entire point.

This is also the format that survives being wrong. If your layer-two claim about the service is inaccurate, layer one still stands - the design is correct and the implementation detail is corrigible. A candidate who only offered layer two has nothing left when the detail is wrong.

The Interviewer's Own Background

A factor most candidates never consider, and it shifts the register more than the company does.

An interviewer who has spent a decade on internal infrastructure may know AWS only in outline. Service names land as unfamiliar vocabulary, and - more importantly - they cannot evaluate whether your service-level claims are correct, so those claims produce no signal at all. Everything you say in that register is wasted.

An interviewer who runs AWS daily will evaluate your specifics closely, which cuts both ways: accurate specifics land well, and an error is caught immediately.

You usually cannot know which you have. The signals available are their questions - an interviewer probing the mechanics of replication and quorum is thinking in primitives; one asking about managed service behaviour is thinking in services.

Tip: This is another argument for primitive-first, and it is the strongest one: the primitive register is legible to both interviewers, and the service register is legible to only one.

A design expressed in primitives is evaluable by an infrastructure engineer and an AWS specialist alike. A design expressed in service names is only evaluable by the specialist - the other interviewer cannot assess it and will default to what they can assess, which is whatever reasoning you showed.

You do not need to identify which interviewer you have if your default register works for both.

The Mode Can Change Mid-Interview

Interviewers move between registers, and the signals are usually explicit.

Toward specificity: "how would you actually build this?", "what would you use for that?", "what does that cost?" - follow them in.

Toward fundamentals: "forget the tooling for a moment", "how does that work underneath?", "what if that service didn't exist?" - drop the product names entirely.

The last one is a direct test. "What if DynamoDB didn't exist - how would you build this?" is asking whether you understand the primitive. The answer is the sketch from Module 01 Topic 2, and a candidate who cannot give it has just revealed that the service name was doing all the work.

Migration And Hybrid Framing

A register that appears frequently in enterprise interviews and catches candidates who prepared only for greenfield.

Many system design questions at large companies are implicitly migration questions. The system does not exist in isolation; it must work alongside something that already exists, often on premises, often for years.

The signals: "we have an existing system that does X", "this needs to integrate with our data warehouse", "we're moving off a monolith", or a stated constraint about an existing database.

What changes: the coexistence period becomes part of the design, the integration boundary matters more than the greenfield architecture, and a migration path is part of the answer rather than an afterthought. A design that is correct as an endpoint and impossible to reach from where they are is not a usable answer.

The strong move is to ask about the existing estate early - "is there an existing system this replaces or coexists with?" - because the answer frequently reframes the entire question, and discovering it at minute thirty is expensive.

When You Do Not Know The Service

It happens, and the recovery is straightforward.

Say what you need and be explicit about the gap: "I need a managed service that does X. I believe AWS has something for this - I'd check what fits rather than guess at the name."

That is a genuinely acceptable answer. Nobody knows the entire catalogue and the catalogue changes constantly. The failure is guessing confidently.

The same applies to limits and pricing. "There's a per-partition throughput ceiling - I'd verify the current number, and the design consequence is that the key must distribute" is stronger than any figure you half-remember.

Common Failure Modes

Warning: Never asking which mode applies. Guessing for forty-five minutes.

Confidently wrong about a named service. The most damaging error here.

AWS vocabulary at an infrastructure company.

Retreating into primitives when specifics were requested. Evasion.

Vagueness on cost or operations. Reads as never having owned a bill.

Missing the shift to fundamentals. "How does that work underneath?"

Unable to answer "what if that service didn't exist?"

Experience used as an argument rather than as evidence.

Company not researched. Fifteen minutes of preparation.

A stated constraint ignored. You were told.

Why This Matters In An Interview

Interview: What interviewers are listening for:

Asking which mode applies, early and once.

The two-layer answer as a default.

Acknowledging uncertainty rather than guessing.

Following the interviewer's register shifts.

Common follow-ups:

"Should I assume AWS?" - asked by you. → Whatever the answer, it costs nothing and demonstrates you know the modes differ.

"What if that service did not exist?" → A direct test of the primitive. Sketch it: partitioning, replication, consistency, and where it breaks. If the service name was doing the work, this is where it shows.

"How much would this cost?" → Reason in ratios rather than prices: what dominates, what scales with what, and what the largest lever is. Vagueness here is worse than an approximate answer.

"You said SNS retains messages - does it?" → Correct yourself immediately and cleanly. It does not; a subscribing queue provides retention. Recovering well costs far less than defending the error.

Practice

Exercise: Starter. For three companies you would interview with, determine from public sources whether they are cloud-native, hybrid, or run their own infrastructure.

Intermediate. Deliver one design in the two-layer format throughout. Notice how often layer two turns out to be unnecessary.

Advanced. Have someone ask "what if that service did not exist?" at every service you name. Each one you cannot answer is a service name doing work your understanding is not.