Student Notes — Chapter 10: Your roadmap: learn it, explain it, get hired

AWS in Action: AI edition · Chapter 10

Before you start

Nothing to install or prepare. This is a concept chapter: you build nothing and deploy nothing. Have paper or a notes app open, because the Flashcards, the Practice and the Model answer ask you to write and say things in your own words.

Summary

This chapter turns the eight chapters you built into something you can keep learning from and something you can say out loud. It shows how to rebuild the helpdesk and change one part at a time so you learn why it works, and it describes four kinds of interview challenge that people who build with models may meet. It argues, as the teacher’s view, that explaining a project clearly matters more than how much you built, and it gives you a four-beat order for walking an interviewer through the helpdesk, with the chapter that holds each answer. It also reports what one survey and one company say about working with models and about interviews, and ends with your next three steps. No job is promised: the chapter prepares you to explain your work, nothing more.

Key concepts

Term	Definition
Rebuilding	Building a system you have built before, again from an empty account, to find out what you can do without the instructions in front of you.
Changing one part at a time	Altering a single piece of a working system, running the checks, and noting what moved, so a different result has one possible cause.
Interview challenge	A question or task set so the interviewer can watch how you think, as well as what you know.
Explaining a project	Telling someone who was not there what problem a project solves, how it works, why you chose each part, what went wrong and what you would change.
Walk-through	A spoken tour of a project in an order a listener can follow: the problem, one request’s path, how it is kept safe and running, and what went wrong.
Beat	One named point an answer must make, taken in a set order. This chapter’s answer has four.
Follow-up question	The next question an interviewer asks after your walk-through, such as how you stopped it making things up or what happens when it cannot settle a case.
Project note	A one-page summary of a project: the problem, the picture, one failure and one change.
Reviewing a model’s output	Reading what a model produced, finding what is wrong, and saying what you would check before anyone relies on it.

Explanations

Orientation: what you built

You have built one thing across eight chapters: a company IT helpdesk assistant. This chapter builds nothing. Think of it as the walk back through a house you finished: the rooms are built, and the question now is how to describe it to a visitor. The whole system, as on the AWS platform, is below. Each box carries the chapter that built it, and nothing is new in this chapter.

Here is each box in everyday words:

Boxes	In everyday words
CloudFront, S3	The front door and the notice board: the chat page sits in S3 and CloudFront hands it to the employee
API Gateway, Lambda	The reception desk and the person behind it: one takes the question in, the other is the helpdesk code
Bedrock model, Knowledge Base	The writer and the librarian: the model writes the reply, the Knowledge Base finds the right IT page
DynamoDB, SNS	The ticket book and the bell: tickets are saved in one, IT staff are emailed by the other
Cognito, Guardrails	The badge reader and the house rules: who may ask, and what may go in or come out
GitHub Actions, CloudFormation, CloudWatch	The builder and the dashboard: they set the system up the same way each time and show how it is running

Try this first: a hiring manager says, “Tell me about a project you built with a model.” You could list the services you used in order, say what problem it solves and then follow one question through the picture, or say an assistant helped and offer the code. Pick one and say why. The chapter gives you a way to answer.

The chapter has six parts: keep learning by rebuilding; interview challenges; why explaining beats volume; walk through the helpdesk; how interviews are changing; and your next three steps. By the end you can:

• plan one change to the helpdesk, say what you expect and how you would check it;
• walk an interviewer through the helpdesk in four beats, naming what each chapter added;
• answer a follow-up question by naming the chapter that holds the answer.

Part 1. Keep learning by rebuilding

Cook a dish from a recipe and it usually works. Cook it again a week later without the recipe and you find the steps you merely followed: the pan temperature, the order of the onions. Then change one ingredient and you learn what it does. A mechanic learns an engine the same way, by stripping it and putting it back, not by looking at the diagram.

That is the idea of rebuilding: building a system you have built before, again from an empty account, to find out what you can do without the instructions in front of you. Changing one part at a time goes with it: alter a single piece, run the checks, note what moved. Each build chapter in this course ended by deleting what it made, so starting from an empty account is something you have already done once.

Here are changes that fit the helpdesk, each with what to watch for:

Change one part	What you watch for	Comes from
Swap the IT pages for your own	Whether the answer names the right page	Chapter 4
Add one more kind of ticket	Whether the model picks the right tool	Chapter 5
Change what makes the triage loop hand over	Which cases reach a person	Chapter 6
Add one more secret pattern or blocked topic	Whether it is masked or blocked, and normal questions still pass	Chapter 7
Add one question to the quality check	Whether a bad change now fails the run	Chapter 9

Why one change and not five? A second picture: a doctor who changes one medicine at a time can tell which one helped. With five changes at once, a better or worse result has five possible causes, and the checks tell you much less. Writing down what you expect first is the other half: when the result differs, you have found something you had misunderstood. Try one now: pick a row, write what you expect, and say how you would check it.

