Exam-style
A quarterly review finds that the PII filter on a production Bedrock guardrail has been switched off for weeks. Both invocation logging and CloudTrail are enabled. Which one identifies who disabled the filter and when?
Reveal the answer
C. CloudTrail, because it records the control-plane API call that updated the guardrail with the caller identity and timestamp
CloudTrail is the record of who changed the system. Control-plane calls such as UpdateGuardrail, CreateGuardrailVersion and PutModelInvocationLoggingConfiguration each carry the calling principal and a timestamp. Invocation logging covers different ground: what the model was sent and what it returned. Its records name the principal that invoked the model, not the one who edited the guardrail. AWS Config does record a configuration item for AWS::Bedrock::Guardrail on each change, so it dates the edit, but a configuration item carries no caller identity and its relatedEvents field is empty. That sends you back to CloudTrail. Guardrail versions are snapshots of the configuration, with no field for the identity behind an edit.
Q. Who turned off the PII filter, and when? Which log, and why not invocation logging?
A. CloudTrail: it records control-plane API calls such as guardrail updates and logging-config changes, with caller identity and timestamp. Invocation logging records what the model was sent and returned, and the principal that invoked it, not the one who changed the configuration.
Why? Separate the who-changed-the-system record (CloudTrail) from the what-the-model-did record (invocation logging).