AWSAWS Certified Generative AI Developer - Professional2026-101.6 Implement prompt engineering strategies and governance for FM interactions

Join prompt changes to observed runtime usage

Completed by the knowledge check

Learning objective

Audit prompt template repositories and usage with S3, CloudTrail, and CloudWatch Logs.

Core idea

A prompt audit needs to answer three questions: what artifact existed, who changed or accessed it, and what the application actually used. S3 can retain repository artifacts and release evidence. CloudTrail records service activity and principals. CloudWatch Logs can hold application decisions and Bedrock invocation records. These evidence types intersect, but they do not replace one another.

Design the join before an incident. A template object key is not a release identity if its contents can change. An API event does not necessarily contain the complete prompt payload. A model response log does not establish that an approver accepted the template. Record identities that let an investigator move between the repository, prompt version, deployment, and request.

How it works

Preserve repository artifacts and release mappings

Use an S3 repository for exported templates, evaluation results, and release records when those artifacts need durable storage independent of the application process. Prompt management still owns its managed prompt resource; S3 is the artifact repository and evidence store, not a substitute runtime Prompt management endpoint.

S3 Versioning retains multiple versions of an object and assigns unique version IDs to new objects in a versioning-enabled bucket. It is disabled by default. Enable it deliberately, and record both the object key and version ID in the release record. An object created before versioning was enabled can have a null version ID, so verify the artifact you intend to cite rather than assuming all existing content gained a new identifier.

Preserve a mapping from the S3 artifact version to the Bedrock prompt version ARN and the approval record. A content digest is useful application-owned evidence for checking that exported configuration matches the reviewed candidate. An S3 version ID and a Bedrock version number identify different resources; neither can be inferred from the other.

Versioning helps recover from overwrites and ordinary deletion, but it is not an approval gate. Decide who can update repository artifacts and who can publish an environment’s active release mapping. See 1.6.3 for promotion. Merely naming an S3 prefix approved does not establish that a review happened.

Capture control and access activity with CloudTrail

Amazon Bedrock integrates with CloudTrail to record API activity, including caller identity, time, request, and related details. Use that activity to investigate prompt-management changes and configuration operations, then relate them to your release records. Confirm that the event selectors and destination capture the event types your audit requires.

Bedrock’s runtime event classification matters. Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream are documented as management events. Managed-prompt rendering is a different event: RenderPrompt is a permission-only action that renders Prompt management resources for model invocation. To record it, configure advanced event selectors for data events with resource type AWS::Bedrock::Prompt.

Do not try to call RenderPrompt as an ordinary application runtime API to obtain an audit record. Its significance here is the permission and CloudTrail event boundary. A management-event trail that captures Converse calls does not automatically provide the managed-prompt rendering data events you need.

Guardrail evaluations follow the same pattern. To log ApplyGuardrail calls, including guardrail evaluations made during model invocation, configure advanced event selectors for data events with resource type AWS::Bedrock::Guardrail. That event records that an evaluation happened and who caused it; the application record still explains what the workload did with the result.

S3 access is another explicit boundary. Bucket-level activity and object-level activity are different event categories. CloudTrail does not record S3 object requests by default. Enable S3 object data events for the repository’s relevant bucket or prefixes, using AWS::S3::Object selectors. GetObject and PutObject are examples of object operations to capture when reads and template writes matter. Narrow selectors can reduce unnecessary evidence volume while preserving the paths under review.

Capture invocation content separately

Bedrock model invocation logging collects request data, response data, and metadata for supported runtime calls. It is disabled by default. Configure it with PutModelInvocationLoggingConfiguration, and verify the installed configuration with GetModelInvocationLoggingConfiguration. Supported destinations are S3 and CloudWatch Logs in the same account and Region as the logging configuration.

The documented supported operations include Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream. Logging applies to the bedrock-runtime endpoint; requests through other endpoints, such as bedrock-mantle, are not captured by this mechanism. Treat endpoint coverage as a separate inventory check rather than assuming the Bedrock service name implies identical logging behavior.

A CloudWatch invocation record includes metadata and JSON input and output bodies up to 100 KB. Larger JSON bodies and binary data require S3 delivery; if an S3 large-data destination is configured, CloudWatch records can refer to data stored there. Configure the large-data path when auditing those workloads. A small log event does not prove the original invocation had a small payload.

The log format includes requestId, operation, modelId, identity.arn, token counts, and optional caller-supplied requestMetadata. Supply metadata such as the application release identifier and selected prompt version identity when invoking through an interface that supports it. Those values are application-defined tags, not automatically inferred approval evidence. Do not assume modelId always contains the managed prompt’s ARN; the documented log field describes the model or inference profile used.

Join operational outcomes to the artifact

Emit application records for the selected release, request correlation identifier, guardrail decision, response-contract result, and terminal outcome. Avoid putting raw customer text into every diagnostic record. Invocation-content logs already create a separate sensitive-data surface; decide deliberately which evidence needs the full content and which needs only identifiers and decisions.

CloudWatch Logs Insights supports querying application JSON logs and discovering their fields. Use it to find requests associated with one release, inspect contract-rejection outcomes, and compare usage before and after promotion. Then join the selected release to the S3 version and approval evidence. CloudTrail answers who performed the API activity; application records explain why the workload accepted, clarified, blocked, or escalated a request.

Key distinctions and trade-offs

Repository history versus access history: S3 Versioning preserves object revisions. CloudTrail data events record object operations and callers. Keeping revisions does not tell you who read them.

API activity versus payload evidence: CloudTrail records service events. Bedrock invocation logging records supported request and response content. Enabling one does not imply the other is enabled. See 3.3.4 for the wider split between CloudTrail audit events and application decision logs.

Automatic fields versus caller assertions: requestId and identity.arn are service-populated invocation fields. requestMetadata comes from the caller. Check metadata against the release registry instead of accepting it as proof of approval.

More payload logging improves forensic detail but increases data exposure and storage volume. More selective logging needs stronger correlation records and a clear explanation of what the audit cannot reconstruct. Choose the evidence requirement first, then configure coverage and retention around it. CloudWatch Logs stores log data indefinitely by default; retention is a per-log-group setting, and events past it are typically deleted within 72 hours rather than immediately.

Architecture / decision scenario

An auditor asks whether production used an unapproved support prompt. The release registry maps the active prompt ARN to an S3 object version and review decision. CloudTrail records template writes, production configuration activity, and RenderPrompt data events for the managed prompt resources.

The service also sends its release identity in request metadata and records the version selected for each request. CloudWatch Logs Insights finds a worker using the prior release after deployment. The investigator checks that release’s approval record instead of assuming that an older reference was unauthorized.

One disputed request contains a large document. Its CloudWatch event cannot supply the entire payload, so the investigator follows the S3 large-data record. If that destination was never configured, the team records an evidence gap; it cannot recover missing content by enabling logging after the event.

Common exam traps

Assuming S3 Versioning logs who accessed a template.
Assuming object data events are enabled because bucket management events exist.
Treating RenderPrompt as a callable inference API.
Expecting CloudTrail to replace full model invocation logging.
Assuming CloudWatch embeds every payload regardless of its size.
Treating caller-supplied release metadata as an independently verified approval.

What to remember

Join artifact version, managed prompt version, approval, and observed request identity.
Configure RenderPrompt, AWS::Bedrock::Guardrail, and S3 object data events deliberately.
Enable invocation logging separately and account for endpoint and payload-size coverage.
Use CloudWatch Logs for decisions and queries, and S3 for durable artifacts and large content.