AWSAWS Certified Generative AI Developer - Professional2026-103.3 Implement AI governance and compliance mechanisms
Reconstruct decisions across audit evidence layers
Completed by the knowledge check
Learning objective
Distinguish CloudTrail API audit events from CloudWatch Logs application decisions and preserve source attribution for forensic review.
Core idea
An API audit record explains which AWS principal requested an operation. An application decision record explains why the workload accepted evidence, selected a model, released an answer, or refused a request. Source attribution explains which content supported the answer. A forensic review needs these records joined without treating one as a substitute for the others.
CloudTrail records AWS API activity. CloudWatch Logs can hold the application records you emit and Bedrock model-invocation logs for supported calls. The storage destination does not determine the meaning of a record: a CloudTrail event delivered to CloudWatch Logs remains an API audit event.
Design evidence collection before an incident. Preserve correlation identifiers, versioned configuration, source revisions, and terminal outcomes. A log containing “request succeeded” cannot explain whether the application released an unsupported answer or correctly refused an unsafe request.
How it works
Capture the relevant API events
See 1.6.4 for inference management events and prompt/guardrail data-event coverage. For forensic review of retrieved evidence and agent actions, add the relevant runtime selectors: Retrieve and RetrieveAndGenerate use AWS::Bedrock::KnowledgeBase; InvokeAgent uses AWS::Bedrock::AgentAlias. Data events are not logged by default, and additional charges apply.
The selector fields eventCategory and resources.type distinguish the category and resource type. Use eventCategory equal to Data and the relevant resource type rather than assuming an existing trail covers every stage. Review selector coverage whenever the application adds a retrieval or agent path.
CloudTrail’s Bedrock examples include eventTime, eventSource, eventName, awsRegion, userIdentity, requestID, and eventID. These identify the API action and AWS identity. They do not necessarily identify the end user behind a shared workload role or explain the business authorization decision.
CloudTrail log entries are not an ordered stack trace. Reconstruct dependencies using identifiers and application records instead of sorting events and assuming temporal proximity proves causation.
Handle streaming audit events correctly
AWS documents an additional CloudTrail event after a ConverseStream or InvokeModelWithResponseStream response finishes. This event has eventType: AwsServiceEvent; the API call has eventType: AwsApiCall. The completion event carries token counts that were unavailable when the call began.
A stream-completion event is not an authorized API request and is not evaluated by IAM policies or SCPs. When counting calls or investigating whether a permission policy blocked a request, restrict the query to AwsApiCall events. Use serviceEventDetails.parentRequestId to join the completion event to the initiating call’s requestID.
A finished model stream does not prove that the client received or accepted a complete answer. Application delivery and publication are separate outcomes. Record those outcomes in your own decision evidence, especially if the stream failed downstream or an output check withheld content.
Emit application decisions with explicit meaning
Define a structured application-log contract. Suggested fields include request_id, attempt_id, aws_request_id, policy_revision, model_id, prompt_revision, decision, reason_code, and evidence_record_id. These are application-defined fields, not automatically populated CloudWatch Logs fields.
Record decisions at the boundaries that matter: verified authorization, selected evidence, model attempt completion, output validation, and content publication. Distinguish a safe refusal from a processing error. A successful Bedrock API call can produce an answer that your application correctly withholds.
Use a stable request identifier across the workflow and a separate attempt identifier for each retry or fallback. Capture AWS request identifiers at the service boundary. See 2.4.9 for trace correlation; forensic records add the policy revision, decision reason, and retained evidence needed to explain the result.
Keep end-user identity references appropriate to the review purpose. A shared IAM role explains AWS permissions but not which employee or tenant requested the answer. Record a controlled reference to the verified caller, rather than copying unrestricted identity claims into every log.
Separate invocation payloads from decision records
See 1.6.4 for invocation-logging coverage, payload fields, and the distinction between service-populated identity and caller assertions. The forensic join additionally needs the application’s request and attempt identifiers in the invocation record.
Send those identifiers through the requestMetadata request-body field on Converse or ConverseStream. For InvokeModel or InvokeModelWithResponseStream, use the X-Amzn-Bedrock-Request-Metadata HTTP header with a JSON object of string keys and values. When signing the header yourself with SigV4, include it in SignedHeaders; omission causes InvalidSignatureException.
AWS records these values in the invocation log’s top-level requestMetadata only when invocation logging is enabled in the call’s Region. The limit is 16 entries per request, with keys and values each limited to 256 characters. Do not include personally identifiable information, credentials, or other sensitive data.
Join decision records to invocation logs on the application request_id and attempt_id carried in this metadata, then join to CloudTrail using the service request identifier. Invocation logs call it requestId; CloudTrail calls it requestID. Normalize names in investigation queries while retaining the original records. Test the join for retries and fallback attempts so one workflow does not appear to be one model call.
Invocation logs show model interaction, not all application decisions surrounding it. They also create a sensitive-data collection surface. Decide whether investigators need full payloads or controlled evidence references, and restrict access accordingly. Do not assume that logging a prompt preserves the original source revision or proves why the application chose that prompt.
Preserve attribution and retention
Retain the citation mapping and source revisions described in 3.3.3. Bedrock’s Citation structure links generatedResponsePart to retrievedReferences. Preserve that relationship in the evidence record; a list of URLs detached from answer segments is weaker evidence.
Record the evidence admitted to model context and the citations returned with the answer as separate sets. An investigator might need to determine whether the application selected unauthorized content, whether the model ignored available evidence, or whether the displayed citation was altered after generation.
Apply a retention policy to decision-log groups using PutRetentionPolicy and its retentionInDays parameter. For retained S3 evidence requiring deletion protection, use Object Lock with versioning and the approved retention mode. Protection applies to individual versions, so retain version identities rather than only object keys.
Key distinctions and trade-offs
API success versus application acceptance: An invocation can succeed while authorization, validation, or publication fails elsewhere.
AWS principal versus end user: A workload role identifies service access. Application evidence must connect it to the verified caller when review requires that context.
CloudWatch Logs destination versus record semantics: CloudTrail events, invocation payloads, and application decisions can share a destination but answer different questions.
Complete payloads versus sufficient evidence: Payload capture can aid reconstruction but increases sensitive-data exposure. Stable evidence references reduce duplication only if the referenced records remain retrievable.
Architecture / decision scenario
An internal policy assistant produces a disputed answer. The investigator first locates the application’s request and attempt records. They show which caller was authorized, which policy revision ran, and that the answer passed the application’s publication gate.
CloudTrail identifies the workload principal and Converse call. Data-event coverage supplies the knowledge-base retrieval event. If the response streamed, the investigator joins its completion record through serviceEventDetails.parentRequestId rather than counting it as another call.
The investigator uses requestMetadata to match each decision-record attempt to its invocation log, then connects the service request identifier to CloudTrail. The retained attribution record then resolves the answer segment to the cited document revision. Comparing that passage with the publication decision reveals whether the source was wrong, the answer misrepresented it, or the application accepted missing support. No single log layer could establish all three.
Common exam traps
- Expecting CloudTrail to explain an application’s acceptance decision.
- Assuming all Bedrock runtime calls are data events.
- Omitting knowledge-base data-event selectors.
- Counting streaming completion events as additional API invocations.
- Treating model-stream completion as confirmed client delivery.
- Preserving source URLs without revisions or citation mappings.
What to remember
Join API identity, per-attempt application decisions, and immutable source attribution. Verify event-selector and endpoint coverage. Preserve enough evidence to explain both the model interaction and the application’s final publication decision.
Knowledge check
A user disputes why an internal policy assistant refused to answer. CloudTrail shows a successful Converse call by the shared workload role at that time. Which record explains the refusal?
userIdentity for the workload roledecision and reason_codeeventName and requestID for the callA cost review counts Bedrock calls from CloudTrail and finds twice as many ConverseStream events as the application made. The trail records management events only. How should the query change?
eventSource is bedrock.amazonaws.comrequestID appears once in the trailerrorCode to nullAwsApiCall events, joining AwsServiceEvent by parentRequestIdAwsServiceEvent that carries token counts. It is not another authorized request, so call counts use AwsApiCall events, and the completion event joins its call through serviceEventDetails.parentRequestId .An investigation needs the knowledge base retrievals behind a disputed answer, but the trail shows only the Converse call. Which trail configuration would have recorded them?
resources.type AWS::Bedrock::KnowledgeBaseresources.type AWS::Bedrock::AgentAliasRetrieve and RetrieveAndGenerate are data events, logged only through advanced selectors for AWS::Bedrock::KnowledgeBase ; data events are off by default. AgentAlias covers InvokeAgent , and storing management events elsewhere does not add events that were never recorded.A workflow calls InvokeModel and retries on failure. Investigators must match each invocation log record to the application’s request and attempt. Model invocation logging is enabled. How should the application pass its identifiers?
requestMetadata field of the InvokeModel request bodyX-Amzn-Bedrock-Request-Metadata header, as a JSON string mapuserIdentityInvokeModel and InvokeModelWithResponseStream take request metadata through the X-Amzn-Bedrock-Request-Metadata header; the requestMetadata body field belongs to Converse and ConverseStream . The values appear in the invocation log’s requestMetadata , so each attempt joins to its decision record. A self-signed request must include the header in SignedHeaders .