Exam-style
A claims assistant on Bedrock regularly receives customer names, addresses and policy numbers in free-text input, and that same text lands in the model invocation logs. The organisation wants the PII stopped at the service rather than in each of the twelve calling applications. What should be configured?
Reveal the answer
C. A Bedrock Guardrail with a sensitive-information policy set to mask or block PII on input and output
The Guardrail sensitive-information policy is the built-in control, and because it applies at invocation every caller inherits it and both the request and the response are filtered before anything is written down. Macie and Comprehend both detect PII well, but they run after the fact over data that has already been logged. A Lambda in front puts the detection logic back into bespoke code that twelve teams then depend on. Tightening the bucket policy limits who can read the leak rather than preventing it, which is why the log store gets a customer managed KMS key and tight access on top of the Guardrail, not instead of it.
Q. Keep customer PII out of prompts and logs. What is the built-in control?
A. A Bedrock Guardrail with a sensitive-information (PII) policy can block or mask PII in inputs and outputs, and redacting before logging keeps it out of the invocation logs. Encrypt the log store with a customer-managed KMS key and lock down access.
Why? The log that proves compliance can itself leak; redact at the guardrail and restrict the store.