What Cloud Interviews Test That Certifications Do Not

A certification asks “which service provides managed message queuing?”. An interview asks “this queue is backing up at 40,000 messages a second and costing $9,000 a month — what do you do?”. Preparing for the first does not prepare you for the second.

What is actually being scored

1. SIZING          Can you turn "10,000 users" into requests per second,
                   gigabytes stored, and instances needed — with the arithmetic
                   visible?

2. COST            Do you know roughly what things cost, and which line item
                   dominates? Egress and idle compute are the two that surprise
                   people in production.

3. FAILURE         For each component: what happens when it dies, who notices,
                   and how long until it recovers?

4. TRADEOFFS       Did you name what you gave up? Every design choice costs
                   something — an answer with no downside stated is incomplete.

5. OPERABILITY     How is it deployed, monitored, and rolled back? A design that
                   cannot be operated is not a design.

Certification study covers none of these. It is not wasted — it gives you the vocabulary — but the round is a different exercise.

Set up the substrate

Two tools. The AWS CLI for real API output, and Python for the arithmetic that every answer in this track rests on.

aws --version
python --version

$ aws --version
aws-cli/2.31.6 Python/3.13.9 source/x86_64

$ python --version
Python 3.13.2

You do not need an AWS account for most of this track. Where an account would be needed, the output is shown so you can read it. For hands-on practice without a bill, LocalStack emulates the common services:

pip install localstack awscli-local
localstack start -d
awslocal s3 mb s3://interview-practice
awslocal s3 ls

$ awslocal s3 ls
2026-09-10 11:42:18 interview-practice

Sizing: the arithmetic they want to see

The question is never “how many servers”. It is a chain of estimates, and showing the chain is the answer.

# sizing.py
DAU = 10_000_000            # daily active users
ACTIONS_PER_USER = 20       # requests each, per day
PEAK_MULTIPLIER = 3         # peak is ~3x the daily average
SECONDS_PER_DAY = 86_400

daily_requests = DAU * ACTIONS_PER_USER
avg_rps = daily_requests / SECONDS_PER_DAY
peak_rps = avg_rps * PEAK_MULTIPLIER

RPS_PER_INSTANCE = 500      # measured, not guessed — see note below
instances_needed = peak_rps / RPS_PER_INSTANCE

print(f"daily requests   {daily_requests:>15,}")
print(f"average RPS      {avg_rps:>15,.0f}")
print(f"peak RPS         {peak_rps:>15,.0f}")
print(f"instances @ {RPS_PER_INSTANCE}/s  {instances_needed:>12,.0f}")
print(f"with N+2 spare   {instances_needed + 2:>15,.0f}")

$ python sizing.py
daily requests       200,000,000
average RPS                2,315
peak RPS                   6,944
instances @ 500/s             14
with N+2 spare                16

Four numbers, each derived from the one above it. The interviewer can challenge any step, and that is the point — an answer of “about fifteen instances” with no chain cannot be examined.

RPS_PER_INSTANCE is the one to flag. It is the number you do not know:

“500 requests per second per instance is a placeholder. In practice I’d load test one instance and measure it, because it depends entirely on what the request does — a cache read might be 5,000, a request that hits the database and renders a template might be 50. That single number moves the answer by two orders of magnitude, so I’d want it measured before committing.”

Cost: the arithmetic that decides designs

# cost.py
GB = 1
TB = 1024

# on-demand list prices, US East, as of publication — verify before quoting
PRICES = {
    "compute_hour":       0.0832,   # m7g.large, per hour
    "storage_gb_month":   0.023,    # standard object storage
    "egress_gb":          0.09,     # internet egress, first tier
    "cross_az_gb":        0.01,     # per direction
    "cross_region_gb":    0.02,
    "nat_gateway_hour":   0.045,
    "nat_gateway_gb":     0.045,
}

HOURS = 730                          # hours in an average month

def monthly(instances, storage_gb, egress_gb, cross_az_gb, nat=True):
    compute  = instances * PRICES["compute_hour"] * HOURS
    storage  = storage_gb * PRICES["storage_gb_month"]
    egress   = egress_gb * PRICES["egress_gb"]
    az       = cross_az_gb * PRICES["cross_az_gb"]
    natcost  = (PRICES["nat_gateway_hour"] * HOURS
                + egress_gb * PRICES["nat_gateway_gb"]) if nat else 0
    total    = compute + storage + egress + az + natcost
    return {"compute": compute, "storage": storage, "egress": egress,
            "cross_az": az, "nat": natcost, "TOTAL": total}

