Responsible AI: Features, Guardrails, and Legal Risk

Certification Blueprint

Field	Coverage
Exam	AWS Certified AI Practitioner (AIF-C01), exam guide v1.1
Domain	Content Domain 4 — Guidelines for Responsible AI
Exam weight	14% of scored content
Task statement	4.1 Explain the development of AI systems that are responsible
Objectives	4.1.1 features of responsible AI · 4.1.2 tools to identify those features · 4.1.3 responsible practices to select a model · 4.1.4 legal risks of working with GenAI

What This Chapter Covers

Twelve chapters have been spent making a model that works. Chapter 08 selected it, Chapter 10 prompted it, Chapter 09 grounded it, Chapter 11 tuned it, and Chapter 12 proved it earned its place.

Not one of them asked whether it should have been built that way.

That question is Domain 4, and it is worth being blunt about why it is examinable at all. Responsible AI on this exam is not a statement of values. It is a list of named properties, each of which has an observable failure, plus a tool that evidences some of them, plus a list of what their absence costs a business. Every one of those is a testable fact.

The single habit this chapter builds: name the property, not the sympathy. Every option in every question here will describe something undesirable. The marks go to the one the guide actually names.

Task 4.1 has seven objectives, the most of any task statement in the guide. This chapter takes the first four — what responsible AI is, the tool that evidences it, how it enters model selection, and what its absence costs. Chapter 14 takes objectives 5-7, which are the measurement half: dataset characteristics, the effects of bias and variance, and the detection tooling.

The Features of Responsible AI

Objective 4.1.1 names six: bias, fairness, inclusivity, robustness, safety and veracity.

Learning them as a list is close to useless. The exam does not ask you to recite six words; it describes a system behaving badly and asks which property that is. So learn each one as the observation that would reveal it.

What to remember from this diagram: every branch ends in something you could observe. If you cannot say what you would look at to detect a violation, you have named a value rather than a feature — and the exam only tests the features.

Feature	What it is	What you would observe when it fails
Bias	Systematic skew in the system's outcomes	Outcomes differ by group in a way the individual records do not explain
Fairness	The standard by which a skew is judged unjust	A group is disadvantaged relative to a standard the organisation accepts
Inclusivity	Whether the full range of intended users can actually use it	Users excluded by language, accessibility, access or assumption
Robustness	Whether behaviour holds up on inputs it did not expect	Quality collapses on edge cases, noise, unusual formatting or adversarial input
Safety	Whether the system can cause harm	Harmful, dangerous, abusive or prohibited output reaches a user
Veracity	Whether what it says is true	Confident, fluent output that is not correct

Bias and fairness are not the same word

This is the distinction the exam most reliably tests inside Objective 4.1.1, and candidates routinely treat the two as synonyms.

• Bias is the measurement. It is the skew itself — an observable difference in outcomes across groups. You can compute it.
• Fairness is the standard. It is the judgement about whether a given skew is acceptable. You cannot compute it; you have to decide it.

The practical consequence is that a system can be biased without anyone having agreed it is unfair, and it can be judged unfair on a skew that is small. A scenario that says "outcomes differ by group" is describing bias. A scenario that asks "is this difference acceptable?" is asking about fairness.

⚠️ Where the boundary sits: this chapter names bias as a feature whose absence is a risk. How anyone would prove bias exists — dataset balance, subgroup analysis, SageMaker Clarify, Model Monitor, Amazon A2I — is Chapter 14, Objectives 4.1.5 through 4.1.7. If a question asks what tool measures bias across demographic groups, that is next chapter's material.

Safety and veracity are also different, and often confused

Both describe bad output, which is why they blur.

• Safety is about harm: the output is abusive, dangerous, or in a category the application should refuse.
• Veracity is about truth: the output is wrong.

A model that confidently states an incorrect drug interaction has a veracity failure. If a user then acts on it and is harmed, the harm is a separate consequence — and in the guide's vocabulary that consequence has its own name, end user risk, which is Objective 4.1.4's material rather than 4.1.1's. Keeping those two apart is worth real marks.

Inclusivity and robustness

These two are the least-studied of the six and appear in scenarios more often than candidates expect.

Inclusivity asks whether the people the system is for can actually use it. A model that handles only one language well, or assumes a level of literacy or connectivity its users do not have, has an inclusivity problem even if it is perfectly accurate for the users it does serve.

