From Whiteboard Interview to Terraform Plan: A Prompt Playbook for System Design and Cloud Architecture in 2026

From Whiteboard Interview to Terraform Plan: A Prompt Playbook for System Design and Cloud Architecture in 2026

In October 2026, a system design interview and a real infrastructure change request look suspiciously similar. Both start with vague requirements, a blank page, and a ticking clock. The difference is that one ends with a polite "we'll be in touch," and the other ends with a terraform plan that either terrifies you or makes you smile.

The uncomfortable truth: most engineers lose hours not because they lack knowledge, but because they lack a structured way to think out loud. Whether you are designing a multi-region Kubernetes platform on AWS or surviving a 45-minute FAANG loop, the bottleneck is the same — turning fuzzy constraints into concrete artifacts (capacity numbers, failure domains, API contracts, IaC modules).

This playbook is a working collection of prompts I use to compress that process. It is organized in three tiers — Basic, Advanced, and Expert — and every prompt is written to produce something verifiable: a trade-off table, a capacity estimate, a Kubernetes manifest, a Terraform module, or a runbook. Where standards matter, I point to the real sources (RFCs from rfc-editor.org, the AWS Well-Architected Framework, the Kubernetes documentation), and where numbers matter, I show the arithmetic instead of asserting magic percentages.

Why prompts work for architecture (and where they fail)

An LLM is a probabilistic text engine, not an oracle. It does not know your SLOs, your compliance regime, or your team's on-call maturity. What it is genuinely good at: expanding a seed idea into a structured artifact you can critique, enumerating failure modes you forgot, and translating between representations (a diagram description into a Terraform skeleton into a cost estimate).

The rule I follow: the model proposes, the engineer disposes. Never paste a generated IAM policy, security group, or production manifest without reading it line by line. Treat output as a draft from a fast, tireless, occasionally overconfident colleague.

Two practical habits make the difference:

1. Always request a trade-off table. A design without alternatives is a guess.
2. Always demand numbers. "It scales well" is worthless; "3 replicas × 500 RPS/instance = 1500 RPS sustained" is checkable.

Basic tier: getting the structure right

1. The requirement-clarification prompt

Task: Turn a one-line product idea into a structured list of clarifying questions, exactly like the first 5 minutes of a system design interview.

Prompt:

You are a staff engineer interviewing a candidate. I will give you a one-line product idea.
Do NOT design the system yet. Instead:
1. List 10 clarifying questions grouped into: functional requirements, non-functional
   requirements (latency, throughput, consistency, durability), scale assumptions,
   and constraints (budget, team size, compliance).
2. For each question, state the default assumption an experienced engineer would make
   if the interviewer said "you decide."
3. Flag which two questions would most change the architecture.
Product idea: "A collaborative whiteboard for 50-person design reviews."

Example result: The model returns questions like "How many concurrent editors per board?" with a default of ~50 and a note that real-time presence (CRDT vs OT) is the architecture-changing decision. It also flags "Do we need offline editing?" as the second pivot point. This mirrors the actual interview structure described in the System Design Interview literature and in engineering blogs from companies like Figma, who have publicly discussed CRDT-based multiplayer.

2. The back-of-the-envelope capacity prompt

Task: Produce a defensible capacity estimate with visible arithmetic.

Prompt:

Estimate capacity for this system. Show EVERY step of arithmetic, state each assumption,
and use powers of ten. Convert to concrete units: RPS, storage GB/month, bandwidth Mbps.
System: URL shortener. Assumptions: 100M new URLs/month, 10:1 read:write ratio,
5-year retention, average URL length 100 bytes, metadata 500 bytes per record.
Deliver: (a) write RPS, (b) read RPS, (c) peak multiplier 3x, (d) 5-year storage, (e) cache size
if we cache 20% of hot reads with a 0.8 power-law distribution.

Example result: Writes ≈ 100M / (30×86400) ≈ 39 RPS; reads ≈ 390 RPS; peak ≈ 1.2k RPS. Storage ≈ 100M × 600 B × 60 months ≈ 3.6 TB (before replication). This is the same discipline taught in Google's SRE book on capacity planning — the point isn't the exact number, it's that you can show the work.

3. The API contract prompt

Task: Draft a versioned REST or gRPC contract with error semantics.

Prompt:

Design a REST API for a task queue service. For each endpoint give: method, path,
request schema, response schema, status codes, and idempotency semantics.
Follow RFC 9110 (HTTP Semantics) for method semantics and RFC 9457 (Problem Details)
for error bodies. Include pagination via cursor and a Retry-After header on 429.
Output OpenAPI 3.1 YAML.

Example result: The model emits an OpenAPI document with POST /v1/tasks returning 201 + Location, Idempotency-Key header support, and application/problem+json error bodies per RFC 9457. Cross-check against the official specs at rfc-editor.org before shipping.

4. The data-model prompt

Task: Convert access patterns into a schema — the DynamoDB single-table approach, generalized.

Prompt:

