When: Wed 11 Nov 2026, 13:00 to 14:00 CAT, same Zoom link.
Who: Principal Specialist SA, Analytics. Data and AI with CXOs, data modelling, author on AWS data engineering, analytics and generative AI. His bio says he's a Bar Raiser (the schedule doesn't).
What a Bar Raiser decides: an objective interviewer from outside the hiring team, checking you meet Amazon's bar for the level. Less interest in service names; deep probing on ownership, judgement, ambiguity and impact. Usually three or four stories, each probed for 10 to 15 minutes. Any technical question will be data or AI, and he'll notice bluffing.
Rules for this hour: depth beats breadth; "I", not "we"; a number, or "about..., I don't have the exact figure"; own the bad parts; never overclaim. Before you join, check the tracker for what Jason heard on Monday.

How each story is laid out: STAR. S and T one sentence each; A as numbered steps, what you did and how; R with the number; then the learning. Say it as written, without the labels. Under each story, the probes he's likely to use.

The five probes he'll use on every story (have each answer ready):

1. "What exactly did you do?" Your A steps, in the first person.
2. "What data did you use?" The evidence in your A steps.
3. "What was the result?" Your R, with the number.
4. "What would your manager say?" Only what you know they said or would recognise; otherwise "I'd expect them to say..." and the result.
5. "What would you do differently?" Your learning line.

S: At Big Beard, migrating over 500 websites to AWS, I had to size the e-commerce sites.
T: The sizing was my call, and I sized them from the hosting plan each client paid for, not from what they actually used.
A: what I did, and how:

1. Found it in the error logs: the database storage filled up. I'd sized the RDS storage from the plans, but the real databases were 2, 14 and 32 GB, so the larger ones didn't fit and the loads failed. Nobody had to tell me; I traced it myself. [If asked who you told: your answer.]
2. Measured each site's real usage on the old server.
3. Archived data the sites no longer used.
4. Right-sized each site from the measurements: database storage on RDS to the real size, with storage autoscaling up to a cap, and the services on ECS.
5. Cut the cost of fixing it: a script stopped the e-commerce services outside working hours while I built and tested.

R: They ran at about 23 dollars a month each, cheaper than before, with clients paying the same.
Learning: a plan tells you what something should be; the data tells you what it is. In my discovery work today, capacity has to come from a month-end of measurement, not from interviews.

Probes:

• "What exactly failed?" "The database storage. RDS needs an allocated size up front, and it only grows, never shrinks. I'd set it from the plans, so the real databases didn't fit. The writes failed with a disk-full error, FreeStorageSpace in CloudWatch had dropped to almost zero, and RDS moved the instance into the storage-full state."

• What you see when RDS storage runs out (so you can describe it accurately):

  Where	What it shows
  RDS console, instance status	storage-full
  CloudWatch metric	FreeStorageSpace falling to about 0
  The database (MySQL or MariaDB)	ERROR 1114 (HY000): The table '...' is full, or ERROR 1021 (HY000): Disk full (...); waiting for someone to free some space. At the operating-system level: No space left on device

• Say the exact code only if you remember it. Otherwise: "the import failed with a disk-full error, and the instance went into storage-full".

• The prevention line: "Now I measure first, turn on storage autoscaling with a maximum, and alarm on FreeStorageSpace well before zero, for example below 20% of allocated storage."
• "How would you stop it now?" "Measure first, turn on storage autoscaling with a sensible cap, and alarm on free storage space before it runs out."
• "Why not just a bigger instance?" "That's compute, not space. The instance class sets CPU and memory, the storage type sets how fast the disk is, and the allocated storage sets how big it is. My problem was size: allocated storage taken from the plans, with no maximum to grow into."
• "How does RDS storage autoscaling work?" "You set a maximum. RDS grows the storage when free space drops below 10% for five minutes, with at least six hours since the last change, and it never shrinks. A big import can still outrun it because of that cooldown, which is why measuring first mattered more."

The four RDS settings, so you never mix them up:

Say storage type for RDS. Storage class is an S3 term (Standard, Glacier).