Robustness asks whether behaviour survives contact with reality. Real input contains misspellings, mixed languages, odd formatting and occasional deliberate attack. A model that performs well on clean input and erratically on messy input is not robust — and note that this is about stability under unexpected input, not about being wrong, which would be veracity.

Using Tools to Identify These Features

Objective 4.1.2 is short and specific: explain how to use tools to identify features of responsible AI, with Amazon Bedrock Guardrails as the named example.

The word doing the work is identify. The objective is not "have good intentions" — it is turning a stated standard into something a system enforces and you can point at.

Amazon Bedrock Guardrails

Bedrock Guardrails evaluates what goes into a model and what comes out of it against policies you configure, blocking or filtering anything the policy prohibits.

What to remember from this diagram: Guardrails sits at two points, not one. It evaluates the input before the model is called and the output before the user sees it. That two-sided placement is the detail exam questions are built on — a guardrail that only inspected output would be unable to stop a prohibited request from ever reaching the model.

Policy type	What it does	Feature it evidences
Content filters	Filters hate, insults, sexual content, violence and misconduct at configurable strength	Safety
Denied topics	Defines subjects the application will not engage with at all	Safety
Word filters	Blocks specific words and phrases, including profanity and competitor terms	Safety
Sensitive information filters	Detects and masks or blocks personally identifiable information	Safety, privacy
Contextual grounding check	Checks whether a response is actually supported by the source material provided, and whether it is relevant to the query	Veracity

The contextual grounding check is the veracity policy

Of the five, this is the one worth knowing precisely, because it is the only one that addresses truth rather than harm.

It evaluates two things: whether the response is grounded in the source material supplied to the model, and whether it is relevant to the query asked. A response that is fluent, harmless, and unsupported by the source fails it.

This is the connective tissue back to Chapter 09. RAG supplies source material; the grounding check verifies the model actually used it. Retrieval alone does not guarantee grounding — it only makes grounding possible.

What Guardrails does not do

Worth stating explicitly, because a very reliable distractor is built on over-claiming it:

• It does not measure bias across demographic groups. No guardrail policy computes subgroup outcome differences. That is Chapter 14's tooling.
• It does not assess inclusivity or robustness. Nothing in the policy list examines whether users are excluded or whether behaviour holds up on unusual input.
• It does not retrain or modify the model. It sits around the model, evaluating traffic. The weights are untouched.
• It does not document the model. Recording intended uses and limitations is a Model Card, which is Chapter 15's material.

The one-line version: Guardrails evidences safety and veracity. For bias and fairness you need the detection tooling in Chapter 14; for transparency you need the documentation tooling in Chapter 15.

Three places "guardrails" appears in this exam

The word is genuinely overloaded across the guide, and knowing which sense a question means is worth marks.

Where	Sense	Chapter
Objective 3.2.3	"Guardrails" as one named benefit of good prompt engineering — constraining a model through how you ask	Chapter 10
Objective 4.1.2	Amazon Bedrock Guardrails as a responsible-AI tool that evidences safety and veracity	This chapter
Objective 5.1.1	Bedrock Guardrails as a security control, beside IAM, encryption and PrivateLink	Chapter 16

Same service in the last two rows, examined for different reasons. A question's domain framing tells you which answer it wants.

Responsible Practices to Select a Model

Objective 4.1.3 is the objective candidates skip, and it is the shortest to learn: define responsible practices to select a model, with environmental considerations and sustainability as the named examples.

Take that at face value. On this exam, sustainability is a stated model-selection criterion, sitting beside cost, latency and capability rather than after them as a corporate footnote.

What to remember from this diagram: the responsible screen runs after capability and cost, not instead of them. A model that cannot do the job is not made acceptable by being efficient. But among models that all meet the requirement, efficiency is a legitimate and examinable reason to choose between them.

Practice	The reasoning
Prefer the smaller model where it is sufficient	Energy and compute scale with model size. If a smaller model meets the requirement, the larger one spends more for no gain
Adapt rather than train	Training is by far the largest energy cost in a model's life. Prompting, RAG or fine-tuning an existing model avoids repeating it — the Chapter 09 cost ladder read environmentally
Consider the provider's position	Infrastructure efficiency and energy sourcing differ between providers and regions
Document the rationale	A selection you cannot explain is not a responsible practice, whatever it selected

Notice how much of this you already know. Chapter 09's customization cost ladder — in-context learning, RAG, fine-tuning, distillation, pre-training, ordered by cost — is also ordered by energy. The same reasoning that says "do not fine-tune when prompting would do" is the sustainable answer. The exam is asking you to read a familiar ladder along a second axis.

