Quick Answer
An AWS Solutions Architect interview is graded against Amazon's 16 Leadership Principles, not a fixed question list. That means your preparation unit is a story bank — a set of real experiences, each mapped to the principle it proves best, with explicit ownership boundaries and a ready translation into AWS vocabulary. This guide shows the exact system: the story shape, the LP map, eight worked examples, and the cross-platform translation technique.
Why a story bank beats a question list for an AWS SA interview
Amazon's Solutions Architect loop is graded against Leadership Principles, not a list of questions — and that distinction changes everything about how you prepare. A question list assumes you can predict which question comes next. A story bank assumes the interviewer will approach the same story from five different angles, and you need to be ready for all of them.
What is a CARL story bank?
A CARL story bank is a structured collection of real professional experiences, each shaped around six ordered questions — Customer concern, Architecture reasoning, Real ownership, and Learning — mapped to specific Leadership Principles, with explicit notes on what you personally did versus what specialists or partners did, and a short translation into AWS-equivalent services and patterns.
The difference between a CARL story and a generic STAR story is precision about three things: whose problem it was (the customer's concern, not your technical task), what you personally owned versus what others did, and what you actually learned rather than what went well. Those three things are exactly what Amazon interviewers probe in follow-up questions — which means if your story doesn't have them built in, you will feel the pressure the moment the second question arrives.
If your real experience sits on a different cloud platform than AWS — Azure, GCP, or another major vendor — that is not a disqualifier. It is a translation problem, and translation problems have solutions. The guide to the STAR interview framework covers the underlying story structure in depth; what this article adds is the specific system for mapping that structure to Amazon's Leadership Principles and across cloud platforms.
Key takeaway
Prepare for the principle, not the question. The same story can answer 'Tell me about a time you owned a problem' and 'Tell me about a time you earned trust' — if you know which principle it proves best, you can steer it there under pressure.
The CARL story shape: six questions every story must answer in order
Every story in a well-built SA story bank answers six questions in a fixed order. The order matters because it mirrors how Amazon interviewers evaluate answers: they want to know the customer's real concern before they want to hear about services or architecture. A story that opens with 'I deployed EKS and configured autoscaling' is an architecture pitch. A story that opens with 'The customer needed to know whether their traffic could survive a migration without latency regression' is a customer story — and only one of those will land well at Amazon.
The six questions, in order
- What worried the customer? (Not: what was the technical task. What was the customer's actual concern — cost, risk, timeline, trust, operational continuity?)
- Why did it matter? (Scale, business impact, strategic stakes — one sentence that tells the interviewer this was a real problem, not a sandbox exercise.)
- What were you thinking? (Your reasoning before you acted — what hypotheses you formed, what you decided not to do, and why. This is where 'Are Right, A Lot' lives.)
- What did you personally do? (Not what the team did. Not what the partner did. What you specifically owned, decided, communicated, or unblocked. This is where 'Ownership' lives.)
- What changed? (The concrete result — for the customer, not just for the project. A number, a decision made, a blocker removed, a trust rebuilt.)
- What did you learn? (One honest reflection. Not 'it went great.' Something that changed how you work now.)
Interview tip
Time your story against these six questions, not against a word count. Questions 1–2 should take about 20% of your answer. Questions 3–4 should take about 50%. Questions 5–6 should take about 30%. If you are spending most of your time on question 4 (what you did) without establishing questions 1–2 (why it mattered), the interviewer has no context to evaluate your judgment.
Weak opening (service-first)
"So I was working on a migration project and we needed to set up EKS with autoscaling, configure a managed database, and connect the CI/CD pipeline. The customer was on a different cloud platform before..."
Strong opening (customer concern first)
"The customer's main concern wasn't the cost saving — they already had a 66% estimate. What they needed to know was whether they could actually run production on the new platform without putting their live service at risk. That question had to be answered before any migration made sense."
Watch Out
The most common mistake non-native English speakers make in this shape is translating their thinking process literally from their first language, which often puts the action before the context. In English interview answers, context (the customer's concern) must come first — the action without context sounds like a list of tasks, not a demonstration of judgment.
The ownership boundary: why vague answers lose credibility in SA interviews
Being explicit about what you personally owned versus what specialists, delivery partners, or the customer did is the single detail most candidates skip — and it is the detail Amazon interviewers probe hardest. In a presales or solutions architect role, you are almost never the person implementing every component end to end. Trying to claim you were reads as either dishonest or confused about your own role. Being precise reads as senior.
For every story, keep three separate lists ready
- What I did: the decisions, communications, assessments, and unblocks that were mine to own.
- What specialists or delivery partners did: implementation, deep technical work in areas outside my scope, formal support escalations.
- What the customer did: their own internal decisions, their delivery team's work, their sign-offs.
The phrase that makes this land well in English is: 'I didn't implement that part myself, but I owned the assessment, coordinated the specialists, and made sure the customer had a clear picture of the trade-offs.' That sentence is not a confession of limitation — it is a description of a senior technical role. Interviewers hear it as more credible than 'I built the whole thing.'
| What you actually did | How to say it in English | What the interviewer hears |
|---|---|---|
| Coordinated specialists but didn't implement | "I didn't implement that component myself — I brought in the networking specialist and made sure the customer had context before that conversation." | Senior. Knows their scope. Trustworthy. |
| Assessed and recommended, didn't build | "My contribution was connecting the cost analysis to a concrete migration path and keeping the team focused on the real blockers." | Strategic. Adds value beyond technical execution. |
| Validated a result you didn't produce | "I wasn't running the test, but I defined the success criteria and pushed back when the methodology didn't match the production scenario." | Has standards. Insists on the Highest Standards. |
| Escalated when blocked | "Once we had clean evidence, I recommended opening a formal support case — the customer was genuinely blocked and guessing wouldn't help." | Bias for Action. Doesn't stall. |
Precise ownership boundaries make you sound more senior, not less capable.
The full LP map: lead story and backup for all 16 Amazon Leadership Principles
Map your stories to Leadership Principles before you rehearse them — not during the interview. For each principle, you need a lead story (the one that proves it most directly) and a backup (a different story that also demonstrates it, in case the interviewer asks a follow-up that your lead story can't cover). The table below shows how a real SA story bank maps across all 16 principles, with the angle that makes each story credible for that principle.
| Leadership Principle | Lead story | Backup story | The angle that makes it credible |
|---|---|---|---|
| Customer Obsession | Identity incident during evaluation | Database-transition escalation | Customer impact, trust, and clarity — not just the technical fix |
| Ownership | Identity incident | Cost-assessment blocker | Didn't stop at your formal boundary when the customer outcome was blocked |
| Invent and Simplify | Production migration | Ongoing assessment engagement | Focused architecture on the practical production path, not the most complete design |
| Are Right, A Lot | Cost assessment | Large-scale evaluation | Kept assumptions explicit and avoided unsupported claims |
| Learn and Be Curious | DevOps/deployment investigation | Migration story | Learned enough of a new technical area to structure the problem correctly |
| Hire and Develop the Best | Large-scale evaluation | Workshop engagements | Brought specialists into the right conversations and prepared context for them |
| Insist on the Highest Standards | Large-scale evaluation | Cost assessment | Pushed for realistic validation, not a superficial demo |
| Think Big | Large-scale evaluation | Production migration | Connected a bounded technical step to a broader platform strategy |
| Bias for Action | DevOps investigation | Identity incident | Created momentum when the customer was blocked |
| Frugality | Cost assessment | Production migration | Balanced cost reduction with realistic architecture — not just the biggest savings number |
| Earn Trust | Database-transition escalation | Identity incident | Listened, stayed factual, and avoided overpromising |
| Dive Deep | Layered troubleshooting story | Identity incident / DevOps story | Separated the stack into layers and made hypotheses testable |
| Have Backbone; Disagree and Commit | Internal stakeholder conflict | Trade-off conversations inside evaluation | Addressed disagreement directly without damaging the working relationship |
| Deliver Results | Production migration / cost assessment | DevOps investigation | Moved from assessment into a concrete customer outcome or unblock |
| Strive to be Earth's Best Employer | Internal stakeholder conflict | Incident-response collaboration | Improved collaboration and reduced friction under pressure |
| Success and Scale Bring Broad Responsibility | Large-scale evaluation | Database-transition escalation | Weighed operational, trust, cost, and long-term consequences at scale |
Every story appears in at least two cells — that is the point. A bank of eight stories covers all 16 principles if each story is mapped carefully.
Interview tip
Notice that the same story (the large-scale evaluation) appears as lead or backup for five different principles. That is not laziness — it is the correct system. A rich, complex story can prove multiple principles depending on which angle you emphasize. The skill is knowing, in the moment, which angle the interviewer is actually asking about.