• "Why didn't you measure first?" "I treated the plan as the specification. Nothing enforced the limits on the shared servers, which was exactly the problem we were leaving, so I should have expected it."
• "How do you know it won't happen again?" "It's a rule in how I work: every number names its source, and estimates are marked as estimates."
• "What did it cost?" "[Your honest estimate of the rework.]"

S: Clients at Big Beard kept reporting delayed email, and the hosting provider kept clearing storage, but it kept coming back.
T: Find the real cause, not the symptom.
A: what I did, and how:

1. Looked at the pattern: clearing storage fixed it every time, and it hit everyone on a server at once, which points to a shared resource.
2. Found the root cause in the architecture: every site shared storage on two servers, and clients rarely deleted anything, so one client filling up slowed email for everyone. A noisy neighbour.
3. Fixed the design, not the symptom: in the migration, every site got its own isolated resources, watched against its plan, with alarms near the limit.

R: The delays ended, and nobody cleared storage by hand again.
Learning: if a fix has to be repeated, it isn't a fix.
Probe, "Why not just add storage?": "That moved the problem. While clients shared storage with no limits, one could still fill it for everyone."

S: When we chose the migration target at Big Beard, a solutions architect proposed one Lightsail instance per website, because a fixed price per site is easy to sell.
T: I believed it would cost us availability and the ability to scale, and I had to make that case without dismissing the revenue concern.
A: what I did, and how:

1. Took the proposal seriously: revenue mattered, and I said so.
2. Showed the drawbacks concretely: one instance per site means one failure takes it down, shops can't scale out, there are 500 servers to patch, and the database sits on the same machine.
3. Proposed an alternative by site type and compared the two pillar by pillar with the Well-Architected Framework.
4. Answered their real concern: clients keep paying the same, running costs go down, so the margin per client improves.

R: My design was adopted. Costs came to near zero, 2 dollars or 23 dollars a site a month, and we kept working well together.
Learning: their concern was revenue, so the argument that worked was margin.
If overruled: "I'd have committed fully, made Lightsail as resilient as possible, and tracked incidents so we could revisit it with data."
If he asks for your manager specifically: this was a senior peer, so use HF1.

S: At Big Beard we were understaffed: we needed a senior, an intermediate and a junior developer, and later an architect. I was the sole cloud and DevOps engineer.
T: Keep the cloud and DevOps work moving while covering the development gap, especially in the proof-of-concept stages.
A: what I did, and how:

1. Took on development and testing in Python and Node.js, because I knew them well, mostly during the proofs of concept.
2. Closed my own gaps: I'm not a pure developer, so there were gaps in how I worked, and I improved them.
3. Saw the cost: wearing both hats, my cloud and DevOps work lagged.
4. Got the feedback: there were conversations that my role should change to senior Python developer, because of the gaps that came from wearing two hats.
5. Owned my reaction: I didn't take it well at first, because it changed what I wanted to do. My goal has always been to become a solutions architect.
6. Pushed back, with a solution: I explained the developer path wasn't mine and conflicted with the role I was doing, and I helped fix the real problem: I was the sole interviewer for the missing developer roles, so I helped find the developers.

R: [What happened next: did your role stay as it was, and were the developers hired?]
Learning: [In your words. A possible line: "Covering a gap is right in the short term, but agree up front how long it lasts and what it costs the main job, so it doesn't quietly become the job."]
Probes: "Was the feedback fair?" "Partly: the gaps in my development work were real, and I fixed them. Changing my role was the wrong fix for an understaffing problem." "What would your manager say?" [Your honest view.] [Confirm who raised the role change: your manager, the director or both.]

Rules: "a regulated financial services client"; never name it; costs are "illustrative"; no final decision yet.
S: At a regulated financial services client, a large estate on OpenShift on-premises had to move to AWS on a tight deadline, and the choice was ECS or ROSA, managed OpenShift.
T: I argued for ECS: one vendor instead of a chain, about half the cost in an illustrative model, and native IAM and networking.
A: what I did, and how:

1. Listened to the challenge: the architecture review forum raised the refactoring effort.
2. Analysed it, and found they were right: moving off OpenShift means rebuilding the deployment model, the compliance defaults and the networking. On that deadline, ECS everywhere would have delayed the migration.
3. Changed my position and committed to a split: what suited ECS went to ECS, what needed heavy refactoring went to ROSA, with the trade-offs written down.
4. Fixed a gap I found along the way: there was no process tracking each application's networking, so I proposed a per-application connection inventory, including which clients connect by fixed IP, because those break at cutover.