bill = monthly(instances=16, storage_gb=50 * TB, egress_gb=20 * TB, cross_az_gb=100 * TB)
for k, v in bill.items():
    print(f"{k:<10} ${v:>12,.2f}   {100*v/bill['TOTAL']:>5.1f}%")

$ python cost.py
compute    $      971.78    16.3%
storage    $    1,177.60    19.7%
egress     $    1,843.20    30.9%
cross_az   $    1,024.00    17.2%
nat        $      954.45    16.0%
TOTAL      $    5,971.03   100.0%

Read the percentages, not the total. Compute is 16% of this bill. Data movement — egress plus cross-AZ plus NAT — is 64%.

That inversion is the single most useful thing to internalise about cloud cost, and it is where cert prep leaves you blind — the exams test which service does what, not which line dominates.

Three consequences that turn into interview answers:

• Egress is the tax on leaving. Serving 20 TB to the internet costs $1,843 — nearly twice the $972 fleet that served it. A CDN in front changes this line item by an order of magnitude.
• NAT gateways charge per gigabyte processed on top of an hourly rate. Traffic to object storage through a NAT gateway is the classic accidental six-figure line; a VPC endpoint removes it.
• Cross-AZ traffic is not free. It is small per gigabyte and large at volume, and it is the hidden cost of a chatty microservice mesh spread across zones.

Estimating without a price list

You will not have the calculator open. These anchors are enough:

Small VM (2 vCPU, 8 GB)         ~$60/month on demand, ~$25 reserved
Object storage                  ~$0.02 per GB-month  → 1 TB ≈ $20/month
Internet egress                 ~$0.09 per GB        → 1 TB ≈ $90
Cross-region transfer           ~$0.02 per GB        → 1 TB ≈ $20
Managed relational DB           roughly 2x the equivalent raw VM
Serverless function             ~$0.20 per million invocations + memory-time
Managed Kubernetes control plane ~$70/month per cluster

“Roughly two cents a gigabyte-month to store and nine cents a gigabyte to serve out. So a terabyte sitting still is about twenty dollars a month, and a terabyte leaving is about ninety dollars once. That ratio is why caching and CDNs pay for themselves — I’d check the calculator before committing to a number, but that’s the shape.”

Being within 2x and saying you would verify is a correct answer. “I don’t know” is not.

The failure question

For every component in your design, three answers:

COMPONENT       WHEN IT DIES              WHO NOTICES        RECOVERY
load balancer   managed, multi-AZ         nobody             automatic
app instance    ASG replaces it           nobody             ~2 min
whole AZ        capacity drops by 1/3     latency alarm      ASG scales in others
database primary  writes fail             error rate alarm   failover, 30-120s
whole region    total outage              everyone           depends on your DR plan
cache           latency spikes, DB load   DB CPU alarm       warms back over minutes

The row people forget is the cache. “The cache goes down” is not a small event — it is a thundering herd against a database sized on the assumption that the cache absorbs 95% of reads. Naming that unprompted is a strong signal.

The clarifying questions worth asking

"How many users, and what's the read/write ratio?"      → sizing
"What's the acceptable downtime — minutes, or hours?"   → single vs multi-region
"How much data loss is tolerable on failover?"          → RPO, sync vs async replication
"Is this greenfield, or migrating something running?"   → completely different answers
"Is there a budget constraint I should design against?" → the FinOps framing
"Which cloud, and is multi-cloud a requirement?"        → managed vs portable services
"Is there a compliance or data residency constraint?"   → region choice, encryption

Two of these before you draw anything. The most common way to fail an architecture round is to design a correct system for a problem nobody asked about.

How the round runs

1. CLARIFY      Two or three questions. Scale, availability target, constraints.
2. SIZE         Do the arithmetic out loud. Requests, storage, instances.
3. SKETCH       Boxes and arrows. Name the services, and where state lives.
4. FAIL IT      Walk each component and say what happens when it dies.
5. COST IT      Rough monthly number, and which line item dominates.
6. TRADE OFF    "This is more expensive than X because Y. Here's when I'd
                choose X instead."

Steps 4, 5, and 6 are what most candidates skip and what most interviewers are actually scoring.

Practice

200M requests/day → 2,315 avg RPS → 6,944 peak RPS → 14 instances → 16 with spares

compute 16.3%    storage 19.7%    egress 30.9%    cross-AZ 17.2%    NAT 16.0%

stored: ~$20/month      served out: ~$90 once

Thundering herd against a database sized assuming 95% cache hit rate.

Next: compute choices — VM, container, or serverless, with the break-even calculation that decides between them.