Legal Risks of Working with Generative AI

Objective 4.1.4 names five: intellectual property infringement claims, biased model outputs, loss of customer trust, end user risk, and hallucinations.

The framing matters more than the list. These are business exposures, not technical failure modes. The exam is asking what the organisation is exposed to — not what the model did wrong. A candidate who reads this objective as a list of bugs will misclassify most of its questions.

What to remember from this diagram: the five sort by where the exposure enters — what went in, what came out, or what someone did with it. That grouping is what lets you classify a scenario quickly instead of matching keywords.

Risk	What it is	The signal in a scenario
Intellectual property infringement claims	Training on or generating material that reproduces protected work	Copyrighted text, images, code or brand material appearing in training data or output
Biased model outputs	The model produces outcomes that disadvantage a group	Differential treatment visible in what the model produces
Hallucinations	Confident, fluent, untrue output	The output was wrong, and nothing in the system said so
End user risk	A user acts on output in a setting where being wrong has consequences	Medical, legal, financial or safety-critical reliance on an answer
Loss of customer trust	The accumulated business consequence of the others	Users disengage, churn, or stop believing the product

Hallucination is on this list on purpose

A hallucination looks like an accuracy problem, and accuracy was Chapter 12's subject. So why does it reappear as a legal risk?

Because a confident untruth that a user acts on creates exposure for the organisation that published it. The technical event is a wrong answer; the legal event is that someone relied on it. Chapter 12 asks how would you know the model is wrong. This objective asks what does it cost you when it is wrong and nobody caught it.

That is also why hallucinations and end user risk so often appear together — they are the two ends of one incident. The model produced a confident untruth (hallucination) and a user acted on it in a consequential setting (end user risk).

Loss of customer trust is the accumulator

Of the five, this one is different in kind: it is not a distinct failure so much as what the other four turn into over time. Infringement, bias, hallucination and end-user harm all end in the same place if they are not addressed.

It is listed separately because it is the consequence that survives the incident. A single hallucination is fixable; the belief that the product cannot be trusted is not fixed by fixing the hallucination.

The Features and the Risks Are One List, Read From Two Ends

This is the chapter's spine and worth holding as a single picture.

What to remember from this diagram: Objective 4.1.1 and Objective 4.1.4 are not two topics that happen to sit in one task statement. 4.1.1 names the properties; 4.1.4 names the price of not having them. Learn the mapping and both objectives become one piece of knowledge — and questions that describe a harm and ask for the feature, or describe a feature gap and ask for the risk, become the same question.

Decision Rules and Exam Signals

Rule 1 — name the property, not the sympathy. Every option will describe something bad. Marks go to the one the guide names.

Rule 2 — bias is the measurement, fairness is the standard. Outcomes differ by group → bias. Is that difference acceptable → fairness.

Rule 3 — safety is about harm, veracity is about truth. A wrong answer is veracity. A dangerous answer is safety. They can occur together and are still two properties.

Rule 4 — robustness is stability under unexpected input, not correctness. Erratic on messy input → robustness, even if the answers are also wrong.

Rule 5 — Guardrails evidences safety and veracity, and nothing else. If a question asks it to measure bias, that is the distractor.

Rule 6 — the contextual grounding check is the veracity policy. Supported by the source, and relevant to the query.

Rule 7 — Guardrails evaluates at two points, input and output. A single-sided description is incomplete.

Rule 8 — sustainability is a real selection criterion here. Not a footnote, and not disqualified by sounding non-technical.

Rule 9 — the responsible screen runs after capability and cost, among options that all already work. It never rescues a model that cannot do the job.

Rule 10 — the legal risks are business exposures. The question is what the organisation is exposed to, not what the model did.

Rule 11 — hallucination and end user risk are the two ends of one incident. Confident untruth produced; user acted on it.

Rule 12 — loss of customer trust is where the other four end up. It accumulates; it is not a separate incident type.

Distractor Patterns