R: A split recommendation the forum could support, with the trade-offs recorded, and a connection inventory that protects the cutover.
Learning: I'd argued the platform before sizing the effort. Size the migration effort before you pick the platform.

Rule: never claim the Bar Raiser title.
S: At AWS Support, hiring needed more interviewers without lowering the standard.
T: Interview well myself, and help new interviewers get to the same standard.
A: what I did, and how:

1. Did over 100 interviews, assessing technical depth on real scenarios and behavioural evidence against the Leadership Principles.
2. Pushed for written evidence before the debrief, so the discussion stayed on what the candidate actually showed.
3. Reverse-shadowed new interviewers: they led, I observed, then gave specific feedback on their questions, their follow-ups and their write-up.

R: Hiring capacity grew without lowering the bar. [How many interviewers you helped develop, if you know.]
Learning: the bar is held by evidence, not by opinion in the debrief.
If asked "Were you a Bar Raiser?": "My role was interviewing in Support hiring and developing new interviewers by reverse-shadowing them."

S: On SNS SMS, customers launching a new service hit their SMS spend limit on launch day, and their messages stopped: an outage. The normal route to raise it sat in a slow queue, even though it always ended with my team.
T: Get the customer's messages flowing again straight away, without skipping the record.
A: what I did, and how:

1. Weighed the trade-off: wait for the full process, safe but the customer stays down on launch day, or act now.
2. Raised their limit straight away, which was within my role.
3. Then escalated it, so the change was formally recorded, not done quietly.
4. Ruled out the workaround: switching Region meant a code change mid-outage, and that Region's limit could run out too.

R: Customers got their SMS back within minutes, and it cut tickets by about 40%.
Learning: it was a two-way door: easy to reverse, with the record still made. On a one-way door, like deleting data, I'd slow down and get approval.

S: At AWS, SQS customers sometimes created a queue with a Deny All policy, which locked everyone out, including themselves. Support couldn't change it, so every case went to the service team in Seattle, and removal took days while the customer's production was held up.
T: As a support operations engineer, get locked-out customers back in faster, without weakening the checks on who may ask.
A: what I did, and how:

1. Verification first, every time: I checked who created the queue and who opened the case, their permissions and their access, before any removal.
2. Took on the tooling: the service team gave experienced support operations engineers access to remove these policies, and I was one of them.
3. Submitted a process-improvement request for a dedicated queue for these cases, so they no longer waited in general queues or travelled to Seattle.

R: Cases were resolved within our own shift instead of taking days, with fewer hand-offs, and it stopped being an issue globally.
Learning: the best fix is prevention: guide customers to scope Deny statements with conditions and exclude a break-glass admin role.

S: The Isiqalo Youth Fund portal, where young entrepreneurs apply for funding in an annual window, ran on-premises and was overwhelmed within ten minutes of the window opening, every year. Applicants who miss it wait a year.
T: Redesign it on AWS before a window date that couldn't move.
A: what I did, and how:

1. Worked from the data I had: the basic logs showed when the rush came and that it broke, not which component failed first. Waiting for better data meant another failed window, so I designed from the patterns.
2. Chose replatform: a lift-and-shift onto fixed servers would have failed the same way, and a full rebuild wouldn't be ready in time.
3. Designed for the spike: auto scaling, an active-standby setup with more capacity than on-premises, and disaster recovery.
4. Kept it reversible: everything in infrastructure as code, so anything wrong could be corrected quickly.

R: The AWS version went live for the window. [How it performed in the window, if you know.]
Learning: a failure that repeats every year is a pattern, not bad luck, and the customer's own logs are the first place to look.