Remember: predict, change one part, compare. Following steps shows that it works; rebuilding and changing shows why. Delete what you create when you finish.

Part 2. Interview challenges

A driving test does not ask you to recite the road signs. The examiner sits beside you and watches your decisions at each junction. A trial shift in a kitchen works the same way: the head chef watches how you handle a busy order and a mistake. An interview challenge is a question or task set so the interviewer can watch how you think, as well as what you know.

In the teacher’s view, four kinds of challenge cover much of what people who build with models may meet. The mix differs by company, so ask what the format is.

Challenge	What the interviewer looks for	Helpdesk example
Explain a project you built	That you understand it and can say it in order	Walk through the helpdesk, question to running system
Design out loud	How you split a problem and choose between options	“Design an assistant that answers IT questions”
Review a model’s output	Whether you find what is wrong and say what to check	A reply that says “Done!” when nothing was done
Work with an assistant live	How you direct it, check it and fix its output	Ask it for a new ticket field, then check the result

The third kind connects to chapter 1. A model can write a confident reply that is wrong, so reviewing its output means reading it the way a person on the desk would: what is claimed, what was it not shown, what would I check against the source? A second way to see it: a proofreader does not trust a page because it reads smoothly.

Why do interviewers care about checking? Here is what one survey found. Stack Overflow’s 2025 developer survey, as published by Stack Overflow, reports that 84% of respondents use or plan to use AI tools in their development process. It also reports that more developers distrust the accuracy of AI tools (46%) than trust it (33%), and that 66% name “AI solutions that are almost right, but not quite” as their biggest frustration. The survey counts the developers who answered, it is not a count of the whole field. Reading it as the teacher’s view: using a model is common, so using one proves little, and checking it is where a builder can show judgement. That reading is an opinion, not a result of the survey.

Part 3. Why explaining beats volume

Picture two house tours. In the first, the guide reads out the building materials: bricks, tiles, pipes. In the second, the guide walks you from the front door, room by room, saying what each is for. Tomorrow you remember the second. Explaining a project is the second kind of tour: telling someone who was not there what problem it solves, how it works, why you chose each part, what went wrong and what you would change. A chef describing a dish does the same: what is on the plate and why it is made that way, as well as the ingredient list.

The failure comes first, because it is easy to fall into. Three illustrative exchanges, written for these notes.

Situation 1: the wall of services.

Interviewer: Tell me about your project.
Candidate:   Lambda, Bedrock, S3, CloudFront,
             DynamoDB, SNS, Cognito, CloudWatch.
Interviewer: Why DynamoDB for the tickets?
Candidate:   It was in the tutorial.

The interviewer learns what you touched, not what you understand. The cause: the story named boxes with no problem, no path and no reason for any choice.

Situation 2: the assistant wrote it.

Interviewer: Did you write the guardrail rules?
Candidate:   The assistant wrote most of it.
Interviewer: What did you check?
Candidate:   It ran, so it was fine.

The interviewer cannot tell which part you understand. The cause: the story said what produced the work, not what you checked or changed.

Situation 3: it worked the first time.

Interviewer: What went wrong while you built it?
Candidate:   Nothing. It all worked first time.
Interviewer: Nothing at all?

The interviewer starts to doubt you built it. The cause: a story with no failure in it sounds untried. A failure, its cause and the fix show real work. This course has several: a confident wrong reply in chapter 1, and an endpoint that had no sign-in until chapter 7.

The same shape in everyday life:

Everyday situation	What the listener ends up with
A guide names each brick and does not walk you through the rooms	A list, and no idea what the house is for
A mechanic reads out the parts fitted and does not say what was wrong	A bill, and no reason to trust the repair
A doctor reads out each test value and gives no diagnosis	The numbers, and not their meaning

Why it happens: the speaker remembers the parts, not the reasons for them; the reasons are exactly what the listener cannot see; and a story with a problem and a path carries them. For the helpdesk, say “employees waited for IT to reply”, not “Lambda, Bedrock, S3”.

What this means for your project story:

What went wrong in the answer	What to do instead	Material to draw on
A wall of service names	Open with the problem; name a service together with its job	Chapters 2 to 9
“The assistant wrote it”	Say what you asked, what you checked, what you changed	Chapters 1 and 9
No failure story	Bring one thing that went wrong, its cause and the fix	Chapters 1, 4 and 6

In the teacher’s view, a small project you can explain well shows more than a large one you cannot. That is an opinion, not a measured result. The reason behind it is simple: the interviewer cannot see your account and hears what you say, so the explanation is where your understanding shows.

Part 4. Walk through the helpdesk

The walk-through uses the eight chapters you built. Here they are in one picture: the top frame answers and acts, the bottom frame makes it safe, ships it and runs it.