Pattern	What it looks like	How to defuse it
Bias and fairness used interchangeably	Both offered as though either would do	Bias is the measurable skew; fairness is the judgement about it
Safety offered for a truth problem	"The answer was wrong, so the system is unsafe"	Wrong is veracity. Safety is about harm, which may or may not follow
Veracity offered for an instability problem	Erratic output on odd formatting called an accuracy failure	Instability under unexpected input is robustness
Guardrails over-claimed as a bias tool	"Use Guardrails to demonstrate the model is unbiased"	No policy measures subgroup outcomes; that is Chapter 14's tooling
Guardrails described as retraining the model	"It removes the behaviour from the model"	It evaluates traffic around the model; weights are untouched
Guardrails described as output-only	Filtering the response, with no input evaluation	It evaluates both sides; input evaluation can stop the call entirely
Model Cards offered as a guardrail policy	Documentation presented as enforcement	Documentation is Chapter 15; enforcement is Guardrails
Sustainability dismissed as non-technical	Offered and expected to be rejected as a soft concern	Objective 4.1.3 names it explicitly as a responsible selection practice
The bigger model justified as headroom	"Choose the larger one for future requirements"	Where a smaller model suffices, the larger spends more for no gain
A technical fault named instead of the legal risk	"Overfitting" or "robustness failure" offered as a legal risk	The guide's list is business exposures; overfitting is Chapter 14
Hallucination treated as purely an evaluation issue	"That is a Domain 3 accuracy concern, not a legal one"	It is named in 4.1.4; the exposure is a user acting on it
Trust offered as marketing's concern	Presented as reputational rather than examinable	It is one of the five named risks, and the one the others accumulate into

The most reliable marks in this task statement come from the first three rows. All three are answered by asking one question: what exactly is the observation the scenario describes?

Scenario Walkthrough

A national bank deploys a generative assistant that answers customer questions about its lending products. After six months: the assistant quotes eligibility guidance far more conservatively for customers writing in the country's second official language than for those writing in the first; it occasionally states repayment terms that do not exist in any product, fluently and without qualification, and one customer restructured a loan on that basis; its answers about a competitor's products reproduce several sentences verbatim from that competitor's published brochure; and the bank's own review board cannot say why one of two equally capable models was chosen. Complaint volumes are rising and retention in one customer segment has fallen.

Observation	Reading	The named item
Conservative guidance by language group	Outcomes differ systematically by group	Bias (4.1.1) — and biased model outputs as the legal risk (4.1.4)
Second-language customers served worse	The system does not serve its full intended user range	Inclusivity (4.1.1)
States repayment terms that do not exist	Confident, fluent, untrue	Veracity (4.1.1) — and hallucinations (4.1.4)
A customer restructured a loan on that basis	A user acted on it where being wrong has consequences	End user risk (4.1.4)
Reproduces a competitor's brochure verbatim	Protected work reproduced in output	Intellectual property infringement claims (4.1.4)
No recorded reason for the model choice	The rationale was never documented	Fails responsible model selection (4.1.3)
Complaints rising, retention falling	The accumulated consequence of all of the above	Loss of customer trust (4.1.4)

Seven observations, and every one of them maps to something the guide names. Note the shape of the first and third rows: each appears twice, once as a responsible-AI feature and once as a legal risk. That is not double-counting — it is Objective 4.1.1 and Objective 4.1.4 describing the same event from two ends, exactly as the bridge diagram shows.

Note also what this scenario does not contain: any measurement. Nobody has computed the outcome gap by language group, and nothing here tells you whether the training data was balanced. That work — subgroup analysis, dataset characteristics, Clarify, Model Monitor, A2I — is Chapter 14. This chapter gets you as far as naming what is wrong.

Key Concepts

Term	Definition
Responsible AI	The practice of developing and operating AI systems against a set of named, observable properties rather than against intentions
Bias	Systematic skew in a system's outcomes, in which results differ by group in a way the individual records do not explain; the measurable half of the bias/fairness pair
Fairness	The standard against which a measured skew is judged acceptable or not; the judgement half of the pair, which cannot be computed
Inclusivity	Whether the full intended range of users can actually use the system, including across language, accessibility and access
Robustness	Whether a system's behaviour holds up on inputs it did not anticipate — noise, unusual formatting, edge cases and adversarial input
Safety	Whether the system can cause harm; concerned with harmful, dangerous, abusive or prohibited output rather than with truth
Veracity	Whether what the system says is true; concerned with correctness rather than harm
Amazon Bedrock Guardrails	A service that evaluates model inputs and outputs against configured policies, blocking or filtering what the policy prohibits; evidences safety and veracity
Content filters	A Guardrails policy filtering hate, insults, sexual content, violence and misconduct at configurable strength
Denied topics	A Guardrails policy defining subjects the application will not engage with at all
Sensitive information filters	A Guardrails policy detecting and masking or blocking personally identifiable information
Contextual grounding check	The Guardrails policy that checks whether a response is supported by its source material and relevant to the query; the policy that evidences veracity
Environmental considerations	Named in Objective 4.1.3 as a responsible model-selection practice — energy and compute cost weighed alongside capability and price
Intellectual property infringement claims	The legal risk that training data or generated output reproduces protected work without permission
Biased model outputs	The legal risk arising when a model produces outcomes that disadvantage a group
Hallucinations	Confident, fluent and untrue output; named in Objective 4.1.4 as a legal risk because a user may act on it
End user risk	The legal risk arising when a user acts on model output in a setting where being wrong carries consequences
Loss of customer trust	The accumulated business consequence the other named risks produce; listed separately because it survives the incident that caused it