Trade-offs, if he probes: replatform over rehost (more work, but a copy would fail the same way) and over a rebuild (some old limits stay, but the date couldn't move); a paid standby even with public money, because an outage costs an applicant a whole year; auto scaling over fixed peak capacity, with scaling up on a schedule before the window opens to cover the delay.

S: At Big Beard, alongside the migration, I had to build pipelines for both code and infrastructure, on quarterly deadlines, and it was a big learning curve.
A: I started with the simplest repositories, worked through the first errors one at a time, and built up to every site in its own repository, deploying through dev, SIT and production accounts with OIDC and tests in every environment.
R: Everything was automated, and it turned out to be what made delivery faster.
Learning: now I plan pipelines from day one. [Your current development area, if he asks for one.]

S: At Big Beard I committed to passing the AWS Security Specialty.
A: I did the training and worked hands-on with Security Hub, GuardDuty, Config, KMS and IAM.
R: I didn't pass. My knowledge came from what I'd built, and the exam covers more breadth than my work had touched.
Learning: now I start from the exam guide's domains, find the gaps against my real work, and build labs for them. I've made a study plan, and I still intend to take it. [Target date, if you have one.]

"I'm hard on myself when I don't meet a plan I set. When I didn't pass the Security Specialty, it was the missed plan that bothered me more than the result. [What you actually do about it.] It's also why I follow through: I don't let a plan quietly drop."

Framework: connect, move, transform, prove, govern.

"They make sure data gets from where it is to where it's needed, reliably and governed. That means connecting sources, moving data in batch, as change data capture or as a stream, transforming it, and proving it arrived, through reconciliation and retries that never duplicate. On AWS that's DMS for databases and CDC, DataSync for files, AppFlow for SaaS, Glue for transformation and the catalogue, and SQS, EventBridge or Step Functions to orchestrate it. At the Office of the Premier I helped turn the annual recruitment plan into one system that all 13 departments work from, and 8 of 13 departments moved compute and archiving to AWS. I've run DMS with CDC in my own labs."

Your lab evidence (one sentence, after the answer): "I've also moved Salesforce into S3 with AppFlow on Bulk API 2.0 and reconciled it: 13 departments, 74 contacts and 652 cases on both sides, with every link resolved."
If he probes "what surprised you?" (Dive Deep): "Bulk API returns every value as text, and empty fields as blank strings, so the processing step owns the data types. I kept the raw zone exactly as the source sent it, so it can be replayed when the rules change."

1. Customer context: archive isn't backup or migration; what data there is, and why it's kept.
2. Requirements: how long the law says to keep it, any legal holds, how fast it must come back.
3. Constraints: where it may live (residency), and the volume to move.
4. Architecture: retrieval speed picks the class: Glacier Instant Retrieval for milliseconds, Flexible Retrieval for hours, Deep Archive for compliance archives. Export to open formats like Parquet so the data outlives the old application and Athena can query it in place.
5. Well-Architected: Object Lock, encryption and access logging; a catalogue so it can be found; lifecycle rules for cost.
6. Trade-offs: cheaper classes mean slower retrieval and retrieval fees, so match each class to how fast it must come back.
7. Rollout: move with DataSync, DMS or Snowball depending on volume.
8. Validation: don't switch off the source until a retrieval test is signed off by the owner.

Your example: archiving moved to AWS at the Office of the Premier, and there's an archiving proof of concept under way at the bank.

1. Context and requirements: files or events arrive in bursts; each must be processed exactly once and never lost.
2. Constraints: uneven volume, downstream limits.
3. Architecture: a file lands in S3, which raises an event through EventBridge; SQS buffers bursts, with a dead-letter queue for repeated failures; Step Functions runs each item's steps; small Lambdas do the work; a DynamoDB conditional write stops a duplicate from processing twice.
4. Well-Architected: alarm on the age of the oldest message, not just errors; least-privilege role per function.
5. Trade-offs: a queue adds latency, but it absorbs bursts and makes failure safe.
6. Validation: replay a batch with duplicates and failures, and check every item lands once.

Your example: "I built this shape in my AI landing-page builder: generation took over five minutes behind a 29-second limit, so I moved it onto SQS with dead-letter queues and tracked status in DynamoDB."
Second example, only if Lab 5b is built: "In my Salesforce lab, S3 raises an event through EventBridge, with one rule and one queue per object, so a bad case file can't hold up departments and contacts. The message carries a pointer to the file, not the data."
If it isn't built yet, say: "My Salesforce to S3 leg is built; next I'm putting EventBridge and SQS behind it."

Use D1 below, and the honest line: "two production Bedrock builds; I haven't fine-tuned a model or run a vector-store RAG pipeline in production."

What Jason showed: he took one service from an answer and asked how it works underneath, then went down again. Every answer below has the same five layers, so you can keep going when he does:

1. Answer first (one sentence).
2. Mechanism: what actually happens, step by step, inside the service.
3. The numbers: defaults, limits and the settings you'd change.
4. Failure modes: what breaks, how you'd see it (the metric or error), and what you'd do.
5. Your evidence, and the honest edge.

LLM internals, why Textract, and DNS to browser rendering are already in Jason's file, Part 7. Revise those too.

Answer first: "Retrieve the few passages that are relevant to the question, put them in the prompt, and instruct the model to answer only from them."
Mechanism:

1. Ingest: split documents into chunks (a few hundred tokens each, with some overlap so a sentence isn't cut in half).
2. Embed: an embedding model turns each chunk into a vector, for example Titan Text Embeddings V2 (1,024 dimensions by default). Chunks with similar meaning end up close together.
3. Store: a vector store indexes the vectors: OpenSearch Serverless, Aurora PostgreSQL with pgvector, or S3 Vectors. Store metadata with each chunk (tenant, document, date) for filtering.
4. Query: embed the question with the same model; find the nearest chunks by cosine similarity. At scale this is approximate nearest neighbour (for example an HNSW graph index), trading a little accuracy for speed. Optionally combine with keyword search (hybrid) and a reranker.
5. Generate: put the top few chunks in the prompt with the instruction "answer only from these; say you don't know otherwise; cite the source".
6. Managed version: Bedrock Knowledge Bases does steps 1 to 5: it syncs from S3, chunks, embeds, stores and retrieves.

Failure modes:

• Wrong chunks retrieved: usually chunking. Too big dilutes the meaning; too small loses context. Test retrieval on its own first: did the right chunk come back in the top 5?
• Stale answers: the index wasn't re-synced after documents changed.
• One customer sees another's data: filter on tenant metadata at query time, never only in the prompt.
• It answers anyway: a contextual grounding check in Bedrock Guardrails blocks answers not supported by the retrieved text.

RAG or fine-tuning? RAG for knowledge that changes or must be cited; fine-tuning for a fixed style, format or narrow task, at the cost of retraining whenever things change. Prompting first, RAG second, fine-tuning last.
Your evidence: "TheoFlow uses the same idea without a vector store: the form definition is the retrieved context, and code checks every value exists in the source. I haven't run a vector-store RAG pipeline in production."

Answer first: "Against a fixed test set with known answers, measured per field, run again every time the model or prompt changes."
Mechanism:

1. A golden set: real documents with the correct output written by a person.
2. Metrics per field: correct, wrong, or sent to a person. "Wrong but confident" is the one that matters most, because it's silent.
3. For free text: an LLM as judge with a scoring rubric, checked against human scores on a sample. Bedrock Evaluations can run both automatic and human evaluations.
4. Regression: the same set on every prompt or model change, before it ships.

Failure modes: a test set that doesn't look like production (only clean scans); one accuracy number that hides the dangerous errors.
Your evidence: "In TheoFlow, 58 of 58 fields on one form and 41 of 43 forms. That's validation, not an accuracy rate. And Sonnet 4.5 is now in legacy, so the migration to the next model will be exactly this: the same forms through both, field by field, before switching."

Answer first: "Don't trust the model: constrain its output, check it in code, and route uncertainty to a person. Then guardrails on top."
Mechanism:

1. Structured output: a fixed JSON schema, validated in code.
2. Values must exist in the source: code checks every extracted value against the text.
3. Read twice and compare: disagreement goes to a person.
4. Bedrock Guardrails:
   - content filters;
   - denied topics;
   - sensitive information filters, which mask or block PII such as ID numbers;
   - the contextual grounding check, which scores grounding and relevance against thresholds.
   The ApplyGuardrail API runs them on any text, even outside Bedrock models.
5. Data: Bedrock doesn't use prompts or outputs to train models, and doesn't share them with the model providers.

Your evidence: steps 1 to 3 are TheoFlow.

Answer first: "We've hit the model's quota in that Region, measured in requests and tokens per minute."
Mechanism and fixes:

1. Quotas are per model, per Region: requests per minute and tokens per minute. Over them, Bedrock returns ThrottlingException.
2. Retry with exponential backoff and jitter (the SDKs do some of this).
3. Smooth the demand: put a queue in front and cap concurrency, so bursts wait instead of failing.
4. Cross-Region inference profiles spread requests over several Regions in the same geography (check that this is acceptable for the data).
5. Request a quota increase, or provisioned throughput for guaranteed capacity.

Your evidence: "On the page builder I capped the SQS trigger's concurrency to protect Bedrock's quota."

Answer first: "DMS reads the database's own transaction log, so it captures every change without querying the tables."
Mechanism:

1. Full load: DMS copies the existing rows table by table, and caches the changes that happen meanwhile.
2. Apply cached changes, then ongoing replication from the log.
3. For MySQL or MariaDB: the source needs binary logging on, binlog_format = ROW and binlog_row_image = FULL. Binlogs must be kept long enough for DMS to catch up after a pause (on RDS, set binlog retention hours).
4. LOBs: limited LOB mode (fast, truncates above a size you set) or full LOB mode (slow, complete).
5. Data validation compares source and target rows after the load.

Failure modes:

• Replication lag: watch CDCLatencySource and CDCLatencyTarget.
• Binlogs purged before DMS read them: the task fails and you reload.
• The endpoint can't connect: a network path problem. That's my own story.

Your evidence: "My DMS lab: MariaDB into RDS with CDC. The first connection test timed out because DMS sat in a private subnet whose default route pointed at the internet gateway; I added a NAT."

Mechanism and the numbers:

1. Lambda polls the queue for you, with long polling (up to 20 seconds), and invokes your function with a batch: up to 10 messages by default, more with a batching window.
2. A received message becomes invisible for the visibility timeout (30 seconds by default). If the function doesn't finish, the message reappears and is retried. Set the visibility timeout to at least six times the function timeout.
3. Delivery is at least once: a standard queue can deliver a message twice, so the consumer is idempotent (a conditional write keyed on the message's business ID).
4. Partial batch failure: the function returns the IDs that failed (ReportBatchItemFailures), so only those retry, not the whole batch.
5. Dead-letter queue: after maxReceiveCount failed receives, the message moves to the DLQ for inspection and redrive.
6. Retention: 4 days by default, up to 14. FIFO queues keep order per message group and remove duplicates within a 5-minute window.
7. Scaling: Lambda adds pollers as the queue grows. Maximum concurrency on the event source caps it to protect a downstream.

Failure modes:

• Visibility timeout shorter than the work: duplicates and retry storms.
• One poison message: without partial batch failure, it retries the whole batch.
• Alarm on ApproximateAgeOfOldestMessage, not only on errors: a stuck consumer throws no errors.

Answer first: "Start from the questions the business asks, decide the grain, then a star schema: one fact table of events or measures, with dimension tables around it."
Mechanism:

1. Grain: what one row of the fact table means, for example "one form submission". Decide this first.
2. Fact table: measures and keys, for example time to process and fields corrected.
3. Dimensions: who, what, when and where: client, form, date, broker. Descriptive and denormalised.
4. History: a slowly changing dimension type 2 keeps old versions with valid-from and valid-to dates, so last year's report doesn't change when a broker moves branch.
5. Operational versus analytical: operational systems are normalised (third normal form) or modelled per access pattern (DynamoDB); analytics is denormalised for fast reads.

Your evidence: "TheoFlow's correction records would be the fact table for measuring the 11 hours: one row per field corrected."

1. "You interview for many teams. What separates the SAs who do really well in their first year from those who struggle?"
2. "Which Leadership Principle do new hires underestimate most?"
3. "What's a mechanism at Amazon that changed how you work?"

Still to fill before Wednesday: L16 rework cost (the error is now described in L16's first probe: storage-full, FreeStorageSpace, disk-full); L7 number; HF1's result and learning, and who raised it; Isiqalo's result in the window; F1 current area; F2 date; F3 what you do.