3.3.3. Prompt Management and Versioning
💡 First Principle: Prompts deployed to production require the same engineering discipline as deployed code: version control, peer review, staged rollout, and instant rollback capability. A prompt change that improves quality for 95% of cases may break the other 5% — you need to detect that before it affects all users.
Amazon Bedrock Prompt Management provides the managed service for prompt lifecycle:
- Template creation: Parameterized prompt templates with variable substitution (
{{customer_name}},{{retrieved_context}}) - Versioning: Immutable prompt versions — each publish creates a new version; prior versions are never modified
- Approval workflows: Integrate with SNS/Lambda for human review before production deployment
- Access control: IAM-based permissions on who can create, update, and deploy prompts
- Audit logging: CloudTrail records every prompt access and modification event
# Use a versioned prompt from Bedrock Prompt Management
bedrock_runtime.converse(
modelId='anthropic.claude-3-sonnet-20240229-v1:0',
promptVariables={
'customer_name': {'text': customer_name},
'retrieved_context': {'text': context_from_kb}
},
# Reference specific version — pinned for production stability
promptArn='arn:aws:bedrock:us-east-1:123456789:prompt/PROMPTID:3'
)
Prompt regression testing pipeline:
⚠️ Exam Trap: The CloudTrail audit log for Bedrock Prompt Management records who accessed and modified prompts, but it does not record the actual prompt content of each API call at invocation time. For that — to see what prompt text was sent and what response came back — you need Bedrock Model Invocation Logs enabled in CloudWatch.
Reflection Question: Your team deploys a prompt update at 2pm and by 3pm the support team reports the chatbot is refusing to answer questions it previously handled. You need to roll back immediately and investigate. What is the rollback procedure using Bedrock Prompt Management, and what log sources would you query to understand what changed?