Revision Flashcards

Say the answer aloud before revealing it.

1. Name the six features of responsible AI in Objective 4.1.1. → Bias, fairness, inclusivity, robustness, safety and veracity. Learn each as the observation that would reveal its absence rather than as a word, because the exam describes a system behaving badly and asks which property that is.

2. What is the difference between bias and fairness? → Bias is the measurable skew — outcomes differ by group in a way the individual records do not explain, and you can compute it. Fairness is the standard by which that skew is judged acceptable or not, and it is a decision rather than a computation. A system can be biased without anyone having agreed it is unfair.

3. Distinguish safety from veracity. → Safety concerns harm: the output is dangerous, abusive or in a prohibited category. Veracity concerns truth: the output is wrong. A confidently incorrect drug interaction is a veracity failure; a user being harmed after acting on it is a separate consequence the guide calls end user risk.

4. What does robustness mean here, and what is it easily confused with? → Whether behaviour holds up on inputs the system did not anticipate — noise, misspellings, mixed languages, unusual formatting, adversarial input. It is confused with veracity, but robustness is about stability under unexpected input rather than about being correct.

5. What does Amazon Bedrock Guardrails actually do? → It evaluates inputs before the model is called and outputs before the user sees them, against policies you configure, blocking or filtering anything prohibited. It does not modify the model — it sits around the model evaluating traffic, which is why the weights are untouched.

6. Name the five Guardrails policy types. → Content filters, denied topics, word filters, sensitive information filters, and the contextual grounding check. The first four address safety and privacy; the grounding check is the only one that addresses truth.

7. Which Guardrails policy evidences veracity, and how? → The contextual grounding check. It evaluates whether a response is grounded in the source material supplied to the model and whether it is relevant to the query. It is the connective tissue back to RAG — retrieval makes grounding possible, and this check verifies the model actually used what it was given.

8. Which responsible-AI features can Guardrails not evidence? → Bias and fairness, because no policy computes outcome differences across groups; inclusivity and robustness, because nothing in the policy list examines user exclusion or stability under unexpected input. Bias measurement is Chapter 14's tooling and documentation is Chapter 15's.

9. What does Objective 4.1.3 name as responsible practices for selecting a model? → Environmental considerations and sustainability. In practice: prefer the smaller model where it is sufficient, adapt an existing model rather than training a new one, consider the provider's position, and document the rationale. The screen runs after capability and cost, among options that all already meet the requirement.

10. Why is Chapter 09's cost ladder relevant to sustainability? → Because it is also an energy ladder. In-context learning, RAG, fine-tuning, distillation and pre-training are ordered by cost, and training is by far the largest energy expenditure in a model's life. The same reasoning that says do not fine-tune when prompting would do is the environmentally responsible answer.

11. Name the five legal risks in Objective 4.1.4. → Intellectual property infringement claims, biased model outputs, loss of customer trust, end user risk, and hallucinations. All five are business exposures rather than technical failure modes — the objective asks what the organisation is exposed to, not what the model did wrong.

12. Why is hallucination listed as a legal risk when accuracy was Chapter 12's subject? → Because the technical event is a wrong answer but the legal event is that someone relied on it. Chapter 12 asks how you would know the model is wrong; this objective asks what it costs when it is wrong and nobody caught it. That is also why hallucinations and end user risk so often appear together — they are two ends of one incident.

13. Why is loss of customer trust listed separately from the other four risks? → Because it is what the other four accumulate into. It is not a distinct incident type but the consequence that survives the incident: a single hallucination is fixable, whereas the belief that a product cannot be trusted is not repaired by fixing the hallucination.

