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 one PII policy enforced on every model call rather than twelve bespoke implementations in the 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: one versioned policy, defined once, filtering both the request and the response before anything is written down. It is not automatic. Each caller passes the guardrail identifier and version on the model call, so what makes it non-optional across twelve applications is an IAM condition key requiring that identifier on the invoke action, or a shared facade that injects it. 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. The policy is defined once as a versioned resource and every caller passes its identifier and version on the model call, so an IAM condition key requiring that identifier, or a shared facade that injects it, is what stops a team shipping without one. 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.