Domain 3 is built around Amazon Bedrock Guardrails. These notes restate what the documentation says about each policy type, how PII and grounding checks behave, and the gaps that scenario questions like to exploit.
| Requirement | Guardrail policy |
|---|---|
| Block hate, insults, sexual content, violence, misconduct or prompt attacks | Content filters (with the Prompt Attack category) |
| Keep the assistant away from a whole subject | Denied topics |
| Block exact words or phrases such as competitor names | Word filters |
| Block or mask PII in prompts and responses | Sensitive information filters |
| Detect answers that are not supported by the source or do not answer the question | Contextual grounding check |
| Verify answers against logical rules | Automated Reasoning checks |
Source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html
A guardrail can combine content filters, prompt attacks, denied topics, word filters, sensitive information filters, contextual grounding checks and Automated Reasoning checks. It must contain at least one filter and the messaging shown when something is blocked.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html
Content filters cover Hate, Insults, Sexual, Violence, Misconduct and Prompt Attack, each with its own filter strength. The prompt attack category detects jailbreaks and prompt injections; prompt leakage detection needs the Standard tier.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html
Use denied topics to keep the application away from whole subjects, such as illegal investment advice. Word filters are exact match, so they suit specific words or phrases such as competitor names or profanity.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html
The sensitive information filter either blocks the whole request or response, or masks the PII with its type (for example {NAME} or {EMAIL}). It is a probabilistic, context-dependent ML filter, and custom regex entities do not support lookaround.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-sensitive-filters.html
PII masking applies to what goes to and comes from the model, not to model invocation logs: the input field in CloudWatch Logs keeps the original request. Protect logs with CloudWatch Logs data protection. The match field in the guardrail trace also holds the original PII.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-sensitive-filters.html
The sensitive information filter evaluates text only. PII in tool call arguments, tool results and tool definitions is neither blocked nor masked, so agents that call tools need their own controls.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-sensitive-filters.html
A contextual grounding check detects hallucinations by scoring grounding (is the answer supported by the source?) and relevance (does it answer the question?). It needs three inputs: the grounding source, the user query and the content to guard.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-contextual-grounding-check.html
Grounding and relevance thresholds range from 0 to 0.99; a higher threshold blocks more responses and lowers the chance of hallucinations reaching users. A threshold of 1 is invalid because it would block everything.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-contextual-grounding-check.html
Grounding checks accept up to 100,000 characters of source, 1,000 of query and 5,000 of response. The Standard tier needs cross-Region inference on the guardrail, and UpdateGuardrail replaces the whole configuration: omit tierConfig and the tier resets to Classic.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-contextual-grounding-check.html
With a streaming API an irrelevant response can reach the user before the grounding check flags it, because the whole response must be streamed first. Grounding checks run on the model output only, never on the prompt.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-contextual-grounding-check.html
A filter action of NONE (detect mode) takes no action but returns detection information, so you can measure how a guardrail would behave before you switch it to block or mask. It is the safe way to evaluate a policy against real traffic.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html
Automated Reasoning checks validate that model responses follow logical rules you define in natural language, for example that a chatbot only recommends products that are in stock or that financial advice follows regulatory rules.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html
In the guardrail trace (for example in a Converse response) the match field contains the original detected PII, not the masked value. That is by design so your application can use the detection, but it means the trace itself is sensitive.
Official source: docs.aws.amazon.com/bedrock/latest/userguide/guardrails-sensitive-filters.html
Answer practice questions, then review your mistakes with spaced repetition.