Chapter 17 · Domain 5 · 14% of the exam
Governance, Compliance, and Audit
35 min read · Chapter 17 of 17
On this page
- Certification Blueprint
- What This Chapter Covers
- The Six Services, by the Evidence They Produce
- Data Governance
- Governance Protocols
- The Generative AI Security Scoping Matrix
- Decision Rules and Exam Signals
- Distractor Patterns
- Scenario Walkthrough
- Key Concepts
- Revision Flashcards
- The Five-Beat Answer
- Why This Helps You
- Chapter Checklist
- After the Chapter
Certification Blueprint
| Field | Coverage |
|---|---|
| Exam | AWS Certified AI Practitioner (AIF-C01), exam guide v1.1 |
| Domain | Content Domain 5 — Security, Compliance, and Governance for AI Solutions |
| Exam weight | 14% of scored content — shared with Task 5.1 |
| Task statement | 5.2 Recognize governance and compliance regulations for AI systems |
| Objectives | 5.2.1 AWS services for governance and compliance · 5.2.2 data governance strategies · 5.2.3 processes to follow governance protocols |
What This Chapter Covers
Chapter 16 gave you controls. Encryption, identity, isolation, guardrails, output filtering — the machinery that stops the bad thing happening.
This chapter asks the question that always follows:
Can you prove it?
An auditor does not accept "encryption is enabled." They accept a record showing it was enabled on the date in question, a record of who could have changed it, and a document stating that enabling it was the policy. Governance is the discipline that produces those three things.
That is the whole subject, and it has a shape worth holding from the start:
| Objective | The question it answers |
|---|---|
| 5.2.1 Services | Where does the evidence come from? |
| 5.2.2 Data governance | What are the rules for the data itself? |
| 5.2.3 Protocols | How does an organisation keep following its own rules? |
A warning about this task statement specifically. Every service named in 5.2.1 is real, and every one of them has a genuine governance role. You cannot eliminate by spotting the invented option, because there isn't one. You eliminate by asking what kind of evidence the question needs.
The Six Services, by the Evidence They Produce
Objective 5.2.1 names six services. Learners routinely memorise six one-line definitions and then find that all six sound applicable to any compliance scenario — because at the level of "helps with compliance," they are.
The discrimination that works is narrower:
What artefact does this service hand you, and what question does that artefact answer?
What to remember from this diagram: the first split is the one that decides most questions. Before comparing any of the five customer-side services, ask whether the scenario is asking about AWS's compliance or yours. Artifact answers only the first, and it is the only one that does. Everything below that split is about your own workload.
| Service | The artefact it produces | The question it answers |
|---|---|---|
| AWS Config | A time-stamped record of resource configuration and every change to it | "What was this set to on the 3rd, and when did it change?" |
| AWS CloudTrail | A record of API calls — identity, action, time, source | "Who did this?" |
| AWS Audit Manager | Evidence assembled and mapped to a framework's controls | "Show me our evidence against control 4.2" |
| AWS Artifact | AWS's own third-party audit reports — SOC, ISO, PCI | "Prove that AWS is compliant" |
| Amazon Inspector | Vulnerability findings against workloads | "What here is exploitable?" |
| AWS Trusted Advisor | Checks against recommended practice | "Where do we deviate from best practice?" |
The first cut: whose compliance is being questioned?
AWS Artifact is the odd one out, and knowing why is worth marks.
Every other service on the list generates evidence about what you built. Artifact does not generate anything — it is a portal where you download reports AWS had produced about itself by external auditors. You cannot use Artifact to show that your model endpoint was encrypted. You use it to show that the underlying platform is certified.
This lands directly on the shared responsibility model from Chapter 16. Artifact covers AWS's side of the line. Config, CloudTrail, Inspector, Trusted Advisor and Audit Manager cover yours.
The exam signal: a scenario where an auditor or customer asks for a SOC 2 report, an ISO certification, or "evidence of the provider's compliance" is an Artifact question, and nothing else on the list can answer it.
The pair that decides the most questions: Config versus CloudTrail
These two are confused more than any other pair in Domain 5, and one word separates them.
What to remember from this diagram: Config records state; CloudTrail records actions. Both saw 14:02. Config knows what the setting became; CloudTrail knows who made the call. Neither can answer the other's question, and a real audit almost always needs both — which is why a question offering only one is usually testing whether you know which artefact was asked for.
| AWS Config | AWS CloudTrail | |
|---|---|---|
| Records | Resource configuration and its history | API calls |
| Answers | What was it set to, and when did that change? | Who called what, when, from where? |
| Natural question | "Was this bucket public on the 3rd?" | "Who made it public?" |
| Also supports | Compliance rules that evaluate configuration continuously | Forensic reconstruction of an incident |
| The word in the stem | configuration, setting, state, drift, compliant resource | who, which user or role, API call, action taken |
The practical test: if you can imagine the answer being a value — enabled, disabled, us-east-1,
kms-key-abc — the question is Config's. If the answer is a name — a user, a role, a service — it
is CloudTrail's.
Audit Manager assembles; it does not observe
Audit Manager is the service most often mis-filed, because it sounds like the general-purpose compliance service and it is not.
AWS Audit Manager continuously collects evidence from other services and maps it to the controls of a named framework, so that an audit against that framework can be answered with assembled evidence rather than a manual scramble.
It does not watch your resources itself. It consumes what Config, CloudTrail and others produce, and organises it against a control set. That is the reason for the dashed arrows in the first diagram.
The exam signal is the word framework or a named standard — an audit against a specific control set, with evidence needing to be mapped to specific controls. If a scenario names the framework and complains about the effort of assembling evidence for it, that is Audit Manager.
Inspector and Trusted Advisor: two kinds of "you should fix this"
These two both hand you a list of things to improve, and are separated by what kind of problem is on the list.
| Amazon Inspector | AWS Trusted Advisor | |
|---|---|---|
| Finds | Vulnerabilities — known CVEs, unintended network exposure | Deviations from recommended practice across cost, performance, security, fault tolerance and service limits |
| The underlying question | "What here could be exploited?" | "Where are we not following AWS's advice?" |
| Nature of a finding | A specific security weakness with a severity | A recommendation, often not a security issue at all |
Trusted Advisor is the broader and shallower of the two, and the only one on this list whose findings are frequently about cost rather than compliance. Inspector is narrow and security-specific. A scenario about unpatched software or an exploitable workload is Inspector's; a scenario asking whether the account follows AWS's general recommendations is Trusted Advisor's.
Data Governance
Objective 5.2.2 names six things: data lifecycles, logging, residency, monitoring, observation, and retention.
They are not six parallel items, and reading them as a flat list is the mistake this objective punishes. Three are stages or properties of the data's life; three are disciplines that run across all of it.
What to remember from this diagram: logging, monitoring and observation are not a stage. They are drawn touching every stage because they run continuously across the whole lifecycle. A learner who memorises the six as a sequence will look for the "logging step" in a scenario and not find it.
| Item | What it governs | Where it lives |
|---|---|---|
| Data lifecycle | The stages data passes through — ingestion, classification, storage, use, retention, disposal | The frame the rest sit in |
| Residency | Where data physically lives, and which jurisdiction's law applies to it | A property of the store stage |
| Retention | How long data is kept, and the basis for keeping it | A property of the retain stage |
| Logging | What is recorded about access and use | Across every stage |
| Monitoring | Watching for conditions that need action | Across every stage |
| Observation | Being able to see the system's behaviour at all | Across every stage |
Residency and retention: different words, different questions
The exam builds questions on the confusion, and the distinction is simple once stated.
- Residency asks where. Data must remain within a stated geography — a country, a region, an economic area — because a law or contract requires it.
- Retention asks how long. Data must be kept for a stated period, or deleted after one.
They are independent, and a scenario can constrain both at once. A requirement to keep records for seven years says nothing about which region they sit in; a requirement that data never leave a country says nothing about when it may be deleted.
The exam signal: the words jurisdiction, region, cross-border, must not leave, sovereignty point at residency. The words how long, retain, delete after, records must be kept point at retention. A stem containing a duration is a retention stem.
Why residency is harder for AI systems
Worth understanding rather than memorising, because it explains several plausible-looking distractors.
An AI system moves data further than a database does. Data may be collected in one place, used to build an index in another, sent to a model endpoint in a third, and logged in a fourth. Each of those is a copy, and each copy has a location. A residency requirement applies to all of them — including the inference logs, which is the copy most often forgotten because nobody thinks of a log as customer data.
Logging, monitoring and observation
These three are related, listed together, and not the same thing.
| What it is | Failure mode when absent | |
|---|---|---|
| Logging | Recording that something happened | Nothing to reconstruct after the fact |
| Monitoring | Watching recorded signals for conditions that need action | The record exists but nobody notices the condition |
| Observation | Being able to see what the system is doing at all | You cannot answer a question you did not anticipate |
Logging without monitoring is the most common real failure. The evidence was captured and nobody was watching it, which produces the audit finding that the organisation "had the data" and did not act on it. That sequence — recorded, unwatched, discovered later — is worth recognising in a stem.
Governance Protocols
Objective 5.2.3 names policies, review cadence, review strategies, governance frameworks such as the Generative AI Security Scoping Matrix, transparency standards, and team training requirements.
The unifying idea is that a policy is not a governance protocol. A policy is a document. A protocol is what makes the document take effect and stay current.
What to remember from this diagram: the two dashed arrows are the protocol. Without the first, policies never get revised and drift out of date. Without the second, a review keeps finding the same failure and treating it as an operating problem when it is a training problem.
| Element | What it is | What its absence looks like |
|---|---|---|
| Policies | The written rules, with a named owner | Practice varies by team, and nobody is wrong because nothing was agreed |
| Review cadence | How often the rules and the evidence are examined | Review happens after an incident, which is not a cadence |
| Review strategies | How review is conducted — what is sampled, by whom, against what | Review is a meeting, not a method, and finds whatever is raised |
| Governance frameworks | A structured model for scoping and comparing obligations, such as the Generative AI Security Scoping Matrix | Every use case is assessed from scratch and inconsistently |
| Transparency standards | What the organisation discloses about its AI systems, to whom, in what form | Disclosure is decided case by case, usually under pressure |
| Team training requirements | Ensuring the people applying the policy know it | The policy exists and is not followed, which looks like defiance and is ignorance |
Cadence and strategy are separate requirements
The guide names both, and they are commonly collapsed into one.
- Cadence is how often. Quarterly, on every model change, on every new data source.
- Strategy is how. Full review or sample, self-assessment or independent, evidence-based or interview-based.
A review that happens reliably and examines whatever someone happens to raise has a cadence and no strategy. A rigorous review that only happens after an incident has a strategy and no cadence. Both failures are examinable, and they look different in a stem.
Transparency standards are a disclosure obligation, not a model property
This boundary is worth stating carefully, because Chapter 15 used a similar word for a different idea.
- Chapter 15, Objective 4.2: transparency and explainability are properties of a model — can its behaviour be understood and accounted for? Model Cards, Clarify, open weights and licensing.
- Here, Objective 5.2.3: transparency standards are a governance protocol — what the organisation commits to disclosing about its AI systems, to whom, and in what form.
An organisation can run a fully explainable model and have no transparency standard, because it never decided what it would tell anyone. The reverse also happens: a clear disclosure policy about a model nobody can explain.
The Generative AI Security Scoping Matrix
This is the one framework named in the guide by name, which makes it the one you must actually know rather than recognise.
The Generative AI Security Scoping Matrix groups generative AI solutions into five scopes, numbered 1 to 5, representing least ownership to greatest ownership. Scopes 1 and 2 are buying generative AI; scopes 3, 4 and 5 are building it.
What to remember from this diagram: the split between Scope 2 and Scope 3 is the buy/build line, and the number measures ownership, not risk. A Scope 1 use case can carry enormous risk — employees pasting confidential material into a public chat application is Scope 1 — while a carefully run Scope 5 project may carry less. The number tells you how much of the thing is yours to govern.
| Scope | Name | What it means |
|---|---|---|
| 1 | Consumer app | Your business consumes a public third-party service. You do not see or own the model or its training data and cannot modify it |
| 2 | Enterprise app | You use a third-party enterprise application with GenAI features embedded, and a business relationship exists with the vendor |
| 3 | Pre-trained models | You build your own application on an existing third-party foundation model, integrated through an API |
| 4 | Fine-tuned models | You refine a third-party foundation model with your own data, producing a new specialised model |
| 5 | Self-trained models | You build and train a model from scratch on data you own. You own every aspect of the model |
The matrix also names five security disciplines that apply across all scopes, with requirements that change as the scope changes: governance and compliance, legal and privacy, risk management, controls, and resilience.
Scoping is the first governance step, not a later one
The reason the framework exists is that the same question — "who is responsible for the training data?" — has a different answer in each scope, and answering it wrongly is how obligations get missed.
| The question | Scope 1 | Scope 4 |
|---|---|---|
| Who selected the training data? | The provider, invisibly to you | You did, for the fine-tuning set |
| What can you tell an auditor about it? | Only what the provider publishes | Everything, because you assembled it |
| Where does your obligation start? | At what your staff put into it | At the data, the tuning, and the output |
Chapter 11's warning lands here. Fine-tuning is Scope 4, which means the organisation owns the training data question — and training data cannot be removed from weights. The scoping step is what surfaces that obligation before the fine-tuning job runs.
Decision Rules and Exam Signals
Rule 1 — ask what artefact the question needs. Six real services; the discrimination is by evidence produced, never by which sounds most like "compliance."
Rule 2 — Artifact is about AWS, everything else is about you. This single split resolves a large share of 5.2.1 questions on its own.
Rule 3 — Config records state, CloudTrail records actions. If the answer is a value, it is Config. If the answer is a name, it is CloudTrail.
Rule 4 — Audit Manager assembles, it does not observe. The signal is a named framework and the effort of mapping evidence to its controls.
Rule 5 — Inspector finds vulnerabilities; Trusted Advisor finds deviations from advice. Only Trusted Advisor routinely reports things that are not security issues at all.
Rule 6 — residency is where, retention is how long. A duration in the stem means retention.
Rule 7 — logging, monitoring and observation run across the lifecycle, they are not stages in it. Logging without monitoring is the classic real-world failure.
Rule 8 — a policy is not a protocol. Cadence, strategy, training and review are what make a policy operative.
Rule 9 — cadence and strategy are separate. How often and how fail independently.
Rule 10 — transparency standards are disclosure, not explainability. Chapter 15 owns the model property; this objective owns the organisational commitment.
Rule 11 — the Scoping Matrix numbers ownership, not risk. 1 to 5 is least to greatest ownership, with the buy/build line between 2 and 3.
Rule 12 — governance evidence and model quality evidence are different artefacts. A strong evaluation score is not a compliance record.
Distractor Patterns
| Pattern | What it looks like | How to defuse it |
|---|---|---|
| Artifact offered for your own workload | Using Artifact to evidence that your endpoint was encrypted | Artifact delivers AWS's reports about AWS; it generates nothing about what you built |
| CloudTrail offered for a configuration question | "Which service shows whether the bucket was public on the 3rd?" | That is a state question — Config. CloudTrail would show who changed it |
| Config offered for an identity question | "Which service identifies who disabled encryption?" | That is an action question — CloudTrail |
| Audit Manager as a monitoring service | Described as continuously watching resources for drift | It assembles evidence against a framework; Config evaluates configuration |
| Trusted Advisor for a vulnerability | Offered for unpatched software or an exploitable workload | Inspector finds vulnerabilities; Trusted Advisor checks practice |
| Residency answer to a retention stem | A region or jurisdiction control offered for "records kept seven years" | A duration is retention; region is residency |
| Retention answer to a residency stem | A deletion schedule offered for "data must not leave the country" | Deleting on time does not constrain location |
| Logging treated as a lifecycle stage | A sequence in which logging happens after storage and before use | Logging runs across every stage; it is not positioned in the sequence |
| A policy offered as the complete answer | "Publish a policy" for a repeated compliance failure | Ask what makes it operative — training, cadence, review strategy |
| Explainability offered for transparency standards | Model Cards or Clarify offered for a disclosure obligation | Those are Chapter 15's model properties, not an organisational commitment |
| Scope number read as risk | "Scope 1 is safest because you own least" | The number measures ownership; Scope 1 carries real risk from what staff put in |
| Fine-tuning scoped as 3 | An organisation tuning an FM on its own data, called pre-trained | Producing a new specialised model from your data is Scope 4 |
The first three are a matched set and the highest-value marks in this objective. All three are answered by one question: is the evidence a state, an action, or AWS's own certification?
Scenario Walkthrough
A healthcare group has fine-tuned a third-party foundation model on de-identified clinical notes to draft appointment summaries. A regulator has opened a review. It asks for four things: proof that the cloud platform itself holds a recognised security certification; evidence that the model endpoint had encryption enabled throughout the period under review; the identity of whoever disabled endpoint logging for six days in March; and the organisation's evidence mapped to the control set of a named healthcare framework. Separately, the group's own counsel notes that clinical notes must remain within the country and that inference logs are currently written to a bucket in another region. Nobody outside the platform team has been briefed on the model's disclosure policy.
| Requirement | Reading | Decision |
|---|---|---|
| Platform holds a recognised certification | Evidence about AWS, not about you | AWS Artifact — download the relevant report |
| Encryption enabled throughout the period | A configuration state over time | AWS Config |
| Who disabled logging in March | An action and an identity | AWS CloudTrail |
| Evidence mapped to a named framework's controls | Assembly against a control set | AWS Audit Manager |
| Notes must stay in-country; logs are elsewhere | Residency, and it is being breached by a copy | Inference logs are customer data; fix the log destination |
| Nobody briefed on the disclosure policy | Team training, not a policy gap | The policy exists; the protocol around it does not |
Six requirements, and four different services, none of them interchangeable. The scenario is built so that "a compliance service" is not an answer — each row names the artefact it needs.
Two rows are the real test. The residency row is a breach nobody entered deliberately: the logs were configured once, and nobody classified a log as clinical data. The training row is the failure that looks like non-compliance and is not — the policy was written and never reached the people it governed.
And one thing worth naming: the group fine-tuned the model, which is Scope 4. That is why the training-data questions are theirs to answer rather than the provider's.
Key Concepts
| Term | Definition |
|---|---|
| AWS Config | Records resource configuration and its change history, and can evaluate configuration against rules continuously; answers what a resource was set to at a given time |
| AWS CloudTrail | Records API calls — which identity performed which action, when, and from where; answers who did something |
| AWS Audit Manager | Continuously collects evidence and maps it to the controls of a named framework, so an audit can be answered with assembled evidence rather than manual collection |
| AWS Artifact | A portal for downloading AWS's own third-party audit reports and certifications, such as SOC and ISO; evidence about the provider, not about your workload |
| Amazon Inspector | Scans workloads for vulnerabilities such as known CVEs and unintended network exposure, returning findings with severities |
| AWS Trusted Advisor | Checks an account against AWS recommended practice across cost, performance, security, fault tolerance and service limits; the broadest and least security-specific of the six |
| Data lifecycle | The stages data passes through from ingestion and classification, through storage and use, to retention and disposal |
| Data residency | The requirement that data remain within a stated geography or jurisdiction; a property of where data is stored, including every copy and log |
| Data retention | The requirement that data be kept for, or deleted after, a stated period; a property of duration rather than location |
| Logging | Recording that something happened, so it can be reconstructed later; runs across the whole data lifecycle rather than occupying a stage in it |
| Monitoring | Watching recorded signals for conditions that require action; the discipline whose absence produces evidence that nobody read |
| Observation | The ability to see what a system is doing at all, including in ways not anticipated when it was built |
| Review cadence | How often governance rules and their evidence are examined; distinct from how the review is conducted |
| Review strategy | How a review is carried out — what is sampled, by whom, and against what standard |
| Transparency standards | An organisation's commitment about what it discloses regarding its AI systems, to whom and in what form; a governance protocol, not a model property |
| Team training requirements | Ensuring the people who must apply a policy know it exists and how to apply it; the element whose absence makes a real policy look like defiance |
| Generative AI Security Scoping Matrix | An AWS framework grouping GenAI solutions into five scopes representing least to greatest ownership — consumer app, enterprise app, pre-trained models, fine-tuned models, self-trained models — with scopes 1-2 buying and 3-5 building |
Revision Flashcards
Say the answer aloud before revealing it.
1. What single question discriminates the six governance services in Objective 5.2.1? → What artefact does this service hand you, and what question does that artefact answer? All six are real services with genuine compliance roles, so elimination cannot work by spotting a fake option. Config produces configuration state, CloudTrail produces an API call record, Inspector produces vulnerability findings, Trusted Advisor produces best-practice deviations, Audit Manager produces evidence mapped to a framework's controls, and Artifact delivers AWS's own audit reports.
2. Why is AWS Artifact the odd one out among the six? → Because it is the only one producing evidence about AWS rather than about your workload. It generates nothing — it is a portal for downloading reports that external auditors produced about AWS itself, such as SOC and ISO certifications. It sits on the provider side of the shared responsibility model, so it can never evidence that your model endpoint was configured correctly.
3. Separate AWS Config from AWS CloudTrail in one sentence each. → Config records what a resource was configured as and when that changed; CloudTrail records which identity called which API, when, and from where. The practical test is the shape of the answer: if the answer is a value such as enabled, disabled or a region name, the question is Config's; if the answer is the name of a user, role or service, it is CloudTrail's.
4. What does AWS Audit Manager actually do, and what is its exam signal? → It continuously collects evidence from other services and maps it to the controls of a named framework, so an audit against that framework can be answered with assembled evidence rather than a manual scramble. It does not observe resources itself. The signal is a named framework or standard, plus a complaint about the effort of mapping evidence to specific controls.
5. Distinguish Amazon Inspector from AWS Trusted Advisor. → Inspector finds vulnerabilities — known CVEs, unintended network exposure — and returns security findings with severities. Trusted Advisor checks the account against AWS recommended practice across cost, performance, security, fault tolerance and service limits, and is the only service on this list that routinely reports things which are not security issues at all.
6. Which of the six things in Objective 5.2.2 are not lifecycle stages? → Logging, monitoring and observation. They run continuously across every stage rather than occupying a position in the sequence. A learner who memorises the six as an ordered list will look for the logging step in a scenario and fail to find it, because it is not there — it touches ingestion, storage, use and disposal alike.
7. Residency versus retention — what does each ask? → Residency asks where data lives and which jurisdiction's law applies to it. Retention asks how long it is kept and on what basis. They are independent and a scenario can constrain both at once. A duration anywhere in the stem is a retention signal; words like jurisdiction, cross-border or must not leave are residency signals.
8. Why is residency harder to satisfy for an AI system than for a database? → Because an AI system makes more copies. Data may be collected in one place, indexed in another, sent to a model endpoint in a third and logged in a fourth, and every one of those copies has a location the requirement applies to. The inference logs are the copy most often missed, because nobody thinks of a log as customer data.
9. What is the difference between logging and monitoring, and which failure is most common? → Logging records that something happened; monitoring watches recorded signals for conditions needing action. Logging without monitoring is the common real failure: the evidence was captured and nobody was watching, producing the audit finding that the organisation held the data and did not act on it.
10. Why is a policy not a governance protocol? → Because a policy is a document and a protocol is what makes it take effect and stay current. The protocol is the surrounding machinery — team training so the rule reaches the people applying it, a review cadence so it is examined regularly, a review strategy so the examination is a method rather than a meeting, and a revision path so findings change the rule.
11. Review cadence and review strategy are listed separately. What does each mean and how does each fail? → Cadence is how often review happens; strategy is how it is conducted — what is sampled, by whom, against what. They fail independently. A review that occurs reliably and examines whatever someone raises has a cadence and no strategy. A rigorous review that only happens after an incident has a strategy and no cadence.
12. How do transparency standards differ from explainability? → Explainability is a property of a model, examined under Objective 4.2 in Chapter 15 with Model Cards, Clarify and licensing. Transparency standards are an organisational commitment about what is disclosed regarding AI systems, to whom, and in what form. An organisation can run a fully explainable model with no transparency standard, because it never decided what it would tell anyone.
13. Name the five scopes of the Generative AI Security Scoping Matrix in order. → Scope 1 consumer app, Scope 2 enterprise app, Scope 3 pre-trained models, Scope 4 fine-tuned models, Scope 5 self-trained models. Scopes 1 and 2 are buying generative AI; scopes 3, 4 and 5 are building it. The numbering runs from least ownership to greatest ownership.
14. What does the Scoping Matrix scope number measure, and what does it not measure? → It measures ownership — how much of the solution is yours to govern. It does not measure risk or sophistication. A Scope 1 use case can carry enormous risk, since employees pasting confidential material into a public chat application is Scope 1, while a carefully run Scope 5 project may carry less.
15. An organisation fine-tunes a third-party foundation model on its own data. Which scope, and what follows from it? → Scope 4, fine-tuned models. It follows that the training-data questions are the organisation's to answer rather than the provider's — data selection, consent, licensing and representativeness all become theirs. Chapter 11's warning applies directly: training data cannot be removed from weights, so scoping must surface that obligation before the tuning job runs.
The Five-Beat Answer
The core question this chapter prepares you for: "How would you govern an AI system?"
Five beats, checked in this order. Missing a beat is a failure state — you will be probed on whichever one you skipped.
- Scope it first — say which of the five scopes the use case falls into, and therefore how much of it you own. Governance obligations follow from ownership, and scoping before anything else is what stops obligations being missed rather than discovered.
- State the rules as policy — name what is written down, who owns it, and what it covers. A governance answer that starts with tooling has skipped the part that decides what the tooling is for.
- Place the data on its lifecycle — where it is stored and under whose jurisdiction, how long it is kept, and what happens at disposal. Say residency and retention separately; they are different obligations.
- Name the evidence and where it comes from — configuration state from Config, actions from CloudTrail, vulnerabilities from Inspector, framework mapping from Audit Manager, the provider's certifications from Artifact. Evidence you cannot produce is a control you cannot claim.
- Say how it stays true — review cadence, review strategy, team training, and the path by which findings revise the policy. This is the beat that separates governance from a one-off compliance exercise, and it is the one most answers omit.
A strong answer scopes before it selects and treats evidence as the deliverable. A weak answer names a service in the first sentence.
Why This Helps You
On the job: the expensive governance failures are rarely a missing control. They are a control that existed and could not be evidenced, a log that was written and never read, or a policy that was correct and never reached the team applying it. All three are invisible until someone asks — which is exactly when they become expensive.
In interviews: "how do you know that control was in place last quarter?" is a question that separates people who have been through an audit from people who have not. The strong answer reaches for a specific artefact and names where it comes from. Being able to separate Config from CloudTrail in one sentence is a reliable marker.
On the exam: Domain 5 is 14% of scored content, split with Task 5.1. This task statement's questions are unusually service-heavy, and all six services in 5.2.1 are genuine — so the elimination habit of finding the invented option does not work here. The candidates who do well are the ones who convert each option into the artefact it produces before comparing them.
Chapter Checklist
- I can name all six governance services and the artefact each one produces
- I can say why AWS Artifact is the odd one out, and what it can never evidence
- I can separate AWS Config from AWS CloudTrail with the state-versus-action test
- I can say what Audit Manager assembles and what its exam signal is
- I can distinguish Amazon Inspector from AWS Trusted Advisor
- I can name the six items in Objective 5.2.2 and say which three are not stages
- I can separate residency from retention and name the signal words for each
- I can explain why residency is harder for AI systems than for a single datastore
- I can distinguish logging, monitoring and observation, and name the common failure
- I can say why a policy is not a governance protocol
- I can separate review cadence from review strategy and describe how each fails
- I can distinguish transparency standards from explainability
- I can name all five scopes of the Generative AI Security Scoping Matrix in order
- I can say what the scope number measures, and what it does not
After the Chapter
- Complete
student/project.md— parts 58-60 of the AI/ML Decision Sheet you began in Chapter 01. Bring the same sheet; do not start a new one. These are the last parts you will add. - Take
student/quiz.mdclosed-book, then review the reasoning for every question you guessed, including the ones you got right. Pay particular attention to questions 2 and 3 — they are deliberate mirror images, and missing both means the state-versus-action split has not landed. - Open the official v1.1 exam guide's Domain 5 page and confirm you can attach a concept from this chapter to each of the three bullets under Task Statement 5.2. Note that the guide names the Generative AI Security Scoping Matrix explicitly — it is the one framework you are expected to know rather than merely recognise.
- Then go back through the whole Decision Sheet, parts 1-60, before Chapter 18. This is the last teaching chapter, and the practice exam samples all five domains at their published weights. Re-reading the sheet end to end is a better use of your time than re-reading any single chapter.
- Next: Chapter 18 — Full Practice Exam and Exam-Day Strategy. A full-length practice exam sampled at the official domain weights, with elimination walkthroughs for every question, timing strategy for all four question types, what compensatory scoring means for triage, and a final readiness checklist.
Chapter 17 quiz
13 questions on this chapter, marked instantly, with an explanation for every answer.