Bedrock Prompt Management โ Governance Features
Prompt Management provides: versioning (track every change to a template), review workflows (approve before activating), parameterized templates (reusable with variables), and role definitions (system/user/assistant roles embedded in template).
Auto-activating new versions as they save bypasses the review workflow entirely โ that's the anti-pattern. The exam distinguishes between "versioning with review" vs "versioning with auto-activation." Review = governance. Auto-activate = no governance.
Scenario: "governance requirement, all prompt changes must be approved before deployment" โ Prompt Management with review workflow + versioning. Not auto-activation.
Compliance Stack โ What Belongs Where
The correct governance + compliance stack:
Bedrock Prompt Management โ manage parameterized templates, versioning, review workflows
Bedrock Guardrails โ enforce content safety policies (not RBAC, not compliance logging)
AWS CloudTrail โ audit log of API calls (who called what Bedrock API, with which template, when) โ this is your compliance record
IAM + permission sets โ role-based access control (who can invoke which models)
CloudWatch Logs = operational monitoring (errors, latency). CloudTrail = compliance audit trail (API activity). For "compliance" and "audit trail" questions โ CloudTrail. Never CloudWatch.
Avoid: "use Guardrails for RBAC." Guardrails filter content โ they don't control who can invoke which model. RBAC = IAM.
Prompt Lineage โ Tracking Template History
Prompt lineage = tracking which version of a template was used for which invocation, and what changed between versions.
Implementation: Bedrock Prompt Management stores template versions โ AWS CloudTrail records the specific template version ARN used in each Bedrock API call โ you can reconstruct exactly what prompt was sent and when.
CloudWatch Logs stores the text of invocations but not the template version management. S3 object tags are a manual approach with no native versioning integration. Prompt Management + CloudTrail is the AWS-native lineage solution.
Output Source Traceability
When you want to know "which document from the knowledge base influenced this response?", the pattern is: tag FM outputs with metadata from the data source at generation time โ include source document ID, title, chunk reference in the response metadata.
Model invocation logs tell you what went in and came out of the LLM, but not which retrieved KB chunk was the source of truth. Tagging the output explicitly at generation time is how you get end-to-end traceability.
IAM Identity Center โ Permission Sets vs IAM Roles Directly
Permission sets in IAM Identity Center define what access a role has across multiple AWS accounts. They're defined once and assigned to accounts โ no need to replicate roles manually across accounts.
For Bedrock model access control: permission sets can include condition keys like bedrock:ModelArn to restrict which models a department can invoke.
IAM Identity Center + permission sets = single definition, multi-account consistency. IAM roles created per-account = drift, inconsistency, management overhead. The exam always prefers Identity Center for enterprise multi-account scenarios.