14. How do Objectives 4.1.1 and 4.1.4 relate to each other? → They are one list read from two ends. 4.1.1 names the properties; 4.1.4 names what their absence costs. Veracity missing becomes hallucinations; fairness missing becomes biased model outputs; safety or robustness missing becomes end user risk; and all of them eventually become loss of customer trust.

The Five-Beat Answer

The core question this chapter prepares you for: "How would you make sure this AI system is responsible?"

Five beats, in this order. Missing a beat is a failure state — you will be probed on whichever one you skipped.

1. Name the properties you are claiming — bias, fairness, inclusivity, robustness, safety, veracity. Saying "responsible" without naming what you mean is the weak answer's opening, and every follow-up question will expose it.
2. Say what you would observe for each one. A property you cannot detect is a value, not a control. This is the beat that separates a designed answer from a sincere one.
3. Name the enforcement and be honest about its limits — Bedrock Guardrails evaluates input and output for safety and veracity. Say plainly what it does not cover, because volunteering the gap is what makes the rest of the answer credible.
4. Bring it into selection, not just operation — responsible practice includes which model you chose and why, sustainability included, with the reasoning recorded. Most answers treat responsibility as something applied to a finished system.
5. State the exposure in business terms — infringement, biased outputs, hallucination, end user risk, and the trust they accumulate into. This is the beat that turns a technical answer into one an executive can act on.

A strong answer names observable properties and admits what its tooling cannot see. A weak answer says the system was built responsibly and offers a policy document as evidence.

Why This Helps You

On the job: the most common failure here is not an irresponsible system — it is an organisation that cannot demonstrate its system is responsible, because nobody defined the properties concretely enough to observe them. Beats one and two are the entire difference, and they cost nothing to do at design time and a great deal to retrofit.

In interviews: "how would you know if your model were biased?" is a standard question and a sorting one. The strong answer distinguishes bias from fairness, names what would be measured, and says which tool does and does not measure it. Volunteering that Guardrails does not measure bias is a reliable signal of someone who has used it rather than read about it.

On the exam: Domain 4 is 14% of scored content and Task 4.1 is the largest task statement in the guide at seven objectives. The four in this chapter are the ones most often treated as common sense and therefore left unstudied — and because every distractor here also describes something undesirable, common sense is exactly the tool that fails.

Chapter Checklist

• I can name all six features of responsible AI from Objective 4.1.1
• I can state, for each feature, what I would observe when it fails
• I can distinguish bias from fairness and say which one is measurable
• I can distinguish safety from veracity, and both from robustness
• I can explain what inclusivity asks that the other five do not
• I can describe what Bedrock Guardrails does and at which two points it acts
• I can name the five Guardrails policy types
• I can say which policy evidences veracity and what exactly it checks
• I can name the features Guardrails cannot evidence, and which chapter covers them
• I can distinguish the three senses of "guardrails" across Objectives 3.2.3, 4.1.2 and 5.1.1
• I can state the responsible practices for selecting a model, and where the screen sits
• I can explain why Chapter 09's cost ladder is also an energy ladder
• I can name all five legal risks from Objective 4.1.4
• I can explain why hallucination is a legal risk and not only an accuracy problem
• I can explain why loss of customer trust is listed separately from the other four
• I can map each responsible-AI feature to the legal risk its absence produces

After the Chapter

1. Complete student/project.md — parts 46-48 of the AI/ML Decision Sheet you began in Chapter 01. Bring the same sheet; do not start a new one.
2. Take student/quiz.md closed-book, then review the reasoning for every question you guessed, including the ones you got right. Pay particular attention to questions 1, 3 and 5 — each describes an undesirable outcome and asks for a different named property, and missing more than one means the six features have not yet separated in your mind.
3. Open the official v1.1 exam guide's Domain 4 page and confirm you can attach a concept from this chapter to each of the first four bullets under Task Statement 4.1. Note that three further bullets follow — those are Chapter 14, and seeing the split on the page is worth more than reading about it.
4. Next: Chapter 14 — Bias, Variance, Datasets, and the Tools That Detect Them (Domain 4, Task 4.1, objectives 5-7). This chapter named bias as a property and gave you no way to prove it exists. Chapter 14 is that: what makes a dataset defensible, the effects of bias and variance including overfitting and underfitting, and the tooling that turns any of it into evidence — label quality analysis, human audits, subgroup analysis, SageMaker Clarify, SageMaker Model Monitor and Amazon A2I.