Chapters 2 to 5, what each added and one line to say about it:

Chapter	What it added	One line to say
2	An ask endpoint: a Lambda function that sends the question to a hosted model through Bedrock Converse	One endpoint turns a question into an answer
3	A chat page in a private S3 bucket, served by CloudFront	Employees reach a page; the bucket itself stays private
4	A Knowledge Base over the IT pages; the answer cites the page	The answer comes from our pages and shows which one
5	Tickets in DynamoDB, opened and read through tool use	The model asks for an action; our code does it

Chapters 6 to 9:

Chapter	What it added	One line to say
6	A triage loop that escalates by email through SNS	Hard cases reach a person
7	Cognito sign-in with employee and IT-staff roles; Guardrails that mask secrets and block off-topic questions	We know who asks, and set rules on what goes in and out
8	GitHub Actions: tests, then staging, then prod, with an OIDC deploy role	A push passes tests and staging before prod
9	Logs, a dashboard, an alarm, a cost-per-ticket formula, a quality check, teardown	We watch it, price it, test it after each deploy, and can delete it

Now the order to tell it in. It is not the order you built it in; it is the order that makes sense to a listener, like a tour that starts at the front door.

1. The problem. Who has it and what it costs them: employees waiting for IT to reply to the same questions.
2. The path. One question followed from the chat page to the reply, naming what chapters 2 to 6 added: the ask endpoint, the page, the answer from the IT pages with a cited page, a ticket, and the triage loop that emails a person.
3. Safe, shipped, watched. What chapters 7 to 9 added: roles and Guardrails, tests then staging then prod, and logs, an alarm, a cost formula and a quality check.
4. What went wrong and what next. One failure and one change you would make.

Then the interviewer’s follow-ups come. Know which chapter holds each answer:

A likely follow-up	Where your answer lives
“How do you stop it making things up?”	Chapter 4: it answers from the IT pages and cites one
“What if it cannot settle a case?”	Chapter 6: the triage loop and the escalation email
“What if someone pastes a password?”	Chapter 7: Guardrails mask it
“Does that cover the pages it looks up?”	Chapter 7: it checks input and reply, not retrieved pages
“How do you know a change did not make it worse?”	Chapters 8 and 9: tests, staging and the quality check
“What does one ticket cost?”	Chapter 9: the formula, with the current price page

Two of these rest on the vendor’s own documentation, read on 2026-10-17. AWS says a Guardrails sensitive-information filter can mask detected sensitive information in a request or a reply, replacing it with its type; it describes the filter as probabilistic and context-dependent, so it can miss a value, and says Guardrails are applied to the input and the generated reply, not to the references a Knowledge Base retrieves at runtime. A good answer to “what does your safety not cover?” says so, and says what else you rely on: sign-in roles, people and the quality check. For the cost question, read the current price page yourself; this course states no price.

Part 5. How interviews are changing

Think of a cooking competition that once banned recipe books and now lets you bring one. The test shifts from “can you remember it” to “can you choose, adapt and check”. Some interviews are shifting in a similar direction.

One company’s stated change is a fact you can cite; the market is not. Canva, in a public engineering post, says it now expects backend, machine learning and frontend candidates to use AI tools such as Copilot, Cursor and Claude in technical interviews. The post says its interviewers look at five things: whether you know when and how to use AI well, how you break down unclear requirements, whether your technical decisions are sound with an assistant in the loop, whether you can find and fix problems in AI-written code, and whether the result is good enough for production. Notice how close these are to the third and fourth challenges in Part 2.

That is one company. In the teacher’s view, rules differ by company and change, so ask the recruiter what is allowed before the interview. If an assistant is allowed, the line to hold is whether you can explain each piece you submit.

Right	Wrong
Say what you are about to ask it	Paste its output and move on
Read its output and say what you would check	Present its work as your own
Fix one thing it got wrong, and say why	Use it when the interviewer said not to
Say so when you are unsure	Accept an answer you cannot explain

Part 6. Your next three steps

A runner who plans a marathon in one go often does not start; a runner who plans one short run tomorrow does. Three small steps you can repeat:

1. Rebuild one chapter from an empty account, from memory first; look up just what you cannot recall.
2. Change one part, write what you expect, then compare with what happened.
3. Say the walk-through aloud, then write a one-page project note: the problem, the picture, one failure, one change.

Small steps you repeat beat a plan too big to start.

Practice: walk through the helpdesk

Write your four-point answer to “Walk me through a project you built with a model”, then say it aloud from start to finish, and check it against the Model answer below.

1. One sentence on the problem and who has it.
2. Follow one question through chapters 2 to 6.
3. Name what chapters 7 to 9 added.
4. Give one failure and one change.
5. Pick two follow-ups from the table in Part 4 and answer each in one sentence.

Phrases that signal real understanding, and phrases that signal a surface reading:

Do say	Don’t say
“Employees waited for a first reply, so I built…”	“I used Lambda, Bedrock, S3 and…” with nothing after
“It answers from our IT pages and shows which page”	“It just worked”
“A person gets an email when it cannot settle a case”	“The AI did most of it”
“The assistant wrote that part; I checked it by…”	“It does not get things wrong”
“One thing went wrong: … and I changed…”	“I built each part with no help”

Flashcards

Say the answer aloud before revealing it. Speaking is a different skill from reading, so practise both.

1. What is rebuilding, and why do it?

Rebuilding is building a system you have built before, again from an empty account, without the instructions in front of you. It shows which steps you merely followed, so you find the gaps in what you understand.

2. Why change one part at a time instead of several?

With one change, a different result has one possible cause. With several changes at once you cannot tell which one helped or hurt, so the checks tell you much less.

3. Why write down what you expect before you change something?

When the result differs from your prediction, you have found something you had misunderstood. Without the written prediction you tend to explain the result away afterwards.

4. What is an interview challenge, and what is it testing?

It is a question or task set so the interviewer can watch how you think, like a driving test that watches your decisions, as well as your knowledge of signs. The answer matters and so does the way you reach it.

5. Name the four kinds of challenge from this chapter.

Explain a project you built, design out loud, review a model's output, and work with an assistant live. The mix differs by company, so ask the recruiter what the format is.

6. What does Stack Overflow's 2025 survey say that matters here, and what is its limit?

It reports that 84% of respondents use or plan to use AI tools, that 46% distrust the accuracy of AI tools against 33% who trust it, and that 66% name answers that are almost right but not quite as their top frustration. It counts the developers who answered, it is not a count of the whole field.

7. Why does a list of service names make a weak answer?

It tells the interviewer what you touched but gives no problem, no path and no reason for any choice, so they cannot tell what you understand. A guide who reads out the bricks leaves you with no idea what the house is for.

8. What are the four beats of the walk-through, in order?

The problem and who has it; the path of one question through chapters 2 to 6; what made it safe, shipped and watched in chapters 7 to 9; and one thing that went wrong with one change you would make.

9. What does Guardrails not cover, according to AWS's documentation?

AWS says Guardrails are applied to the input and the generated reply, not to the references a Knowledge Base retrieves at runtime. It also describes the sensitive-information filter as probabilistic, so it can miss a value, which is why people and checks stay in the loop.

10. What does one company's post say about assistants in interviews, and how far does it reach?

Canva says it now expects backend, machine learning and frontend candidates to use AI tools in technical interviews, and its interviewers look at how well you use them and fix their output. That is one company's stated policy, not a market-wide fact, so ask each recruiter what is allowed.

Model answer

The core question this chapter answers: “Walk me through a project you built with a model, from the first request to keeping it running.”

Four things an interviewer listens for, in this order: the problem · the path · safe, shipped, watched · what went wrong and what next. Skip any of these four and the answer is incomplete.

1. The problem — who has it and what it costs them
2. The path — one question followed through chapters 2 to 6
3. Safe, shipped, watched — what chapters 7 to 9 added
4. What went wrong and what next — one failure and one change

The full answer, said aloud:

(The problem) “Employees waited for IT to reply to the same questions, and hard cases got lost in email.

(The path) A question goes from a chat page to a Lambda function and a model that answers from our IT pages and cites one. It can open a ticket, and a triage loop emails a person when it cannot settle a case.

(Safe, shipped, watched) Sign-in sets roles, Guardrails mask secrets and block off-topic questions, a push passes tests and staging before prod, and logs, an alarm and a quality check watch it.

(What went wrong and what next) A confident wrong answer was the failure, and answering from our pages fixed it. Next I would add more questions to the quality check.“

Missing a point is a failure state. The follow-up lands where you went quiet: leave out the failure and the next question is “what went wrong?”; leave out the safety and it is “what if someone pastes a password?”. Practise until the four come out without prompting, then stop talking and let the questions come.

Why this matters

In an interview: a hiring manager who asks about a project is listening for a problem, a path, the safety around it and a failure you learned from. The four-beat order gives you that shape, and the helpdesk gives you concrete material for each beat.

On the job: a design review, a growth conversation with a manager and a new-team introduction ask versions of the same question: what did you build, why, and how do you know it works? The follow-up table tells you which chapter holds each answer.

In your own learning: rebuilding and changing one part at a time is how you keep going once the chapters end, with no instructions and no one marking the result.

After this unit

Assignment. The chapter project asks you to write your one-page project note and the spoken four-beat walk-through, and to name the chapter behind each follow-up answer. The brief itself is the project file.

What’s next. This is the last chapter. Your next three steps are the ones in Part 6: rebuild one chapter, change one part and compare, and say the walk-through aloud. Keep your project note: it is the start of your own portfolio.