Free live cohort on Google Meet — register your interest →

Chapter 17 · Domain 5 · 14% of the exam

Governance, Compliance, and Audit

35 min read · Chapter 17 of 17

On this page
  1. Certification Blueprint
  2. What This Chapter Covers
  3. The Six Services, by the Evidence They Produce
  4. Data Governance
  5. Governance Protocols
  6. The Generative AI Security Scoping Matrix
  7. Decision Rules and Exam Signals
  8. Distractor Patterns
  9. Scenario Walkthrough
  10. Key Concepts
  11. Revision Flashcards
  12. The Five-Beat Answer
  13. Why This Helps You
  14. Chapter Checklist
  15. 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?

Decision flow beginning with a compliance question having been asked, first splitting on whether the question is about AWS itself or about your own workload, routing questions about AWS to AWS Artifact which delivers AWS's own audit reports such as SOC ISO and PCI for download rather than generation, and routing questions about your workload to a second split on what kind of evidence answers it, with branches to AWS Config for configuration state over time, AWS CloudTrail for the API call record of which identity called which API and when, Amazon Inspector for vulnerability findings, AWS Trusted Advisor for best-practice deviation checks, and AWS Audit Manager for evidence mapped to a named framework's controls, with dashed arrows showing Config CloudTrail and Inspector feeding their output into Audit Manager

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.

Two side-by-side panels contrasting AWS Config which answers what, showing a model endpoint resource with recorded settings of encryption on public access off and logging enabled, then a change at 14:02 where public access became on, concluding that the question answered is what the resource was set to at any moment; and AWS CloudTrail which answers who, showing an UpdateEndpointConfig API call made by the role deploy-pipeline at 14:02 with source IP and request parameters, concluding that the question answered is who made the change and from where; both panels converge on a note that neither is a substitute for the other because Config shows the state changed while CloudTrail shows who changed it, and an audit usually needs both

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.

Left-to-right data lifecycle beginning with create and ingest where data enters scope, then classify determining what it is how sensitive it is and whose it is, then store where residency decides which region and jurisdiction, then use covering training retrieval and inference, then retain where retention decides how long and on what basis, then dispose meaning deletion that is evidenced rather than assumed, with logging monitoring and observation drawn as a band connecting to every stage rather than sitting as a stage of its own, and a dashed arrow from dispose back to classify showing that policy review changes the rules

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.

Left-to-right operating cycle beginning with policy as the written rule and its owner, moving to team training where the rule reaches the people who must apply it, then operate where work proceeds under the policy, then evidence where logs configuration records and control results accumulate, then review at a stated cadence using a stated review strategy, then transparency covering what is disclosed to whom and in what form, with a dashed arrow returning from transparency to policy showing that findings revise the rule, and a second dashed arrow from review back to team training noting that a policy nobody was trained on fails at the review step

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.

Two grouped columns, the first labelled buying generative AI containing Scope 1 consumer app where the business consumes a public third-party service and does not see or own the model or its training data, and Scope 2 enterprise app where a third-party enterprise application has embedded generative AI and a business relationship exists with the vendor; the second labelled building generative AI containing Scope 3 pre-trained models where the business builds its own application on an existing third-party foundation model via API, Scope 4 fine-tuned models where a third-party foundation model is fine-tuned on the business's data producing a new specialised model, and Scope 5 self-trained models built and trained from scratch on data the business owns with every aspect owned; an arrow runs through all five and terminates in a note that ownership and responsibility increase from 1 to 5 and that the scope number measures how much of the solution is yours to govern rather than measuring risk or sophistication

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

  1. 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.
  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 2 and 3 — they are deliberate mirror images, and missing both means the state-versus-action split has not landed.
  3. 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.
  4. 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.
  5. 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.

1. All six services named in Objective 5.2.1 assist with governance and compliance. What most reliably separates them from one another when answering a question?
2. A regulator asks a bank to demonstrate that a model inference endpoint had encryption enabled for every day of the preceding quarter. Which service produces that evidence?
3. The same bank now needs to establish which identity disabled encryption on that endpoint during a six-hour window in February. Which service answers this?
4. An enterprise customer's procurement team asks for evidence that the underlying cloud platform holds a recognised third-party security certification. Which service provides it?
5. A healthcare organisation is being audited against a named industry control framework, and the team reports that gathering evidence for each individual control is consuming most of the effort. Which service is designed for this?
6. A security team wants to know which of its running workloads contain known exploitable software vulnerabilities. Which service is built for that question?
7. A financial regulator requires that transaction records supporting model decisions be kept for seven years. Which data governance property does this requirement constrain?
8. An insurer must keep policyholder data inside its own country. Its retrieval index and model endpoint are both in-country, but inference logs are written to a bucket in another region. How should this be assessed?
9. A post-incident review finds that the relevant events had been recorded correctly for months, but no one had examined them until after the incident. Which discipline was missing?
10. A retailer takes a third-party foundation model and refines it with its own product and support data, producing a new specialised model for internal use. Which Generative AI Security Scoping Matrix scope applies?
11. Which two of the following produce evidence about **your own** workload rather than about AWS itself? (Select two.)
12. An organisation reviews its AI governance thoroughly, but only ever after something has gone wrong. Which element of a governance protocol is absent?
13. A regulator asks an organisation what it publicly commits to disclosing about the AI systems affecting its customers. Which element does this question address?