Given these access patterns, propose a storage schema. State the partition key, sort key,
and GSI/LSI for each pattern, and explain the hot-partition risk.
Patterns: (1) get user by id, (2) list user's orders by date desc, (3) get order by id,
(4) list orders by status for ops. Expected: 5M users, 50M orders.

Example result: A table with PK=USER#<id>, SK=ORDER#<timestamp> for pattern 2, and a GSI on status for pattern 4, plus a warning that a GSI partitioned by low-cardinality status will create hot partitions — a well-documented DynamoDB anti-pattern in AWS's own developer guide.

Advanced tier: cloud, Kubernetes, and IaC

5. The AWS Well-Architected review prompt

Task: Pressure-test a design against the six pillars.

Prompt:

Review this architecture against the AWS Well-Architected Framework's six pillars
(Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization,
Sustainability). For each pillar: list 3 risks, the AWS service or pattern that mitigates
each, and a measurable acceptance criterion.
Architecture: ALB -> ECS Fargate -> RDS Postgres Multi-AZ, S3 for uploads, no CDN.

Example result: Under Reliability it flags the single-region RDS and suggests read replicas + automated failover; under Cost it points out that Fargate without right-sizing often costs more than Graviton EC2 for steady load. The pillar names come straight from the framework at docs.aws.amazon.com/wellarchitected.

6. The Kubernetes manifest prompt

Task: Generate a production-grade deployment with the safety rails people forget.

Prompt:

Generate a Kubernetes Deployment + Service + HorizontalPodAutoscaler for a stateless
HTTP API. Requirements:
- image pinned by digest, 3 replicas
- requests/limits for cpu and memory
- liveness, readiness, and startup probes on /healthz, /readyz
- pod anti-affinity across zones
- PodDisruptionBudget minAvailable: 2
- HPA on CPU 70%, min 3 max 12
- runAsNonRoot, readOnlyRootFilesystem, drop ALL capabilities
Use apps/v1 and autoscaling/v2. Comment each non-obvious field.

Example result: A manifest where the startupProbe prevents the classic crash-loop-on-slow-boot, and readOnlyRootFilesystem: true forces you to mount an emptyDir for temp files. Every field here maps to real, stable Kubernetes APIs — verify versions against kubernetes.io/docs.

7. The Terraform module prompt

Task: Scaffold a reusable, remote-state-backed module.

Prompt:

Write a Terraform module (Terraform >= 1.9, AWS provider >= 5.x) that provisions a
VPC with 3 public and 3 private subnets across 3 AZs, a NAT gateway per AZ, and
flow logs to CloudWatch. Include variables.tf, outputs.tf, and a versions.tf with
required_providers. Add a backend block for S3 remote state with DynamoDB locking
and a comment explaining why state locking matters. Do not hardcode region or CIDR.

Example result: A module with cidrsubnet() calls to carve subnets, outputs for vpc_id and private_subnet_ids, and a backend config. Note: since Terraform 1.10+, native S3 locking is available (use_lockfile = true), so the DynamoDB locking table is increasingly optional — a good thing to mention to avoid stale advice.

8. The cost-estimation prompt

Task: Turn an architecture into a monthly bill estimate with a sensitivity analysis.

Prompt:

Estimate the monthly AWS cost for this workload. Show the calculation per service,
list the pricing dimension used (per-hour, per-GB, per-request), and then show how the
bill changes if traffic doubles.
Workload: 3 × c7g.large EC2 (Graviton) 24/7, 500 GB EBS gp3, 2 TB S3 Standard,
1 ALB, 300 GB egress/month, 1 RDS db.m7g.large Multi-AZ.

Example result: The model produces a line-item table. Always re-verify against the AWS Pricing Calculator (calculator.aws), because prices and instance families change frequently — never trust a memorized rate.

9. The failure-mode / chaos prompt

Task: Enumerate failure modes before they enumerate you.

Prompt:

For this architecture, run a hypothetical pre-mortem: assume it failed badly at 3 AM.
List 12 failure modes across network, data, dependency, and human categories.
For each: blast radius, detection signal, and the single best mitigation.
Architecture: Kubernetes on EKS, service mesh, Postgres, Redis cache, Kafka for events.

Example result: It surfaces classic traps — Redis as a cache and a lock store (dual-use), Kafka consumer lag without alerting, and a single NAT gateway as a hidden single point of failure. These map to well-known reliability principles in Google's SRE Workbook.

10. The observability / SLO prompt

Task: Define SLIs, SLOs, and alerting that doesn't wake people for nothing.

Prompt:

Define SLIs and SLOs for an HTTP API. For each SLO, give the error budget policy and a
multi-window, multi-burn-rate alert (following the Google SRE approach). Express SLIs as
PromQL over http_request_duration_seconds and http_requests_total. Include a 99.9%
availability SLO over 28 days.

Example result: PromQL for a 1-hour and 5-minute burn-rate pair, with alert thresholds at 14.4x and 6x — the exact pattern published in the SRE Workbook chapter on alerting on SLOs.

Expert tier: interviews, governance, and scale

11. The FAANG interview simulator prompt

Task: Run a realistic, adversarial mock interview with scoring.

Prompt:

Act as a senior interviewer at a large tech company. Give me a system design problem
("design a rate limiter for a multi-tenant API"). Then conduct a 45-minute interview in
rounds: clarify, high-level design, deep dive, scale. After each of my answers, push back
with ONE follow-up that a real interviewer would ask. Do not be nice — probe weak spots.
At the end, score me on: requirements, estimation, trade-offs, depth, and communication,
1-5 each, with specific quotes from my answers.

Example result: The model pushes on the distributed-counter consistency problem of rate limiting and asks whether you'd use a token bucket in Redis with Lua scripts versus a sliding-window log. This mirrors the discussion in Alex Xu's System Design Interview and in the public engineering writing on rate limiting.

12. The multi-region / DR prompt

Task: Choose an active-active vs active-passive topology with explicit RPO/RTO.

Prompt:

Design a multi-region DR strategy for a payment API. Compare active-passive (warm standby)
vs active-active. For each: RPO, RTO, cost multiplier, and data-consistency implications.
Recommend one given RPO < 1 min and RTO < 5 min. Address the cross-region database
problem: Aurora Global Database vs DynamoDB Global Tables vs self-managed Postgres.

Example result: A trade-off table recommending active-passive with Aurora Global Database for the stated RPO/RTO, with a note that true active-active write conflicts require conflict resolution most payment systems can't tolerate. Aurora Global Database's documented typical replication lag (under a second) supports the RPO claim — verify against AWS docs.

13. The security / threat-model prompt

Task: STRIDE-style threat modeling on a data flow.

Prompt:

Perform a STRIDE threat model on this data flow: mobile client -> API Gateway -> Lambda
-> RDS. For each STRIDE category (Spoofing, Tampering, Repudiation, Information disclosure,
Denial of service, Elevation of privilege), list threats, the affected component, and a
concrete control (e.g., specific IAM condition, WAF rule, or encryption setting).

Example result: It flags IAM privilege escalation via over-broad Lambda roles and suggests scoping policies with Condition keys like aws:SourceArn. STRIDE itself is from Microsoft's public threat-modeling documentation.

14. The migration / strangler-fig prompt

Task: Plan an incremental migration from a monolith without a big-bang rewrite.

Prompt:

Create a strangler-fig migration plan to extract the "billing" domain from a Rails monolith
into a separate service. Give 6 phases: each with the seam (how traffic splits), the data
strategy (dual-write vs CDC), the rollback trigger, and the success metric. Assume we
cannot take downtime.

Example result: Phase 1 routes a percentage of read traffic via a facade; later phases use change data capture (e.g., Debezium) to keep both stores consistent. The strangler-fig pattern is documented by Martin Fowler, and Debezium is a real open-source CDC platform.

15. The FinOps / tagging-governance prompt

Task: Design a cost-allocation and tagging policy that survives audits.

Prompt:

Design a tagging and cost-allocation strategy for a 200-engineer org on AWS.
Propose a mandatory tag schema (owner, cost-center, environment, data-classification),
enforcement via AWS Organizations SCPs and tag policies, and a monthly showback report.
Explain how untagged spend is detected and remediated.

Example result: A schema plus enforcement via Service Control Policies and AWS Cost Categories for showback. This aligns with the FinOps Foundation's public framework on allocation and tagging.

16. The documentation / ADR prompt

Task: Turn a decision into an Architecture Decision Record others can trust.

Prompt:

Write an ADR (Architecture Decision Record) in the standard format — Title, Status,
Context, Decision, Consequences — for choosing gRPC over REST for internal service-to-service
communication. Include the rejected alternatives and the conditions under which we would
revisit this decision.

Example result: A one-page ADR with a clear "revisit if" clause. The ADR format is a well-established practice (popularized by Michael Nygard) and is a genuine differentiator in senior interviews — it shows you think about the lifecycle of decisions, not just the decision.

A note on verification and trust

Every prompt above produces a draft, and drafts have failure modes. Before anything touches production: check API and field names against official docs (kubernetes.io, docs.aws.amazon.com, developer.hashicorp.com), confirm RFC numbers at rfc-editor.org, and re-run cost estimates in the AWS Pricing Calculator. Models are excellent at structure and mediocre at freshness — assume any hardcoded price, version, or default is stale until proven otherwise.

The bigger payoff isn't speed. It's that a good prompt forces you to make your assumptions explicit. You cannot ask for a trade-off table without admitting there are trade-offs. You cannot ask for a capacity estimate without picking a scale. That discipline is exactly what interviewers and production incidents reward.

Start with the Basic tier today: pick one prompt, run it on a system you actually own, and compare its output to what you'd have written alone. Then move to the Terraform and Kubernetes prompts and let the model generate the boring 80% while you own the dangerous 20%. The whiteboard and the terminal were always the same skill — this playbook just makes the practice faster.